Yes, but each route without an API gives up some control, so the deciding factor is what the agent must do. Reading through file exports, shared inboxes or a database copy works well. Writing through a screen is possible but harder to attribute, limit and stop. Many teams let the agent read and draft, and people make the changes.
What are the routes when there is no API?
| Route | Good for | What you lose | Typical depth |
|---|---|---|---|
| Scheduled file exports | Reading balances, transactions, case lists | Freshness: data is as old as the last export | 1 |
| Read-only database copy | Reading detailed records | Freshness; needs careful data access limits | 1 |
| Shared inbox or folder | Receiving documents and requests | Structure: content must be parsed | 1 to 2 |
| Work queue | Handing drafts to people to key in | Speed: a person completes the change | 2 |
| File upload the system already accepts | Bulk updates in a format the system validates | Per-item checks before upload, unless you add them | 3, with care |
| Screen automation | Entering data where nothing else works | Attribution, rate control, clean errors | 2 to 3, with care |
The first four are common and safe. The last two need more thought.
Why is writing without an API harder to control?
An API gives you three things for free. The system knows who called it, so the action is attributed to the agent's identity. A gateway can limit how fast it acts, which our guide on rate-limiting an AI agent at the API gateway covers. And errors come back as clear codes rather than as a screen that looks slightly different.
Screen automation loses all three unless you rebuild them. The agent usually logs in as a user, so the system records a person or a generic account. Nothing stops it entering a hundred records a minute. A changed layout can make it type a value into the wrong field without any error.
So the check that decides whether an action is allowed has to sit before the screen, in the agent platform, and the screen should be the last step, not the place where rules live.
What does the agent do, and what stays with people?
| The agent does | Stays with a person |
|---|---|
| Reads exports and inbox items | Deciding whether the export is current enough |
| Prepares changes as drafts in a work queue | Keying or approving the changes into the system |
| Checks its drafts against limits and sources | Exceptions it cannot resolve |
| Enters routine changes by screen, once proven | Owning the screen automation and stopping it when layouts change |
A work queue is often the most useful interface of all. The agent prepares each item with its sources; a person completes it in the system. It is slower than an API, but it gives full control and costs almost nothing to build.
What does this look like in practice?
Take a building society whose mortgage servicing system has no API. The agent reads a nightly export of accounts in arrears and a shared inbox of customer letters. It matches letters to accounts, drafts the servicing changes each letter asks for, and places them in a work queue for the servicing team to enter.
After two months, the team asks to automate one change type: updating a correspondence address where the customer has confirmed it through the secure portal. The society allows the agent to enter that one change by screen, under its own login, limited to a set number per hour, with each entry checked against the draft afterwards. Everything else stays in the queue. Working through that queue is described in how to work an operations exceptions queue with an AI agent.
Who answers for the result?
The process owner, as with any agent. Without an API, they also own a few extra things: how fresh the data must be, which changes may go through the screen, and who checks screen automation after any system update. Technology owns the plumbing, but the decision to accept the trade-offs belongs to the business.
What controls make it safe?
- The agent's own login on any system it touches, even by screen.
- Rules checked before the screen, never relying on the target system to catch errors.
- Rate limits set in the agent platform where no gateway exists.
- Post-entry checks comparing what was entered against what was drafted.
- Freshness checks so the agent refuses to act on an export older than allowed.
- A stop switch the team lead can use without IT.
The deployment stages are the same whatever the interface; see deploying an AI agent: train, shadow, certify, widen.
Questions people ask
Is screen automation reliable enough for regulated work?
For narrow, well-tested changes with checks after entry, it can be. For anything that moves money, prefer a work queue and a person.
Can the agent read a system by screen too?
Yes, and that is safer than writing. Watch for screens that show partial data or truncate values.
Should we wait for an API before starting?
Usually not. Starting with reading and drafting into a queue gives value at once and shows which writes are worth an API.