M
Every week, more SaaS products announce that they are “agent-ready.” Usually, this means the product has a public API or now ships an MCP server.
Both are meaningful progress. Neither, by itself, proves that an agent can complete real work reliably.
APIs are usually designed for developer-mediated integration. A developer reads the documentation, interprets ambiguous fields, handles undocumented constraints, and defines what “done” means. An AI agent does not automatically inherit that judgment. It must choose the right tool, generate valid arguments, sequence multiple calls, and determine whether the requested outcome was actually achieved.
MCP improves how tools are exposed to models through a common protocol. That is valuable. But standardizing access is not the same as verifying execution.
This is why “Is this SaaS agent-ready?” cannot be answered by checking whether an interface exists. At KanseiLINK, we separate the prerequisites for agent access from three deeper dimensions of readiness: Compatibility, Execution, and Trust.
Before an agent can attempt a task, it must be able to find and interpret a usable interface.
This prerequisite layer includes:
At KanseiLINK, we have been mapping agent-readiness signals across more than 11,000 SaaS products. That broad mapping is useful for understanding whether agent-facing interfaces are present and interpretable. But it is important to state exactly what this evidence proves.
An interface survey can show that a service appears reachable and understandable to an agent. It cannot prove that an agent will complete a real business task correctly.
That distinction matters because interface availability is only the beginning of agent readiness.
Execution is where readiness claims meet reality: given a defined business task, can an agent reach the correct end state?
Consider the instruction: “Find the unpaid invoice for customer X and send a reminder.”
The agent may need to:
Every API call could return a successful status while the overall task still fails. The agent might select the wrong invoice, perform the steps in the wrong order, stop halfway, or retry an action that should occur only once.
Execution therefore needs evidence that is different from connectivity evidence:
This evidence cannot be inferred from documentation or an interface survey. It requires running defined tasks and inspecting their outcomes.
An agent may be capable of completing a task and still be unsafe to deploy.
Trust covers the operational controls that make agent actions dependable:
Trust failures often appear only after deployment, when actions affect a real ledger, inbox, customer record, or production system. They are usually invisible in a happy-path demo.
Compatibility is not simply whether an interface can be parsed. It is whether the same defined task remains executable when a relevant part of the agent stack changes.
For example, using the same SaaS account, permissions, task definition, and expected outcome:
If the service, task, environment, and success criteria are not held constant, the result is not a meaningful compatibility comparison. A model choosing a different SaaS product is product-selection variance, not evidence about compatibility with one interface.
Compatibility matters because an integration that works only with one model, prompt, or client configuration may be a successful prototype but a fragile production dependency.
The most important discipline is not allowing evidence from one stage to stand in for another.
Level 0 covers interface presence, authentication paths, schema and tool-description quality, security hygiene, and basic call behavior. It can be measured broadly and updated continuously across many services.
It answers:
It does not establish end-to-end Execution, Trust, or Compatibility.
Deeper evaluation uses a fixed TaskSpec, controlled accounts and permissions, repeated end-to-end runs, external outcome checks, negative tests, and comparable model or runtime configurations.
It asks:
The failure mode to avoid is claim inflation: presenting Level 0 breadth as if it were Level 1 depth. A directory of thousands of services with interface data is a useful map. But “we found an interface that responds” and “we verified that agents complete this task correctly across repeated runs” are different claims.
Any evaluation, including ours, should label the level of evidence behind its conclusions.
The required depth should depend on risk.
A read-only agent that retrieves public documentation may need strong access and interpretation but relatively modest operational controls. An agent that sends customer communications, changes permissions, creates payments, or updates production data needs much stronger Execution and Trust evidence.
This does not make interface standards or directories unimportant. APIs, MCP servers, and discovery layers are necessary infrastructure. The mistake is treating them as proof of a capability they were not designed to establish.
“Agent-ready” should not be a binary badge that a product awards itself after shipping an interface. It should be a set of explicit, falsifiable claims supported by evidence.
For SaaS builders, the sequence is practical:
For buyers, platform teams, and evaluators, the question should always be: which layer does this readiness claim cover, and what evidence supports it?
The ecosystem does not need more binary badges. It needs verifiable stages.
Both are meaningful progress. Neither, by itself, proves that an agent can complete real work reliably.
APIs are usually designed for developer-mediated integration. A developer reads the documentation, interprets ambiguous fields, handles undocumented constraints, and defines what “done” means. An AI agent does not automatically inherit that judgment. It must choose the right tool, generate valid arguments, sequence multiple calls, and determine whether the requested outcome was actually achieved.
MCP improves how tools are exposed to models through a common protocol. That is valuable. But standardizing access is not the same as verifying execution.
This is why “Is this SaaS agent-ready?” cannot be answered by checking whether an interface exists. At KanseiLINK, we separate the prerequisites for agent access from three deeper dimensions of readiness: Compatibility, Execution, and Trust.
Before Readiness: Access and Discoverability
Before an agent can attempt a task, it must be able to find and interpret a usable interface.
This prerequisite layer includes:
- Access and authentication: Is there an API or MCP interface? Can an agent authenticate with an appropriate scope? Is a human-only consent step required?
- Machine-readable schemas: Are request and response schemas complete and accurate, or does critical behavior exist only in prose documentation?
- Tool discoverability: Do tool names and descriptions give a model enough information to distinguish similar operations?
- Actionable errors: When a call fails, does the response help the agent recover, or does it expose only an opaque error?
At KanseiLINK, we have been mapping agent-readiness signals across more than 11,000 SaaS products. That broad mapping is useful for understanding whether agent-facing interfaces are present and interpretable. But it is important to state exactly what this evidence proves.
An interface survey can show that a service appears reachable and understandable to an agent. It cannot prove that an agent will complete a real business task correctly.
That distinction matters because interface availability is only the beginning of agent readiness.
Execution: Can the Agent Complete the Task?
Execution is where readiness claims meet reality: given a defined business task, can an agent reach the correct end state?
Consider the instruction: “Find the unpaid invoice for customer X and send a reminder.”
The agent may need to:
- Identify the correct customer among similar records.
- Find the relevant unpaid invoice.
- Select the appropriate reminder action.
- Send the reminder once.
- Verify that the action completed.
Every API call could return a successful status while the overall task still fails. The agent might select the wrong invoice, perform the steps in the wrong order, stop halfway, or retry an action that should occur only once.
Execution therefore needs evidence that is different from connectivity evidence:
- Task-level success: The unit of measurement is whether the business task reached the correct end state, not whether an individual call returned HTTP 200.
- Repeated runs: One successful demo does not establish a reliable capability. The same task should be tested repeatedly under controlled conditions.
- Failure recovery: If one step fails, does the agent resume safely, restart unnecessarily, or report success despite an incomplete outcome?
- Outcome verification: Success should be checked against the external system’s state, not accepted from the model’s own self-report.
This evidence cannot be inferred from documentation or an interface survey. It requires running defined tasks and inspecting their outcomes.
Trust: Can the Agent Act Safely?
An agent may be capable of completing a task and still be unsafe to deploy.
Trust covers the operational controls that make agent actions dependable:
- Permissions and scope: Can the agent operate with least privilege, and are out-of-scope actions reliably rejected?
- Duplicate execution: Can retries create duplicate payments, messages, or records? Does the service support idempotency or another way to detect duplicates?
- Partial failure: When a multi-step workflow fails midway, is the resulting state visible and recoverable?
- Auditability: Can an operator determine which agent acted, under whose authority, what it changed, and what result followed?
- Verified outcomes: Can the system independently confirm that the intended side effect occurred?
Trust failures often appear only after deployment, when actions affect a real ledger, inbox, customer record, or production system. They are usually invisible in a happy-path demo.
Compatibility: Does Performance Survive a Change in Model or Configuration?
Compatibility is not simply whether an interface can be parsed. It is whether the same defined task remains executable when a relevant part of the agent stack changes.
For example, using the same SaaS account, permissions, task definition, and expected outcome:
- Does a different model select the same correct tool?
- Do models interpret the same schema consistently?
- Does a change in tool ordering or description cause a large drop in task completion?
- Does the workflow remain stable across supported agent runtimes or MCP clients?
If the service, task, environment, and success criteria are not held constant, the result is not a meaningful compatibility comparison. A model choosing a different SaaS product is product-selection variance, not evidence about compatibility with one interface.
Compatibility matters because an integration that works only with one model, prompt, or client configuration may be a successful prototype but a fragile production dependency.
A Staged Evaluation Model
The most important discipline is not allowing evidence from one stage to stand in for another.
Level 0: Interface Baseline
Level 0 covers interface presence, authentication paths, schema and tool-description quality, security hygiene, and basic call behavior. It can be measured broadly and updated continuously across many services.
It answers:
It does not establish end-to-end Execution, Trust, or Compatibility.
Level 1 and Beyond: Task-Based Assurance
Deeper evaluation uses a fixed TaskSpec, controlled accounts and permissions, repeated end-to-end runs, external outcome checks, negative tests, and comparable model or runtime configurations.
It asks:
The failure mode to avoid is claim inflation: presenting Level 0 breadth as if it were Level 1 depth. A directory of thousands of services with interface data is a useful map. But “we found an interface that responds” and “we verified that agents complete this task correctly across repeated runs” are different claims.
Any evaluation, including ours, should label the level of evidence behind its conclusions.
Not Every Workflow Needs the Same Level of Assurance
The required depth should depend on risk.
A read-only agent that retrieves public documentation may need strong access and interpretation but relatively modest operational controls. An agent that sends customer communications, changes permissions, creates payments, or updates production data needs much stronger Execution and Trust evidence.
This does not make interface standards or directories unimportant. APIs, MCP servers, and discovery layers are necessary infrastructure. The mistake is treating them as proof of a capability they were not designed to establish.
Agent Readiness Should Be Verifiable
“Agent-ready” should not be a binary badge that a product awards itself after shipping an interface. It should be a set of explicit, falsifiable claims supported by evidence.
For SaaS builders, the sequence is practical:
- Make the interface reachable and self-describing.
- Demonstrate that defined tasks complete correctly and repeatedly.
- Add the permissions, idempotency, recovery, audit, and verification controls that make those actions safe.
- Test whether performance remains stable across the models and runtimes the product intends to support.
For buyers, platform teams, and evaluators, the question should always be: which layer does this readiness claim cover, and what evidence supports it?
The ecosystem does not need more binary badges. It needs verifiable stages.