From ESB to AI Agents: Another Attempt to Make Enterprise Apps Cooperate

It is 9:47 on a Tuesday. An analyst types a question into a chat window, "Which customers churned after the Q2 price change?", and waits, because the answer lives in SAP for finance, Salesforce for sales, a homegrown CRM, a data warehouse, and three weeks of one-off scripts that nobody owns anymore. A new arXiv preprint called "Agentic Nesting" argues for a single answer to that Tuesday-morning stall: wrap each of those apps in its own AI agent, and let a central conductor translate one natural-language question into a chain of app-specific actions.

The framework, posted to arXiv this month, is a research proposal rather than a deployed product. Its authors call the central trick "Application-as-Agent": the idea that every existing enterprise application, no matter how old, can be encapsulated inside a "digital agent proxy" that knows how to talk to it and how to act on it. Above those proxies, a "central orchestrator" decomposes a user request and dispatches sub-tasks to the right agents. The user sees one conversational surface, called by the paper "Conversation-as-Integration," where they previously would have had to learn five different systems and write the glue themselves.

Enterprises have spent decades stitching systems together through three named predecessors: the Enterprise Service Bus (ESB), a central message router that became the integration backbone of the 2000s; API gateways, which expose each app's functions over the web; and Robotic Process Automation (RPA), which scripts human-style clicks to move data between systems that were never designed to cooperate. Each wave promised to retire brittle point-to-point integration. Each one, the paper argues, ended up reproducing the coupling and cost problems it was meant to solve. "Agentic Nesting" is positioned as the next bet: instead of routing messages or scripting clicks, route intents through agents that already understand the app behind them.

A digital agent proxy has to be built, maintained, and updated every time the underlying application changes its schema, its login flow, or its UI. The orchestrator has to be reliable enough to chain those proxies correctly, recover from partial failures, and refuse requests it cannot safely fulfill. The conversational interface has to handle the long tail of questions that span more than two systems, which is where most real "show me the churn after the price change" requests actually live. None of that is impossible, but each of those layers is a new place where things can break.

The honest test for whether "Agentic Nesting" is genuinely new, rather than a relabeled version of the centralization tax that ESB, API gateways, and RPA each imposed, will come from a small set of evidence the paper does not yet provide. Can a proxy be generated and maintained without a per-application engineering project, or does it become the next bespoke integration? Does the orchestrator fail predictably when one app is down, or does it hallucinate its way through the gap? And can an enterprise governance team audit what the chain of agents actually did, or is the reasoning locked inside a model that cannot explain itself?

Those are the questions enterprise architects will ask as they plan the next refresh cycle. For now, "Agentic Nesting" is a research proposal that names a problem most large organizations already feel, and a specific architectural bet worth pressure-testing before anyone writes a procurement memo.