Connecting AI Agents to Legacy Systems Without a Rewrite

You usually do not need to rewrite an older system before an AI agent can work with it. Three narrow patterns cover most cases: a read-only bridge that lets the agent query live data, a scheduled export that gives it a controlled copy, and a write endpoint limited to a few actions that are validated and logged. The system of record stays where it is, and the agent never receives more reach than the task needs.

Key takeaways

• A rewrite is rarely the right first step. Start with the smallest interface the existing system already exposes.
• Read-only access should be the default, with exports used when live queries are slow, fragile or unavailable.
• Write access works best as a few named actions with validation, idempotency and a human approval rule for anything that moves money, contacts customers or changes legal or tax records.
• Every bridge needs an owner, a log of what the agent read or wrote, and a way to switch it off without touching the legacy system.

Why a rewrite is usually the wrong first step

Replacing an older system is a project with its own schedule, budget and risk. A company that wants an agent to help with order questions, stock checks or back-office paperwork rarely needs the replacement to happen first. It needs a controlled way to read what the old system knows and, for a small set of tasks, to record a result in it. A rewrite also moves the records, which means the agent project inherits every data migration problem before it has shown any value.

A bridge keeps the record where it is. The legacy system remains the source of truth, the staff who know its quirks keep working in it, and the agent operates through a narrow door. If that door turns out to be the wrong size, you can resize it without reconstructing the whole system.

Three patterns for working with an older system

Name the pattern before you build anything, because each carries different risks.

• Read-only bridge: the agent queries the system through a database view, a reporting endpoint or a vendor API with read-only scopes. It can answer questions and prepare drafts, but it cannot change a record.
• Export job: a scheduled process copies a defined set of records into a separate store, such as a file, a table or a document index. The agent works from the copy, which protects the live system from load and from accidental edits.
• Narrow write endpoint: a small, documented action, such as attaching a note to a ticket or creating a draft order line, that the agent can call. It accepts only the fields you have listed, checks them before they reach the system, and records who or what requested the change.

Export jobs have a freshness problem. A copy taken overnight will not reflect a cancellation made at noon, so the agent must state the time of the data it used. Read-only bridges avoid that gap but depend on the legacy system tolerating queries without slowing down the people who use it. Narrow write endpoints are the most useful and the most dangerous of the three, which is why they should be the last pattern you add, not the first.

Which pattern fits each task?

Do not choose one pattern for the whole system. Decide task by task, using these questions.

• Does the agent only need to answer a question or prepare a summary? Use a read-only bridge or an export job.
• Can the answer tolerate being a few hours old? An export job is usually enough, and it places less load on the live system.
• Does the task need the current status, such as stock on hand at this moment? Use a read-only query with a timeout and a clear fallback message.
• Does the task create or change a record? Design one narrow write action, with its fields, limits and approval rule written down before any code is written.
• Would a wrong write be hard to reverse, or would it reach a customer, a supplier or a regulator? Keep a person in the approval step, even if the agent prepares the change.

The answers usually point to one pattern per task, and a single legacy system often ends up serving all three. That is normal. The goal is a set of separate, individually switched-off paths, not one broad connection.

Build the read-only bridge and the export job

Most of the work here is definition, not code. Before anything is connected, write down what the agent is allowed to see and why.

• State the business question the bridge must answer, in one sentence.
• List the exact tables, reports or endpoints needed, and exclude everything else, including personal data that the task does not use.
• Create a credential that belongs to the agent rather than to a staff member, and grant only the read scopes on that list. The OWASP authorization guidance is a useful reference for separating who may act from what they may see.
• For export jobs, define the schedule, the file or table format, how long copies are kept and who may delete them.
• Stamp every answer with the time its data was read or exported, so the reader can judge freshness.
• Test with records you know well, and compare the agent's answer with what a staff member sees on the screen they normally use.

For a deeper treatment of the database case, see how to connect an AI agent to your database with read-only access.

Keep write access narrow

A write endpoint is a small product, and it deserves the same discipline as an API that outside developers use. Anthropic's guidance on writing tools for agents makes a similar point: clear names, tight inputs and predictable results matter more than breadth. Keep the list short enough that one person can review it in a single sitting.

• Each action does one thing, such as adding a note to a case or creating a draft quote. Avoid any general update call.
• Inputs are validated against the legacy system's own rules before submission, and rejected requests return a plain reason.
• Every submission carries a unique key, so a retry after a timeout does not create a second record. Payment providers such as Stripe document this approach for repeated requests. The same idea applies to a stock adjustment or a case note, as explained in the guide on preventing duplicate AI actions.
• The action writes a log entry with the request, the requester, the time and the result.
• Actions that move money, contact people outside the company or alter legal or tax records require a named person to approve each change.
• The agent cannot widen its own permissions or add actions. Changes to the endpoint list go through the same review as any other system change.

Legacy records often contain free text typed by people or imported from forms, and that text can include instructions the agent should not follow. Treat record contents as data, never as commands. The OWASP guidance on prompt injection prevention describes this risk and the controls that reduce it.

Test, monitor and hand over

Illustrative scenario: a regional distributor keeps its stock and order history in an inventory program that has run for many years and offers only a basic export. Account managers want an agent that answers availability questions and drafts replacement orders.

The team starts with a nightly export, so the agent can answer questions about order history without touching the live system. Next they add a read-only query for live stock, with a timeout and a message that tells the user when the live check failed. Only after several weeks of logged answers, reviewed by the account team, do they consider a draft-order endpoint. Draft orders enter the legacy system only after an account manager approves them. Each step has its own switch, so a problem in one path does not stop the others.

Before any bridge goes live, check it against a written acceptance list, such as the one in the acceptance checklist for an AI agent integration. After launch, watch for the signals that matter: failed exports, stale timestamps, rejected writes and approvals that take too long to reach a person.

Be Human approaches this in the same order. The first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations then cover monitoring of the bridges, recurring evaluations of the agent's answers, maintenance when the legacy system changes its interface, permission reviews and incident response when a credential or an export fails. The agent keeps its identity, memory and operating context under the company's control, and the legacy records stay where the company keeps them.

If you are not sure which existing system or task to start with, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent work with a legacy system that has no API? Yes, but the route changes. Database views, scheduled reports or file exports can serve as read-only sources even when there is no modern interface. Where nothing is available, a browser-based connection may be possible, but it is more fragile and needs tighter controls, so check what exists before choosing a pattern.

Do I have to move my data to a new system before an agent can help? No. The bridge pattern exists so that the legacy system can remain the record of truth. Moving data is a separate decision with its own justification, and an agent project should not depend on a migration to start producing value.

Is a copy of the data safe for an agent to use? A copy can be safe when it contains only the fields the task needs, is stored with restricted access and is deleted on a defined schedule. The main risks are stale information and personal data spreading beyond its original purpose. Label every answer with the time the copy was made.

Who should approve the first write action? Someone who owns the business outcome and understands the legacy record, usually an operations lead working with whoever maintains the system. Approval should be recorded for each action or for a defined class of actions. Review the log after the first weeks, then narrow or widen the rule based on what you see.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.