What an agent needs from your systems before it can do anything
An agent can only act through the doors your systems already have. Most of the build is checking which doors exist.
Updated September 2026
- An agent needs a way in, its own identity, and a record of what it did. Most estates are missing at least one.
- A shared human login is the most common shortcut and the one that fails an audit.
- Where there is no API, screen automation is a legitimate answer — with a maintenance cost attached.
- The exception path matters more than the happy path, because that is where the agent hands work back.
Most agent projects are scoped on what the agent should decide. The constraint is usually simpler: what it can actually reach, and what it is allowed to do when it gets there.
1. A way in
An API is ideal — documented, versioned, with a test environment. Failing that, a supported integration, a file interface, or a database view.
Where none of those exist, screen automation is a legitimate answer. It is how a great deal of useful work gets done in systems that have no other door. It carries a maintenance cost, because the automation breaks when the screen changes, and that cost should be in the business case rather than discovered later.
2. Its own identity
The agent needs an account of its own, with permissions scoped to exactly what it does. Not a shared login, not a person’s credentials, not an administrator account because it was quicker.
This is the most common shortcut in pilots and the one that fails an audit. It also makes the agent’s actions indistinguishable from a person’s, which removes your ability to answer the only question that matters after something goes wrong: who did this.
3. A record of what it did
Every action logged, attributable, and readable by someone who was not involved. What it read, what it changed, what it decided and on what basis.
This is what makes an agent reviewable. It is also what makes it fixable — without a trail, diagnosing a bad outcome means guessing.
4. Somewhere to put the work it cannot finish
The exception path is the part that decides whether an agent is usable. When confidence is low, when data is missing, when something does not match, the work has to go somewhere a person will actually see it, with enough context to act on without redoing the agent’s work.
A queue nobody monitors is worse than no agent, because the work stops silently.
5. Limits that are enforced outside the agent
Approval thresholds, segregation of duties, payment release. These should stay exactly where they are today, enforced in the systems that enforce them now.
An agent that prepares work for approval fits inside existing controls. An agent that has been given the approval rights to be faster has changed your control environment, and that is a decision for whoever owns those controls rather than for the build.
6. A test environment that resembles production
Agents behave differently against real data volumes, real edge cases and real permissions. A test environment with fifty clean records will not reveal what the estate will do to it.
Where a realistic test environment does not exist, that is usually the first project — and it benefits far more than the agent.
What this means for sequencing
The gap between “we want an agent to do this” and “the agent can do this” is mostly the six items above. They are ordinary integration and access work, they benefit everything else that touches those systems, and they are why an agent program often starts with something that does not look like AI at all.
The practice behind it.
Wondering if your systems can carry one?
We will look at what the agent would need to reach, and tell you what has to exist first.