How AI Agents Work With Legacy Systems Without a Suitable Public API

Your agent needs a usable way into the legacy system that runs the job.

When a legacy application has no suitable public API, an authorised workflow may use the private web interfaces behind its logged-in pages or operate the UI itself. An application map records the available operations and their requirements so those routes can become repeatable, verified steps.

Test the action in your actual system, using the account your business approves. If the public API doesn't expose it, investigate whether another authorised route can complete it.

Legacy means years of decisions built into the software

An old interface is often the most visible part of a much larger problem. A support process can depend on custom fields, a return status in an order system, and an approval rule that changed after the original integration was built.

The people doing the work know where to look. They check another screen, recognise the exception, and ask someone before making a change.

An agent needs that context made explicit. Even a successful API call can update the wrong record or leave the next system waiting for a step nobody included in the workflow.

A modern internal application can leave an agent stuck in the same way, with incomplete interfaces and undocumented dependencies.

What can an agent use when there's no suitable public API?

Start with the routes the application owner already supports. An existing connector, import function, or approved script may cover the required operation without further discovery.

If those routes leave a gap in a web application, its logged-in interface may call private endpoints that perform the action. With authorised access, discovery can examine those requests and establish the inputs, session requirements, and response behaviour needed for the workflow.

A private endpoint needs validation in its own right. A request copied from a browser session may depend on a particular record state or a token that later expires, so seeing the request succeed once is only the start.

UI interaction is another route when the action is available on screen. Browser automation can combine model-guided exploration with repeatable steps; Stagehand's action API, for example, supports deterministic replay of observed actions.

The application's access controls still apply. Where the approved account cannot reach an operation, the workflow needs an authorised handoff or a change agreed with the system owner.

For a broader comparison of these choices, see AI agent integration platforms and connector coverage.

Follow a return through the systems that hold the answer

Consider an illustrative support workflow: a customer says they've returned an item and asks for a credit. The support case, order history, and warehouse return receipt live in separate systems.

A support employee would normally read the case, check what was bought, and confirm that the return was received. Then they'd apply the company's returns policy and send the proposed adjustment for approval.

The business defines that policy and names the authoritative order and receipt records before automation starts. It also decides who can approve a credit and which exceptions must stay with a person.

Read the records and establish that they belong together

The agent retrieves the support case and follows its order reference into the order system. It then reads the return receipt for the relevant item through an approved API, private web operation, or UI path.

An application map contributes the record relationships and operations needed to make those reads. The workflow must still confirm that the identifiers match; two similar customer names are insufficient evidence for a financial change.

Apply the rule and prepare the proposed action

Suppose the company's policy requires a recorded receipt before a credit request can proceed. The workflow checks that condition and prepares a request containing the order, returned item, and supporting receipt.

A missing receipt or disputed item condition goes to a person with the evidence gathered so far. Discovering how to create a credit request does not give the agent authority to decide an exception to the policy.

Obtain approval, write, and read the result back

Once the authorised reviewer approves, the workflow records the credit request in the order system and adds its reference to the support case. It reads both records back to confirm the request exists and the case points to it.

That is the completion condition for this example. Issuing a refund would be a separate action with its own permissions and approval requirements.

If the credit request is created but the support-case update fails, the workflow should retain the created request's identifier and report the incomplete step. A retry should use that existing request so it does not create a second one.

This is the work a pilot has to prove, including the exception and partial-completion paths.

The map connects access to a valid action

The return example needs more than endpoint names. It needs the relationship between the case and order, the state required to create the request, and a way to check the outcome.

An application map represents those operations, record relationships, and dependencies. It can include discovered validation rules and permission requirements that would otherwise be scattered across API documentation, admin pages, and workflow code.

Your people supply the business meaning: which source to trust, what counts as a received return, and who may approve the next step. The map helps make that knowledge usable in an executable workflow.

Keep the scripts that already work

A stable script can be the right way to execute a known operation. If it handles the relevant record states, validates the result, and has someone responsible for maintenance, it can remain part of the workflow.

Problems appear when the surrounding process changes and those assumptions go unchecked. A new approval step or a change in record ownership can make yesterday's valid action inappropriate today, even if the script still runs.

The response is to make those dependencies explicit and retest the affected operations. The same requirement applies to a connector, a browser action, or a discovered private endpoint.

What Monarch brings to the workflow

Monarch is the orchestration layer between agents and the enterprise systems involved in the job. Its Product Graph discovers application surfaces available to the connected account and represents captured, verified operations alongside their prerequisites and dependencies.

That gives the workflow a way to use existing software across public APIs, private web interfaces, and UI paths where applicable. Repeatable steps can be captured in deterministic code, with the business's rules and review points built into the workflow.

Monarch's access and approval model starts with an account your team provisions and scopes. A pilot should demonstrate the job with those intended permissions, including the action it must pause for a person to approve.

Start with the manual handoff

Choose a workflow where someone is already moving between systems to resolve a specific case. Write down what they read, what decision they make, and the evidence that tells them the work is complete.

Then test the ordinary case and the exception that would cause the most trouble if it were mishandled. Include a revoked permission or a failed second write so you can see what the operator gets back.

Monarch's 30-day pilot focuses on one to three workflows with a deployment engineer. We'll use the pilot to test the legacy step that blocks the job, including its access requirements and completion checks.