Where every integration decision, workaround, and mapping becomes reusable infrastructure

Today we're sharing the architecture behind how Refold learns from every integration it delivers: the Integration Graph.

Simply put, the Integration Graph is the system of record for everything an integration team learns. It remembers every mapping, every fix, every API quirk an engineer would have kept in their head. Each one is captured as a structured, queryable record, scored for confidence, and linked to the specific applications and fields it touches. That knowledge is then available to every future deployment.

It works differently from prior AI approaches:

• Unlike RAG, which retrieves chunks of text by keyword similarity, the Integration Graph retrieves by structural match. Every confidence-weighted pattern attached to this specific field on this specific object, across every prior deployment.
• Unlike fine-tuned models, which freeze knowledge at training time, the Integration Graph learns continuously.
• Unlike agent frameworks, which orchestrate within a session and forget between them, the Integration Graph compounds. Every integration starts with more context than the last.

The impact, measured across 9 production deployments of the same SAP S/4HANA ↔ Salesforce connector pair, with the same 3-engineer team:

• 70% reduction in human-hours from cold-start to deployment 7, 320 hours down to 95
• 82% of fields auto-mapped by deployment 7, pulled directly from the graph
• Sublinear marginal cost, every deployment costs less than the last, because the reusable portion compounds while the tenant-specific portion shrinks

The challenge with enterprise integration today

We keep hearing the same two things from every integration team we talk to

The first is that knowledge walks out the door. Every production SAP or Salesforce instance carries hundreds of custom fields with no record of why they exist. Systems integrator turnover runs 15–25% annually, so by the time Priority_Flag__c needs mapping, the engineer who could explain it is gone. Same for runtime knowledge — which API quirks differ from the docs, which errors cascade, which resolve on retry. Every team transition is a partial reset.

The second is that vendors ship change before changelogs. Customer A hits the break. An engineer ships a fix. A week later Customer B hits the same break, and the cycle runs again. Teams react to change; they don't anticipate it.

Across 200+ deployments of the same connector pairs — SAP↔Salesforce, SAP↔Coupa, NetSuite↔Shopify — we've watched the same pattern: most teams rebuild the solved part from scratch, then figure out the unsolved part from first principles. The industry has no system of record for the operational knowledge that keeps integrations working.

The issue isn't that AI can't reason about integrations. It's that the reasoning isn't persisted. RAG retrieves by keyword similarity, not operational relevance. Fine-tuned models freeze knowledge at training time. Agent frameworks orchestrate within a session and forget between them. Every approach we looked at treated intelligence as ephemeral.

How the Integration Graph works

The Integration Graph is powered by two primitives: Episodes and Patterns.

Episodes capture what happens during every deployment: every error hit, every fix applied, every human correction. This is how knowledge stops walking out the door when an engineer leaves. Patterns capture how systems actually connect: the recurring rules about field mappings, validation sequences, and API behaviors that today live in someone's head and get rebuilt from scratch on every new deployment.

When an agent runs a deployment, the full trace is captured automatically as an Episode and linked to the specific entities it touched. Over time, when the same behavior shows up across multiple Episodes ("validate currency fields against the local config before mapping"), the extraction pipeline lifts it into a Pattern: a typed rule with a trigger, an action, a confidence score, and a link to the entities it applies to.

The cycle is simple. Deploy, extract what was learned, enrich the graph, retrieve on the next deployment. Every deployment writes new Episodes. The pipeline lifts recurring behaviour into Patterns. The next deployment starts with more context than the last.

It works differently from a traditional knowledge base because every piece of knowledge carries a confidence score that decays over time if it isn't reinforced. The graph doesn't just accumulate. It stays current. Old knowledge that's no longer validated by real deployments fades out naturally, rather than persisting and misleading future agents.

What the Integration Graph unlocks in practice

As we deployed across more customers, we started seeing behaviours we hadn't explicitly designed for. They emerge from the architecture operating as a whole.

One customer's break becomes every customer's defence. When a vendor silently changes an API, the first customer to hit it captures the anomaly automatically, and every other customer on that connector inherits the defence before they ever see the break. We had an SAP field deprecation hit one customer on a Friday. By the following week, every other SAP deployment was already routing around it. No ticket filed, no engineer paged.

Fewer wrong mappings make it to production. The agent prioritizes decisions backed by dozens of prior deployments over superficially similar matches it's only seen once or twice. Not everything in the graph is equally trustworthy, and the system knows that. Every piece of knowledge carries a confidence score that decays if it isn't reinforced. Less rework, fewer post-go-live fires.

Past work stays findable, no matter how it was documented. Enterprise documentation is inconsistent at best. A fix logged as "locale configuration issue" six months ago will still surface when an agent is mapping a currency field today, because the underlying entities match, even if the terminology doesn't. The graph doesn't search by keywords; it traverses entity relationships.

New systems extend the graph, not break it. A large enterprise migrating from SAP ECC to S/4HANA introduced an entity type we hadn't anticipated. The system accepted it, we reviewed it, and now it's available to every future SAP migration.

We validated these behaviours across 30 deployments by disabling each architectural property in turn. Typed knowledge had the highest impact: removing it nearly doubled effort. Closed-loop learning was second; without it, the graph helps but doesn't compound. Standard configurations hit 82% reuse. Heavily customized enterprises hit 50%. The reusable portion compounds; the tenant-specific portion shrinks. The learning pipeline runs on about 1–2 hours of human review per week.

Available today

The Integration Graph is live in production across our customer base. Every new SAP, NetSuite, Oracle, and Salesforce connector pair deployed through Refold is writing Episodes and extracting Patterns as we ship.

For ISVs and SaaS companies building toward enterprise customers: your standard connectors go live faster because reusable mappings are already in the graph. Your custom integrations move from months to weeks because the reusable majority is handled automatically, and your team's attention goes to the tenant-specific portion that actually requires judgment.

Your engineering team builds product, not integrations. Your PS team delivers go-lives in days.

The organization that builds the most comprehensive Integration Graph wins. Not because it has the best model, but because it has the best context.

There is a layer in every enterprise that knows more about how the business actually works than any system of record. It isn't the CRM. It isn't the ERP.

It's the context layer : the accumulated record of decisions, exceptions, approvals, and precedents that explains not just what happened across systems, but why it was allowed to happen.

Every enterprise runs on two things. Rules, what should happen in general. And decision traces, what actually happened in a specific case, under what conditions, approved by whom, and why an exception was granted. The VP who approved a 20% discount on a Zoom call. The compliance ruling that changed how one vertical gets handled. The precedent set two years ago that still quietly governs how edge cases get resolved today.

None of that lives in any system of record. Systems of record capture the outcome. They never capture the reasoning. The CRM shows the final price. It doesn't show who approved the deviation or why. The ERP shows the transaction. It doesn't show the exception logic that allowed it.

That missing layer: the decision trace, the precedent, the why is what actually runs the enterprise. And it has never had anywhere to live except in people's heads.

AI agents are now entering this layer. And the question is whether they'll finally build what no software before them could: a deep contextual and business understanding of how an enterprise actually operates.

Integration Context: The Decision Record Nobody Captured

Every enterprise integration is, underneath the field mappings and trigger conditions, a fossil record of decisions.

Why does the finance team's revenue recognition sync fire at a different point in the pipeline than supply chain's procurement workflow? Because a CFO and a VP of Operations disagreed about when a sale was a sale, and someone configured the integration to reflect the compromise they landed on. Why does the financial vertical get different exception handling than everyone else? Because a compliance audit flagged a gap, an SI consultant rewired three mappings to close it, and that logic has been quietly governing revenue recognition ever since.

None of this is documented. None of it is queryable. It exists as organisational memory, distributed across the people who were in the room when those decisions were made, the consultants who translated those decisions into configuration, and the escalation threads that resurface every time a connector breaks.

This is what integration context actually is: not the shape of data in motion, but the reasoning that produced that shape. The business logic encoded in every custom field. The exception rules that reflect how a particular vertical actually operates. The approval chains that determined which system wins when two records conflict.

Integration services became a bigger business

Because iPaaS platforms built the infrastructure. But infrastructure that can't read the business it's connecting has a ceiling.

That ceiling is where system integrators built their businesses. Accenture, Deloitte, Wipro, and a generation of boutique integration consultancies scaled to multi-billion dollar businesses — and it wasn't because enterprises needed someone to configure Mulesoft. They scaled because every enterprise integration project eventually hit the same wall: the platform could move data, but it couldn't understand why the data needed to move that way.

The SI's value was never the code. It was the process of acquiring enterprise context and translating it to implementations.This included sitting with the customer

• Reading the schema
• Decoding the custom objects
• Vertical-specific rules
• Understanding the approval logic that no documentation captured

Finally encoding that understanding into a connector that actually reflected how the business ran.

That knowledge never transferred back to the platform. It lived inside the SI's delivery team. Which is precisely why the same customer called the same SI for the next integration, and the one after that, acting as a great land and expand motion for SIs alongside more forwar integrations into reconciliations and reporting use cases along side maintenances & fixes for these integrations. Not because switching was hard. Because the SI was the only party that remembered why the last connector was built the way it was.

The result: integration services became a bigger business than integration software and Saas overall as every new Saas application came with an added cost of implementing & maintaining it. The platform built the pipes. The services firm captured the context. And in enterprise software, context is where the durable value lives.

The entire SI industry is, structurally, a workaround for a missing software layer.

Agents will capture what iPaas could never

The reason iPaaS couldn't build the context layer isn't a failure of ambition. It's an architectural constraint.

iPaaS was designed around canonical schemas — Salesforce's standard Account object, SAP's standard Customer record. The assumption baked in: two instances of the same application are functionally equivalent. Map the fields, fire the trigger, sync on schedule. The platform doesn't need to understand the business. It just needs to move the data correctly.

But enterprise software is almost definitionally customised. The more successfully a company deploys Salesforce or SAP or Workday, the more its instance diverges from the canonical schema — and the more a generic connector misses what actually matters.

An Account with a custom field called Strategic_Tier isn't a schema artifact. It's evidence of a tiered account strategy, of downstream workflows that depend on that tiering, of business logic that any integration touching that object needs to understand. A connector that ignores it because it isn't in the spec isn't just incomplete. It's operating on a model of the business that doesn't exist.

Agents don't start from the canonical schema. They start from the actual one. They read the schema as a primary source: inferring the business logic encoded in every custom object, every non-standard relationship, every exception rule. They capture why a particular mapping was configured the way it was, who approved the configuration, what changed upstream when something breaks. And critically: they persist all of it.

Every integration becomes a decision trace. Every decision trace becomes context. Every deployment adds to a growing graph of organisational knowledge that makes the next integration faster, more accurate, and less dependent on a consultant who remembers what happened last time.

This is the compounding property iPaaS never had. It moved data reliably. It learned nothing from doing so.

The Implication

The enterprises moving fastest over the next five years won't be the ones with the most connectors. They'll be the ones whose integration layer has finally become what it always was in practice but never was in software: a living record of how the business actually works.

For CTOs at software companies selling into enterprise, this reframes the integration problem at its root. The constraint was never bandwidth — more engineers, more SI capacity, more iPaaS licenses. The constraint was always context. Understanding a customer's schema deeply enough to build an integration that reflects their operational reality, not a generic approximation of it.

The SI industry was built on that constraint. AI agents are the first technology positioned to dissolve it — not by automating the configuration, but by finally treating integration context as first-class data. Capturing it. Persisting it. Compounding it across every deployment.

The pipes were never the product. They were just what got built while the real layer waited.

Every enterprise feels it, but most of them can’t do anything about it.

That slow bleed of time, money, and talent spent just to make systems talk to each other.A workflow breaks, a new customer needs a custom sync, a field changes in SAP, and half the reporting stack collapses.

The result: integration tickets pile up, consultants bill by the hour, and business teams wait weeks for something that should’ve just worked.

That’s costing companies over $350B a year globally. We think it’s time to kill it.

So we raised $6.5M in seed funding to build the AI-native infrastructure that replaces it.The round was led by Eniac Ventures and Tidal Ventures, with participation from Better Capital, Ahead VC, Karman Ventures, Z21, and several incredible angels.

What we’re building

We’re building an AI-native execution layer where autonomous agents plan, build, and maintain integrations across your stack.

These agents do what entire teams or external partners used to:

• Understand how systems behave
• Write the glue code
• Sync data across APIs and browsers
• Handle retries, auth flows, field mismatches, and edge cases
• And most importantly - adapt automatically when systems change

Why this matters

Before Refold, we ran large-scale deployments across enterprise systems.We’ve lived through the chaos:

• Multi-quarter ERP-to-CRM syncs
• Endless finance reconciliation patches
• Fragile supply chain integrations held together by scripts and hope

They were repeating patterns that teams were solving the hard way - again and again.

So we built Refold to turn every one-off service ticket into repeatable, intelligent software.

Under the hood

Refold is structured across three key layers:

1. Workflow AgentsFor solution engineers and developers to generate, test, and maintain production-grade integration logic without boilerplate or ticket sprawl.
   
2. MCP ChainsA natural language layer where business teams can describe workflows and let agents handle the rest from logic to deployment.
   
3. Embedded Integration MarketplaceFor SaaS product teams to offer native integrations (UI + logic + observability) with zero setup and full enterprise safety.

Together, these layers allow companies to replace project-based chaos with agent-powered repeatability.

Where we are now

We’re already working with 30+ paying enterprise customers, including Incorta and Naehas. We’ve seen:

• 2x growth in the past two months
• Over 1,500 active users
• 30M+ API calls per month
• Seven-figure ARR
  

In production, our agents have:

• Automated reconciliation in finance workflows
• Unified inventory and ordering systems
• Built real-time ERP-to-CRM data syncs
• And eliminated weeks of ops work 

This funding helps us go deeper: more integrations, more adaptability, more invisible infrastructure.

What’s next

We’re growing our 20-person team across San Mateo and Bangalore to 30+ by year-end.We're expanding our agent capabilities across verticals and investing in zero-friction deployment for AI-first enterprise teams.

As AI becomes core to how work happens, Refold will be the layer that lets it execute reliably, safely, and autonomously.

We’re grateful to our early customers, partners, and investors for believing in this future.

And if you’ve ever duct-taped an integration and thought, there has to be a better way - we’re building it.

Come talk to us.