The obvious analogy for AI in enterprise integration is, of course, a child’s birthday party. My daughter wanted pancakes for her party. Imagine I’d hired a robot to make them.

The robot could make pancakes. It couldn’t decide which ones. What kind? What goes on top? How do you satisfy every guest? Her mother wanted to be sure there was fruit. Making pancakes was never the hard part. Deciding what to make, and for whom, was. Nobody would have cared how the robot worked. They would have cared what landed on their plates.

AI-built integrations raise the same kind of question, with more at stake. AI is starting to prove itself at generating code. Now, leadership is asking employees across every department to find efficiency with AI, leaving integration leaders with two open questions:

1. Can AI be trusted to generate integration code?
2. Is “code” the right level of abstraction for integration work at all?

Integration leaders have long faced growing demand on limited budgets. The growth of AI made people expect more, and expect it faster. In addition to deterministic workflows, they now want agentic workflows. These use LLMs to judge, route or respond, and require governed access to systems and data.

We build high-stakes integrations, the kind that keep payments, orders or insurance claims from getting lost. Before we'd let a model build or manage one, it had to earn our trust. This is how we got there, and what's working so far.

What we tried first (and why it didn't work)

Foundation model providers made a simple suggestion: give a high-reasoning model a goal and see what it produces. We asked a generic coding agent to integrate our systems together.

The coding agent produced a workflow that compiled. It also wrote its own tests, and they passed. We still wouldn’t have released it. Tests an agent writes for its own build tend to check its own assumptions. Short of reading every line, we couldn’t know what it had missed. Rebuilding from zero would have been faster than understanding its output.

These experiments also made clear that raw code was the wrong medium for integration. Left to build from scratch, a generic coding agent reasons its way through how to talk to critical systems each time. Digibee already has connectors that send legacy SOAP messages and call modern APIs. We gave the agent those pre-built connectors. That fixed how it talked to enterprise systems. It didn’t fix how it designed integrations.

Every integration embodies a pile of decisions. Where does a process split? What counts as a unit of work? What happens when something fails midway? Get those wrong, and you can duplicate orders or drop transactions. Without a spec, the agent made all of those decisions silently, with no record of why and nobody accountable. The workflow also wasn't ordered the way a person would have ordered it. It might work, but it was hard to follow and harder to maintain. 

So we set a rule: every decision gets a named owner and a written reason before the build, and an integration goes to production only when its owner can explain how it works and why.

A copilot wasn't enough

Letting an agent make every decision didn't work. An integration engineer might catch the gaps during a workflow review. By then, fixing them meant so much rework that the initial workflow build was hardly worth it.

So we brought a person into the loop. We set the coding agent up as a copilot, a thought partner we could go back and forth with. Together, we specified decisions together. That moved the engineer’s work up a level, from integrations to decisions. Instead of one long prompt and one big build, we refined context step by step into a specification. We reviewed the decisions in the spec first, then checked generated workflows against them. That was our answer to the second question: code isn’t the right level. Decisions are.

For the first time, this cut the load on the integration engineer. It still wasn't enough. Two questions kept coming back. 

• How do you elicit good recommendations and proposals from the AI? 
• How do you know the spec has everything the build needs? 

We kept the coding agent and the copilot. We needed something on top of them.

Teaching the system integration, not just coding

Reasoning wasn't the gap. The model’s weights contained internet-scale knowledge; it just wasn't thinking through what an integration architect would think through. So, we taught it integration by adding three things on top of reasoning: an operator, a method and a harness. We call the result Digibee Digital Workers.

• The operator is a specialist agent with deep integration expertise. It knows what a good integration looks like, because we gave it build guidelines for 13 different archetypes. It knows the decisions each kind of integration forces, because we organized options and tradeoffs by archetype. Real-time integrations raise one set of decisions, batch another, event-driven a third for example.
• The harness is the environment around the model: guardrails, validation, tools, and a way to carry context from one step to the next. It keeps the Digital Worker inside the lines. Validation runs two ways. A model checks meaning against a rubric. Code checks what can be tested exactly.
• The method is how a person and the AI work together. A Digital Worker interviews you. It runs a playbook, a series of steps toward a defined outcome, and invokes skills that force decisions and offer options. One skill leads to the next and you can loop back.

As part of this structure, we wrote skills (reusable instructions the Digital Workert loads for a task) to help users decide the integration's topology and design. This meant that the structure that came back wasn’t a surprise. Ask for a circle and you might get variation in size or color, but you won't get a dinosaur. 

What that actually got us

This combination got us a shippable integration, emphasis on shippable. A Digital Worker interviewed us to check business exceptions, technical errors, and transformation requirements. The resulting spec covered what the build needed. We recorded each architectural decision and approved it. 

When the workflows came back, we could check whether the AI had followed those decisions. When it misunderstood something, we could correct it, the way you would with a new colleague, through questions, answers and clarification.

The operator also pushes back. On one project, our Field CTO specified an architecture for a planned integration. His Digital Worker pushed back: his requirements fit a different archetype than the one he'd chosen, and it asked whether he wanted to reconsider. He did.

That's the expertise doing its job.

Re-arguing the same decisions

Good specs got us shippable integrations, but we found that we repeated the same decisions on every new project. The Digital Workers knew how integrations work generally, but knew nothing about the choices we'd already made in a specific environment.

The fix was organizational memory: a place where the Digital Worker stores the decisions you've already made and looks them up on the next project. It keeps your preferences, your security standards and your architectural standards. When a workflow needs a queue, it already knows which queue to use, so it doesn't have to ask.

Decisions live at different levels. Some belong to one project. Some apply across multi-year programs. The widest apply to the entire estate: principles, architecture, where your systems of record sit. Because those decisions sit in one place, a Digital Worker can run impact analysis. If you’re moving customer master data from the ERP to the CRM, a Digital Worker can tell you which workflows have to change, and how.

Where the goals live now

The goals still come from a person: what outcome you need, not how to build it. A Digital Worker then works across 13 disciplines, including enterprise architecture, integration architecture, quality management and business analysis. Each one has its own objectives and verifiable results, written into the instructions it runs on. They're disciplines, not roles. A Digital Worker joins a discipline as a teammate and doesn't replace the person in it.

Our Digital Workers propose tradeoffs, and neither side is right by default: synchronous or asynchronous, tightly or loosely coupled, strict or eventual consistency. The requirement decides. A bank will lean toward zero trust. An e-commerce platform will optimize for transaction speed. Any choice that’s irreversible, or has a wide blast radius, goes to a person for approval.

Co-author and delegate

Our Digital Worker approach changes where people spend their time. You co-author the design and the plan. You hand off the volume work. Digital Workers build draft workflows and monitor those in production. They send decisions to your people to ratify. A named person makes the final call. A good conversation with the Digital Worker pays off twice: the spec and the workflows clear a higher bar, and you become a better integration professional.

This has costs. Speed moves the bottleneck. When design work shrinks from days to hours, human review sets your delivery pace. A spec also has to be the right size. Over-specify, and an engineer spends the day babysitting the AI. Under-specify, and the AI chases the wrong workflows and burns tokens. Our own professional services team found the new review habits hard to learn, but several team members have since had big wins.

One of our professional services engineers budgeted 12 days to review data and design architecture, and to refine business requirements for a project. With a Digibee Digital Worker, she finished in about three hours, roughly 32 times faster, and 9 of the project’s 11 flows were ready to build. That gain covers one phase of the integration lifecycle, and one project isn’t a backlog, but it’s one item cleared to make room for the next one.

Getting the balance right

Give the AI too much context and quality decays. Give it too little and you've offered no steering. Somewhere between micromanaging and no guidance there's a happy medium, and we encoded that into the harness and the operator. We're also working on skills and the spec as graphs, maps of how each piece connects to the others. The AI could then move through them and show you the requirements that matter, and what each decision touches, as you make it.

Our trust in our Digital workers comes down to this:

• We trust the tested connectors the Digital Worker builds with.
• We trust the integration expertise built into the Digital Worker.
• We can check the Digital Worker’s work against the spec we co-authored together. 

If I could invest in only one part of this operating model, I would invest in the work before the build: co-authoring the specification and engineering the context in organizational memory. Both raise the bar before anyone reviews a workflow.

[Get early access to the first AI-native integration platform →]