Integrating AI Agents with Legacy Systems: SOAP, VPNs, and Getting IT to Yes

There's a moment in every enterprise agent deployment where the architecture diagram meets reality. The demo ran against a clean REST API. Then someone says: "the actual inventory data is in a system we installed in 2011, it speaks SOAP, it's on-prem behind a VPN, and changes to it go through a review board that meets every other Thursday."

That moment is not a failure. That moment is the job. The systems worth integrating with are old precisely because they're load-bearing — the ERP that runs the plant, the AS/400 nobody dares touch, the claims system that predates half the staff. My time at Siemens working on industrial IoT — where "integration" meant MQTT brokers, plant equipment, and software with decade-long lifecycles — permanently cured me of expecting greenfield. Here's the playbook I've developed for pointing modern agents at old iron.

Respect the terrain before you plan the route

Legacy enterprise integration has a physics to it, and pretending otherwise burns weeks:

Protocols: SOAP/XML with WSDLs, fixed-width file drops on an SFTP server, database views you're allowed to read but never write, message buses that predate JSON. REST, if present, was often bolted on later and covers a fraction of the functionality.
Networks: the system is on-prem or in a private data center. There is no public endpoint. You'll be talking site-to-site VPNs, IP allowlists, jump hosts, and firewall change requests with their own approval queue.
Change velocity: the system itself will not change for you. No new endpoint, no webhook support, no "just add a field." Anything that requires modifying the legacy system is a different, much longer project.
Institutional memory: documentation is partial and the one person who understands the batch job retires next year. Interview them early. Buy them coffee. Their tribal knowledge is your real spec.

The planning consequence: your integration adapts to the system, never the reverse. Every pattern below is a way of doing that.

Wrap, don't touch: the facade is everything

The core move is the same one that works for modern APIs, applied with more armor: build a thin modern facade that speaks the legacy protocol on one side and clean, typed tools on the other. The agent never sees XML.

For SOAP specifically: generate a client from the WSDL (don't hand-roll the envelopes), wrap the two dozen operations you actually need behind a service with the interface you wish existed, and translate the failure modes — SOAP faults, timeouts, that special thing where the response is HTTP 200 but the body says <status>ERROR</status> — into the structured, hint-bearing errors an agent can act on (pattern 3 here). Legacy systems also tend to be slow and fragile under load: a mainframe-backed service that answers in four seconds and falls over at ten concurrent requests is normal. Your facade owns the concurrency cap, the queueing, and the caching, because the agent's loop will happily issue five parallel lookups and take the plant system down with enthusiasm.

The network answer is almost always the same shape too: a small connector service deployed inside the customer's network — their VM, their VPC, their rules — that talks to the legacy system locally and communicates with your agent platform via outbound-only connections it initiates. IT teams who will never open an inbound port will approve an outbound HTTPS connection from a component they host and can kill. Design for the connector being down, because their maintenance windows don't consult your uptime dashboard.

Screen-scraping: the last resort, honestly labeled

Sometimes there is no API, no database access, no file export — just a green-screen terminal or a Windows client, and a business process that lives entirely in it. Then, and only then, RPA-style scraping is on the table.

Go in with eyes open: scraping breaks when the UI changes, when a modal appears, when the locale differs, when the system is slow on the last day of the quarter. So if you must:

Scrape reads before writes. A scraper that extracts a status is annoying when it breaks; a scraper that enters data wrongly is an incident. Writes through scraping need checksums, screenshots-as-audit-log, and a human review gate until proven boring.
Keep the scraper behind the same facade. The agent calls get_claim_status(id); whether that's answered by a SOAP call or a robot driving a terminal is an implementation detail you can swap later. Never let the agent drive the UI directly — an LLM improvising against a production green screen is a genre of horror story we don't need more of.
Book its retirement in writing. Scraping is technical debt with a maintenance bill. Every scraper in my deployments carries a documented exit plan — the API that's coming in the vendor's next version, the export the DBA agreed to build — and gets revisited quarterly.

The strangler fig, agent edition

You don't modernize a legacy estate before deploying agents — you'd never start. The strangler-fig pattern gives you the sequencing:

Facade first. Everything above: one modern interface in front of the old system.
Route reads through the agent. Low risk, immediate value — "ask the agent instead of navigating the ERP" is often the single biggest win, because the legacy system's real tax was always the finding things out.
Add writes narrowly, gated. One transaction type at a time, through typed tools with approval workflows (same discipline as CRM writes), starting human-in-the-loop and earning autonomy with a clean track record.
Grow the new around the old. Data the agent needs frequently gets synced into a modern store with an explicit freshness SLA (pipeline patterns here); over time, more traffic hits the modern layer and less hits the legacy core.
Maybe, eventually, retire pieces. Or don't. Plenty of strangler figs live happily around a trunk for decades. The point was never the retirement — it's that every step shipped value without a big-bang migration.

The under-appreciated part: this sequencing is also your trust ladder with the customer. Each rung is a small, reversible, observable step, which is exactly what the next section needs.

Getting IT to yes

The hardest integration problem in the enterprise isn't technical. The IT and security teams guarding these systems have watched vendors promise magic and deliver outages for twenty years, and an "AI agent" pattern-matches to the riskiest thing they've ever heard. Their skepticism is earned. Treat it as a design input:

Ask for read-only first, and mean it. A proposal that starts with a read-only service account against a reporting replica is approvable in weeks. One that starts with write access to the ERP is approvable never.
Arrive with the security answers pre-written. Data flow diagram, what leaves their network (and what provably doesn't), where the model runs, retention, the named service account, the kill switch. Filling in their questionnaire before they send it changes the meeting.
Blast radius is your currency. Least-privilege accounts, rate caps below what they suggest, an off button they control. "Here's how you shut us down in one click" builds more trust than any accuracy benchmark.
Give them the audit trail as a feature. Every agent action logged with what, why, and on whose behalf — often better observability than their existing integrations have. I've watched that single artifact flip a review board from skeptical to sponsoring.
Find the internal owner who wins. Somewhere in that IT org is the person who's wanted a modern interface on this system for years. Make the facade their asset — something that outlives your agent and helps their roadmap — and you stop being a vendor asking for ports and start being the project they champion.

The takeaway

Legacy integration is the moat of forward-deployed agent work — anyone can wire an agent to a clean REST API. The playbook: respect the terrain, wrap everything behind a facade you control, run a connector inside their network speaking outbound-only, scrape only as a labeled last resort with a retirement date, sequence adoption as a strangler fig that doubles as a trust ladder, and treat IT's skepticism as a requirements document. The companies with the gnarliest legacy systems have the most to gain from agents — which means the engineers who can bridge that gap are the ones who get to ship where it matters.

Related reading