Decision support
Can an AI agent work with our existing software?
Yes — and integration is rarely the hard part. What breaks is that your systems were built assuming the caller was correct.
The question
Our stack is a mix of old and new. How hard is it to connect an agent to it?
The short answer
Connecting is straightforward — if a system has an API, an agent can call it, and if it does not, the same wrapper you would write for any other client works here too. The difficulty is elsewhere: your internal APIs were almost certainly designed on the assumption that the caller knows what it is doing. An agent does not. It will retry a request that already succeeded, pass a plausible but wrong identifier, call things in an order no human would, and occasionally invent a parameter. So the integration work is not connectors, it is making each endpoint safe for an unreliable client — idempotency keys so a retry cannot double-charge, strict validation so a hallucinated argument is rejected rather than accepted, and a compensating action for anything that cannot be undone. Budget for that rather than for the plumbing.
Written for
- Leaders told integration will be the expensive part
- Teams connecting an agent to internal APIs for the first time
- Anyone whose systems predate the idea of an unreliable caller
Why the answer is that
The integration question is usually asked as a compatibility question, and compatibility is rarely the obstacle. REST, GraphQL, SOAP, a database, a CLI, a screen-scraped internal tool — all of it can be exposed to an agent, and the Model Context Protocol has made the wiring more uniform than it was. If your systems can be called by a script, they can be called by an agent.
What is genuinely different is the caller’s reliability. Internal APIs accumulate assumptions: that the client will not call this twice, that the ID passed in came from a previous response rather than being made up, that steps happen in a sensible order, that a field is either present and valid or absent. Those assumptions hold for code you wrote and they do not hold for a model. This is why teams report that integration was harder than expected — not because connecting was hard, but because every endpoint the agent touches turns out to need hardening it never needed before.
Idempotency is the specific thing to fix first. Agents retry: on a timeout, on a transient error, on a partial response the model decided looked wrong. Without an idempotency key, a retried refund is two refunds and a retried email is two emails. This is a well-understood distributed-systems problem with a well-understood solution, and it is the single highest-value change you can make to an API before an agent touches it.
The second is validation at the boundary, and the rule is that the model’s output is untrusted input. Not because the model is bad, but because it is a probabilistic component and this is how you treat those. Validate the shape, validate that referenced entities exist, validate that the caller is entitled to act on them, and reject rather than coerce — a rejected call the agent can retry correctly is much better than a coerced call that half-succeeds. Where an action genuinely cannot be undone, the answer is not better validation but an approval gate.
What integration work actually consists of
Almost none of this is about connectivity. Each row is an assumption your systems make that an agent violates.
| Assumption in your API | How an agent breaks it | What to add |
|---|---|---|
| The client will not call this twice | Retries on timeouts and partial responses | Idempotency keys — do this first |
| IDs come from a previous response | Passes a plausible, invented identifier | Existence checks before the write |
| Steps happen in a sensible order | Calls step three before step one | Explicit state validation, not implicit ordering |
| Fields are valid or absent | Invents a parameter that looks right | Strict schema validation; reject unknown fields |
| The caller is entitled to this record | Acts on whatever ID it produced | Authorise per call against the end user |
| Someone will notice a bad batch | Runs it a thousand times in a minute | Rate limits and a bulk-operation ceiling |
| Errors are read and handled | Retries the same failing call in a loop | Bounded retries, distinct terminal errors |
| An operation can be redone if wrong | Cannot be — the email is sent | A compensating action, or an approval gate |
Every row is ordinary defensive engineering. That is the point — agent integration is mostly a distributed-systems problem, which is good news, because it means the skills already exist on your team.
Integration approaches, by what you can change
Pick the row that matches your constraints rather than the newest option.
| Situation | Approach | Watch out for |
|---|---|---|
| Modern internal APIs you control | Expose tools directly, add idempotency and validation | Tool schemas are billed on every call — attach few |
| Many services, want one interface | An MCP server per domain | It standardises transport, not authorisation — that is still yours |
| Legacy system with a stable API | A thin wrapper that narrows the surface | Expose the few operations needed, not the whole API |
| Legacy system with no API | A queue plus a worker, agent writes intent | Now asynchronous — the agent must handle pending states |
| Third-party SaaS | Their API, scoped credentials | Rate limits, and their idempotency guarantees may not exist |
| Read-only reporting need | Text-to-SQL against a replica with a row-level policy | Never the primary database; never without permission filtering |
The last row is worth stressing: agents that query data directly are the fastest way to deliver value and the fastest way to leak across users. Read replica, permission filter before the query runs, no exceptions.
Get the answer for your own system in four minutes
The free scorecard produces a score out of 100, a breakdown across reliability, cost and observability, and your gaps ranked by production risk with a fix and effort estimate for each. It prints to a PDF you can take into a planning meeting — which is usually more persuasive than an argument.
Run the scorecardIf you are the engineer who found this page: Written to be forwarded. If you are the engineer who found this, send the relevant one up — it is framed for the person who has to approve the work.
If you decide to do the work
The engagements this decision leads to, each with the full method and effort estimates — whether your team runs it or I do.
Questions
Can AI agents work with our existing software?
Yes. If a system can be called by a script — REST, GraphQL, SOAP, a database, even a CLI — it can be called by an agent, and MCP has made that wiring more uniform.
The cost is not in connecting. It is that your internal APIs assume a caller who knows what it is doing, and an agent does not: it retries, passes invented identifiers, and calls things out of order. Hardening those endpoints is the actual project.
What is the first thing to fix before connecting an agent to our API?
Idempotency. Agents retry on timeouts, transient errors, and partial responses the model decided looked wrong.
Without an idempotency key, a retried refund is two refunds and a retried email is two emails. It is a well-understood problem with a well-understood fix, and it is the highest-value change you can make to an endpoint before an agent touches it.
Do we need to rebuild our legacy systems to use AI agents?
No. A thin wrapper that exposes only the few operations the agent needs is usually the right answer, and narrowing the surface is a feature rather than a compromise — fewer tools means fewer tokens per call and fewer ways to go wrong.
If a system has no API at all, have the agent write intent to a queue and let a conventional worker perform the action. That keeps the unreliable component out of the write path entirely.
Is MCP the right way to integrate agents with internal systems?
It is a good way to standardise how tools are described and transported, and it removes a lot of bespoke glue.
What it does not do is authorise anything. MCP standardises the protocol, not permissions — the agent still needs to act with the calling user’s entitlements, and every tool call still needs validating against what that user may do. Treat MCP as plumbing, not as a security boundary.
Want a second opinion on the decision?
Describe your situation and I will tell you what I would do — including when that is "nothing" or "handle it internally". No charge for that, and it is genuinely how a lot of these conversations end.
Other decisions
- What an agent audit should cover
- Questions to ask before launch
- Build or buy: observability
- Metrics worth reporting upward
- Do you need outside help?
- Can an agent touch our internal data?
- Is an agent different from a chatbot?
- Governance, audit logs and compliance
- Do we need our own model?
- Where to put a human in the loop
- Agent cost versus hiring