Agent Readiness Scorecard · Can agents actually operate your systems?

01 / 20Discovery
Can an agent find out what your systems can do without a human explaining it?
No machine-readable description existsSome APIs are documented for humansCapabilities are discoverable from a published schema or manifest
02 / 20Discovery
When a capability changes, how does a calling agent find out?
It does not — things break and someone investigatesWe version and announce changes to known consumersVersioning is in the contract and consumers can detect it at call time
03 / 20Interfaces
Are the operations an agent would need available as APIs rather than screens?
Core workflows only exist in the UISome are exposed, with gaps that need a personThe workflows that matter are fully available programmatically
04 / 20Interfaces
Do you expose an MCP server or an equivalent agent-facing interface?
NoAn experiment exists, untested against the current specYes, and it is tested against the published spec
05 / 20Interfaces
Are side effects described well enough that a caller knows what an operation will change?
No — you have to read the implementationDocumented in prose for most operationsDeclared in the schema, including whether the call is safe to retry
06 / 20Identity
Can you tell which agent performed an action?
Everything runs as a shared service accountAgents share a few accounts by environment or teamEach agent has its own identity, distinguishable in logs
07 / 20Identity
When an agent acts for a person, is that relationship recorded?
No — the agent's own identity is all that is recordedSometimes, in application logsYes, delegation is explicit and carried through to the destination system
08 / 20Identity
How are agent credentials issued and rotated?
Long-lived keys, rotated when someone remembersRotated on a scheduleShort-lived, scoped credentials issued per task
09 / 20Permissions
Is an agent's authority narrower than the human it works for?
No — it inherits everything that user can doPartly, through a restricted roleYes, scoped to the specific operations the task requires
10 / 20Permissions
Do irreversible actions — payments, deletions, outbound messages — require approval?
NoFor some, by convention rather than enforcementYes, enforced at the system that performs the action
11 / 20Permissions
How quickly can you revoke an agent's access entirely?
We are not sure where all its credentials areHours, with manual work across several systemsMinutes, from one place
12 / 20Observability
Can you reconstruct what an agent did on a specific day last month?
NoPartially, by correlating several log sources by handYes, end to end, including the tools it called
13 / 20Observability
Do you verify outcomes in the destination system, or trust the agent's report?
We trust the reported statusWe spot-check manuallyOutcomes are confirmed independently of the agent
14 / 20Observability
Do you know what a completed unit of agent work costs?
We see a total billCost by team or by modelCost attributed to a unit of work, including retries and failures
15 / 20Security
Have you assessed prompt injection against the agent's tool authority?
NoWe have discussed itYes, and untrusted content cannot reach high-authority tools unchecked
16 / 20Security
Can an agent reach data belonging to a tenant or user it is not acting for?
Possibly — isolation is enforced in application code onlyUnlikely, but it has not been testedNo, isolation is enforced below the application and tested
17 / 20Security
Are the agent's outbound destinations restricted?
No egress controlsNetwork-level controls onlyExplicit allowlist of tools and destinations per agent
18 / 20Reliability
What happens when a tool call fails halfway through a multi-step task?
Unclear — partial state is left behindIt retries, and we clean up manually when that failsDefined compensation and stop conditions
19 / 20Reliability
Are your write operations safe to retry?
No — a retry can duplicate the effectSome areYes, writes are idempotent by key
20 / 20Reliability
Is there a named owner accountable for each agent in production?
NoA team owns them collectivelyYes, a named person per agent

Your result

—/ 100

Answer the questions and the band appears here. The score is computed in your browser — nothing is sent anywhere, so there is no report to email you and nothing for us to store.

This is self-reported, so treat it as a starting point rather than evidence. The full assessment runs against your actual systems.

Bands

What the score means.

The middle band is the one to watch. Enough capability to put agents into production, not enough evidence to know what they did.

0–39
Not ready
Agents acting against these systems would be operating on trust. The gaps are structural rather than cosmetic: start with identity and permissions, because everything else depends on being able to say who did what.
40–64
Early
The interfaces are coming along but the controls behind them have not caught up. This is the most common and most dangerous band — enough capability to put agents into production, not enough evidence to know what they did.
65–84
Workable
You could run agents here and defend the decision. The remaining gaps are usually verification and cost attribution: you can see what was attempted, but not always confirm what changed.
85–100
Ready
Unusually well prepared. At this level the useful work is narrowing authority further and proving outcomes independently, rather than adding more capability.

Scored lower than you expected?

That is the normal result, and it is usually identity and verification rather than interfaces. Thirty minutes is enough to work out what to fix first.

Book a 30-min discovery call Send a note instead

Can agents actually operate your systems?

What the score means.

Not ready

Early

Workable

Ready

Scored lower than you expected?