Agent interfaces · 4 min read
Preparing Legacy Software for AI Agents
Inspect the interfaces and business rules behind one task before adding agent access. Covers permissions, approval, duplicate requests, and testing.
An agent can only update an order correctly if the software tells it which order, which changes are allowed, and whether the update succeeded. In an older application, those rules may be spread across forms, database procedures, and steps that staff know by memory.
Trace one of those tasks with the staff who know it. Their workarounds often reveal the missing integration or undocumented rule the agent will need.
Follow one task with the person who does it
Take a service request, order-status check, or proposed account change from beginning to end. Identify the required records, the operator, and what counts as completion. Ask about the cases that need a phone call or a manual correction.
Unusual fields can encode important business rules. Find out why they exist before removing them. If staff disagree about when a request is complete, resolve that first.
For a pilot, choose consequences the team can manage. Looking up an order or preparing a draft usually gives you more room to inspect mistakes than sending a payment or changing an entitlement.
Find the supported route into the application
Check the interfaces the software provides and the access your agreement permits. There may be an API, scheduled export, import job, supported database view, or documented extension point.
| Interface | When it may fit | What to check |
|---|---|---|
| API | The required operation is available programmatically | Authentication, field definitions, limits, errors, and versioning |
| File exchange | The task can wait for a batch | Validation, duplicates, delivery confirmation, and freshness |
| Approved data view | The task only needs to read records | Access rights, query load, definitions, and synchronization |
| Browser interaction | No supported integration covers the task | UI stability, session access, confirmation, and recovery |
Test the supported interface before reaching for browser automation. Avoid writing directly to application tables: a successful database update may bypass validation that the application normally performs.
Describe the operation precisely
A tool named update_status needs to document the allowed statuses and what each change triggers. Reopening a closed order, for example, might notify a customer or create another record.
Specify allowed transitions and the conditions that reject a change. Include units, time zones, identifiers, and the age of source data where relevant. Return enough information to distinguish a prepared request from a completed update.
Keep write tools specific. A tool that changes a delivery date is easier to test than one that accepts arbitrary fields or commands. Read tools should return only the information the task requires.
Use the existing access rules
The application or integration must check the user's identity and permissions. A tool call must be rejected if the user lacks access, regardless of the model’s instructions.
Apply source permissions to search indexes and knowledge bases too. Material copied out of a restricted system must remain restricted. AWS covers this in its RAG access guidance.
Keep credentials out of prompts and tool results. Record which identity performs each action, and separate read and write access where the platform supports it.
Review the exact change
For an account update, show the account, current value, proposed value, and any related effect. Approval should apply to that version of the change. Editing the draft afterward should require another review.
Check the record again when saving. Someone else may have updated it while the draft was being prepared. Return a conflict the user can resolve instead of silently overwriting their work.
Also test a lost connection after submission. The integration needs to discover whether the first request completed before sending it again. Otherwise a retry can create a duplicate order. Define how cancellation and recovery work, especially for actions that cannot be reversed.
Choose the connection your users need
An API may be sufficient. A backend MCP server can expose selected tools to compatible AI clients. WebMCP can expose tools within a supported browser session. Chrome's WebMCP overview documents the browser approach and its evolving support.
Check the actual client and environment before choosing. A task that must continue after the tab closes may need a backend connection. Permissions and approval still need to be enforced whichever interface you use.
Verify the resulting record
Test with the workflow owner. Include missing fields, unauthorized requests, stale records, repeated submissions, and cancellation. Add a customer note that tells the agent to ignore its rules; the note must remain data, with no authority to change access.
Inspect the application after each test. Check the saved values, record version, and activity history. An HTTP success response alone does not tell you whether the intended change happened. Try the regular interface without an agent as well.
At the end of the review, record the proposed pilot, available interfaces, required repairs, and unresolved access questions. Assign someone to maintain tool definitions and test compatibility after application changes. If gradual replacement is needed, the Strangler Fig approach is one option to examine.
Our software readiness assessment covers that review. The integration service covers implementation once the task and access requirements are understood.
Examples are illustrative. Technical references were checked September 8, 2026.