Wrap it, don't rewrite it
The pitch behind "AI agent wrappers" for legacy modernization is simple, and it's spreading fast through enterprise and government IT coverage in 2026: instead of a multi-year rewrite of a system too critical to take offline, you leave the legacy system running exactly as it is and build an AI agent layer around it, talking to it through APIs, connectors, and governed workflows. The agent becomes the new interface. The old system keeps doing what it was already doing correctly.
It's a reasonable answer to a real problem. Government IT in particular is dominated by systems nobody can afford to take down for a rewrite: reporting suggests the U.S. federal government alone spends over $100 billion a year on IT, with roughly 80% of it just keeping existing systems alive. That ratio isn't unique to the U.S.; it's the normal condition of any government running critical software at scale, ours included.
What's newer than the underlying idea is the word "agent." The pattern of building a stable, governed integration layer that lets something new sit on top of a legacy system without touching its internals isn't a 2026 invention. We built the non-AI version of it for the Government of Rajasthan in 2015, and we've been operating it in production ever since.
RajSevaDwar: the wrapper pattern without the AI
RajSevaDwar is the Government of Rajasthan's centralized state data-exchange platform: the government-to-government (G2G) layer that lets 40+ departments and 1,150+ services exchange data and trigger workflows across each other, without every citizen-facing system building and maintaining its own private pipe into every other department. Citizens never touch it directly, and that's the design intent. A request made at one counter, on e-Mitra, RajMail, or IFMS 3.0, doesn't have to be re-verified, re-keyed, or manually re-routed by a clerk at the next one.
Nobody rewrote e-Mitra, RajMail, or IFMS 3.0 to talk to each other directly. Instead, Data built and has operated, since 2015, the interface layer sitting between them: authentication and identity verification done once and trusted downstream, secure API-based integration for the department systems plugging in, and workflow orchestration that sequences multi-department approvals so a single citizen-facing request resolves correctly across systems that were never designed to talk to each other. That is, structurally, the same shape as the "AI agent wrapper" pattern being described this year. The legacy systems underneath didn't change. A governed layer on top of them did the integration work instead.
The 2026 version of this pattern gives the wrapper a different front door. Instead of only other software calling the integration layer, an AI agent calls it too, on a person's behalf, in natural language.
The caller changes. The discipline underneath doesn't.
Our own agentic product, Orion, is a useful way to see what's actually new and what isn't. Orion doesn't just answer questions: it posts to social media, navigates websites and retrieves results, fetches bank reports, posts invoices, and writes content, built under our Anthropic Claude Partner Network relationship. Every one of those actions is Orion calling an interface that already has to exist and already has to be governed, the same category of authenticated, permissioned, auditable API surface that RajSevaDwar has operated for a decade, just with an AI agent as a new kind of caller instead of another piece of software.
That's the part we think gets skipped in a lot of 2026 "agent wrapper" coverage: an AI agent is not itself an integration layer. It's a new consumer of one. If the interface underneath is well-governed, an agent calling it inherits that governance. If the interface underneath is sloppy, screen-scraping, undocumented, unauditable, an agent calling it will surface that sloppiness fast, in production, at conversational speed, in front of an end user. Our FORGE methodology for AI-assisted development exists specifically to build that governed layer quickly without skipping it.
IFMS 3.0: exactly the kind of system this pattern is for, and exactly the kind you can't get wrong
IFMS 3.0, Rajasthan's Integrated Financial Management System, is the state's treasury and disbursement backbone across 67+ administrative departments, 41 treasuries, 258 sub-treasuries, and roughly 32,000 Drawing & Disbursing Officers. It is precisely the kind of system nobody should rewrite behind a chat interface on a hunch. Data's engagement there has moved it toward a modern microservices architecture module by module, live since 2021 with major transactional modules live since November 2024, without a rewrite-everything-at-once approach and without a maintenance window a state's financial operations could actually afford to take.
That's the honest version of "wrap it, don't rewrite it" applied to a system where the cost of getting it wrong isn't inconvenience, it's a government's disbursement operations stopping. An AI-agent front end becomes a realistic option here only once there's a governed, module-by-module interface layer underneath it to call, the same precondition RajSevaDwar already met for citizen-facing services in 2015. The order of operations matters: integration layer first, agent front door second, not the reverse.
Ask what's underneath the agent before you ask about the agent
Most vendor pitches this year lead with the model or the demo: what the agent can say, what it can generate, how natural the conversation feels. That's the least useful thing to evaluate first. Before any of that, we'd ask a prospective AI-agent vendor, including us:
- Is there a real integration layer at all? Or is the agent screen-scraping and hitting endpoints that were never built or documented as a stable interface, which breaks the moment the underlying system's UI changes.
- Who verifies identity and enforces permissions, once, for every caller? Human or agent, that logic should live in one governed place, not be duplicated or, worse, skipped per feature.
- What happens when the agent is wrong? Is there an audit trail treating an agent's action the same way any other authenticated caller's action is logged and reviewable, or does "AI-generated" quietly become an excuse for weaker accountability.
We don't think every legacy system needs an AI agent bolted onto it this year just because the pattern is trending. We do think that whichever systems get one deserve the same integration discipline RajSevaDwar has run since 2015, before the word "agent" was part of the pitch.
If you're weighing an AI-agent interface on top of a system you can't afford to take offline, our Legacy Application Modernization page covers the government and enterprise tracks we run, and our AI & Anthropic page explains how Orion and our FORGE methodology fit on top of that integration layer once it exists.