Four things matter more than code quality. Actions have to be nameable rather than implicit. Permissions have to be enforced by the system rather than assumed by the caller. Writes have to tolerate a retry without duplicating work. And what happened has to be reconstructable afterwards from a record the code actually writes.
Nameable actions
An agent proposes discrete things. If the only way to describe a business action is a sequence of screen interactions, there is nothing for a proposal to refer to and nothing for an approval to authorise.
Look for whether your system can express an operation as a single named call with explicit arguments. Where it can, that operation is a candidate for agentic work immediately. Where a business action is spread across several unrelated writes with no transaction around them, the agent inherits that fragility, and a partial failure becomes a state nobody can describe.
This is usually the quickest readiness check available. Ask an engineer to list the ten operations the business cares about most, then ask which of them exist as one callable thing. The gap in that answer is the work.
Permissions the system enforces itself
Agentic work fails badly when access is decided by the caller. If a service account holds broad rights and each application is trusted to restrict itself, an agent will eventually reach data it should not, because it is exploring a space a human would not.
What you want is enforcement below the agent: row-level rules, per-tenant scoping, or an authorisation service that refuses the call regardless of who asks. Then a mistake in the agent produces a refusal rather than a breach. That distinction is the subject of how you stop an agent reaching data it should not see.
Retry safety and a usable record
Agents retry. Networks fail mid-call, a model returns malformed output, an orchestrator restarts. If a repeated write creates a second record, the retry is the outage.
Idempotency does not require a rewrite. A client-supplied key on the write, or a uniqueness constraint that turns a duplicate into a refusal, is often enough and is worth adding before anything else.
The record matters just as much. Ask whether your system stores who initiated a change, what it changed from and to, and when. Many systems store the current state and nothing about how it got there. An agent makes that gap expensive, because the question "why did this happen" arrives more often and the answer has to be reconstructable. What an audit trail needs to contain covers the shape of that record.
What genuinely does not matter as much as people expect
Test coverage, language, framework age, and code tidiness matter less here than the four properties above. A well-tested system with no nameable operations is harder to work with than an untidy one that exposes clear commands and enforces its own permissions.
Documentation matters less than people expect too, because an agent can read the code and the schema. What it cannot read is an unwritten rule that lives in an operator's head, and those are the rules that cause trouble. Where such a rule exists, the work is to make it explicit somewhere the system can enforce it.
Frequently asked questions
Do we need good test coverage before starting?
Not to start reading, and not to draft proposals. Coverage matters when the write path opens, because that is when a regression changes real data. A sound sequence is to begin with read-only work, add tests around the specific operations you intend to expose, and open those one at a time rather than waiting for a coverage target.
Our system is a single large application. Is that a blocker?
Usually not. Size is less important than whether operations can be named and permissions enforced. A large application with clear service boundaries inside it is workable. What causes difficulty is an application where business rules live in the user interface layer, because then no callable operation carries the rule the business depends on.
How do we assess readiness without a long consulting exercise?
Take one workflow you would want an agent to handle and trace it end to end. Ask whether it can be triggered by one named call, whether the system refuses an unauthorised attempt on its own, whether a repeat is safe, and whether the change is recorded. Those four answers tell you most of it.
