A year ago, we asked ourselves: “how would we build our platform if we started from zero today?” 

The question came naturally to us. We founded Digibee to take full advantage of cloud technology when it was changing what was possible for b2b software. At the time, most legacy iPaaS platforms marketed themselves as cloud-native (but were still running “lift-and-shift”).

To this day, our customers see and feel this difference. And we won’t accept anything less in the AI era.

Here’s what we built to make Digibee AI-native, and the reasoning behind it.

The engineering work behind the label

We reassessed Digibee from first principles. Our goal has always been for integration professionals to use Digibee to build enterprise-grade workflows (complete with credential management, security, and auto-scaling cloud infrastructure) as quickly as available technology allows. With the introduction of agentic AI, work shifts from execution to delegation and strategy. 

To make this re-imagining a reality, we had to tackle some key challenges: 

1. Make the platform UX just as intuitive for agents as it is for people
2. Specialize and harness AI agents to operate as seasoned integration engineers
3. Evolve how people work with this new, digital workforce

Here’s how we addressed each of them.

How would agents (not humans) access platform features?

Humans need visual UIs to interact with software. They need menus. They need buttons. They need form fields.

AI needs atomized, self-explained interaction points. This is akin to the creation of API suites during the rise of microservices. But API suites needed to be written and documented for human developers who could track hierarchical information structures, transfer understanding from other endpoints, and parse ambiguous endpoint names.

LLMs don’t work that way. Given multiple ambiguous endpoint names, they will confidently forge ahead with any one of them. 

Our answer

We created APIs and MCP tools documented with clear, self-contained language.

What’s useful for agents (but not people)?

When users build and iterate in Digibee’s canvas, the platform surfaces the error message for the connector that failed. We could supply the entire workflow’s execution log, but actively chose not to. Users don’t need it, and feeding them the entire log would slow their efforts to find the information they’re actually looking for.

LLMs, in contrast, benefit from crunching through the entire execution log; the agent doesn’t necessarily understand what each node before the failure was supposed to do, and including the entire log adds context.

This is a narrow example, but the basic principle repeats elsewhere. Human users accumulate context through many vectors (such as the visual representation and their experience with other similar integrations). Agents gather context only from what they’re given at run time. 

Our answer
We built our agent-facing services to deliver deep context structured for LLM-friendly consumption.

How do we make LLMs behave like savvy integration engineers?

As we’ve written elsewhere, generalist coding agents can’t build enterprise integrations. Coding agents excel at work within a code base. Integration work exists on the level of organizational knowledge. 

The systems that integrations need to interact with frequently aren’t documented. LLM training data (which agents may default to, despite being given documentation) includes very few examples of how to wire together obscure enterprise systems—especially legacy systems. 

This training data limitation also applies to integration expertise. Digibee encodes integration knowledge and logic into a “flowspec” document. I would be surprised if Anthropic or OpenAI’s training data has seen more than 10 examples of these.

One more complication: context management. Building an integration workflow requires many divergent sub-tasks. Trying to force one agent to handle it all can undermine results; the context grows too long, and the agent grows confused.

Our answer

We distilled our knowledge of how flowspecs work and how integrations should be built into discrete prompt templates. We wrote (and rewrote) a bookshelf’s worth of them. Under the hood, we distributed the templates to specialized sub-agents that deliver expert-grade output. 

The user sees none of this. They interact with one primary digital worker, who takes the sub-agents’ output and creates a cohesive end-to-end project.

How does our (human) users’ work evolve?

Our new approach uses AI to draft projects and workflows, but it does so in collaboration with the user. Users define and guide the project and then verify the output. The integration specialist’s job doesn’t go away, but it changes—as Anthropic’s president and co-founder Daniela Amodei predicts for many jobs. 

Achieving this change required interfaces for two tasks:

1. Defining the workflow specification
2. Checking what the digital worker built

Our answer

Creating a surface for the user to check and adjust the digital worker’s output was easy; we already have the Digibee canvas.

To enable collaboration on planning, we built a completely new interface. It pairs a chat window with a multi-tab living document. The user begins by describing their high-level goal. Then, they collaborate with the digital worker to craft a detailed project specification, complete with edge cases, trigger conditions, and error handling.

Integration at a higher altitude

For Digibee’s users, AI-native means they now work at a higher altitude. While they review and adjust the digital worker’s creations in the canvas, they no longer drag-and-drop every component. In early tests with design partners, users completed workflows up to 20x faster.

This is good timing for integration teams. AI has increased the need for integration work, as users across enterprises build agents that need access to enterprise systems. In addition to clearing the backlog, this frees integration specialists to think more strategically. What processes can they centralize into capsules for easier maintenance? What opportunity for business impact haven’t we uncovered yet?

These are the questions that integration teams historically haven’t had the time for.

Ask them about the chatbot

“Lift-and-shift” was the sniff test for cloud-washing. The AI-native equivalent is simpler: ask any vendor whether they redesigned for agents or added a chatbot.

Bolting AI onto existing products creates the same problems lift-and-shift did. It locks you out of what a genuine rebuild makes possible and keeps you in an intermediate state longer than you’d expect.

The same logic applies internally. The biggest gains don’t come from accelerating existing workflows. They come from asking which of those workflows should exist in their current form at all.

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