A platform is agent-first when an AI agent can finish meaningful work in it — find the right capability, understand what it does, act through a programmatic interface, stay inside scoped permissions, survive failures and leave evidence of what changed — while people keep the ability to approve and stop. An API is where that starts, not where it ends.
- Judge it per workflow. A platform can be strong for one delegated task and unusable for the next.
- Eight capabilities, four questions. Can the agent understand, act, stay under control, and prove what happened?
- No universal extras. MCP, long-term memory and asynchronous execution can matter; none is required everywhere.
- Evidence over scores. Record status, evidence, gap and owner for each test instead of a single number.
01What is an agent-first platform?
An agent-first platform is a software platform whose relevant capabilities are designed to be discoverable, understandable and operable by AI agents within explicit permission and control boundaries. The definition turns on the word operable. A platform can have an excellent API and still be hard for an agent to use: operations named after a human workflow, identifiers the agent cannot resolve, side effects nobody documented, no way to tell whether a request succeeded.
Agent-first means that the capabilities that matter for delegated work were designed with an agent as one of their operators. It does not require every feature to be available to agents, and it does not remove the human interface: people still configure the platform, review what agents did and step in when needed. The claim is narrower and more useful — for the workflows you intend to delegate, an agent can do the work, and people can see and control how.
“Agent-first” describes a design approach. It is not a certification, a standard or a product category, and it does not mean that the human interface goes away.
This is the third layer of a series. Agent-first design decides what work to delegate, agent-first architecture describes the system that performs it, this guide covers the capabilities the agent operates, and the AI agent development lifecycle keeps the whole arrangement working as it changes.
02Agent-first platform vs related categories
Vendors use overlapping names for different things, so it helps to fix the vocabulary. This guide uses five terms as follows.
| Term | Meaning in this guide | The question it answers |
|---|---|---|
| AI agent platform | Tools and services for building or running agents | Where do we build and run our agents? |
| Managed agent platform | A service that takes over a defined part of hosting and runtime operations for agents | What does the provider operate for us? |
| Agent-first platform | A platform designed so that agents can operate its capabilities | Can an agent do real work here? |
| Agent framework | A library or set of abstractions for constructing agent behavior | How do we construct the agent's behavior? |
| Agent-first product | A product in which an agent performs a significant part of the delegated work | Does the product do the work for its users? |
↔ scroll table
The scopes overlap, and naming varies from vendor to vendor. A CRM can host its own agents, expose its records and workflows to outside agents, and ship an agent that does work for its users — all three at once. What matters for evaluation is which of those roles you are relying on.
If your question is where to build and run agents, the vendor landscape is mapped in Managed Agent Platforms. If it is whether agents can do work inside a platform you own or buy, the rest of this guide is for you.
03What makes a platform agent-operable?
Consider an agent working in a CRM. It needs more than a screen it can navigate. It has to identify the correct account among similar ones, understand which actions are available and what each one changes, perform an authorized operation, and confirm what actually changed. People still need ways to review, approve and stop consequential work.
Most platforms were not designed with that operator in mind. Their interfaces assume a person who can read context off a screen, recover from an ambiguous error by looking around, and remember why they clicked. An agent has none of that unless the platform provides it: stable identifiers, operations with documented effects, errors that say what happened, and a way to check the outcome.
A platform for building agents may provide the runtime for this workflow. The CRM itself also needs suitable capabilities for the agent to operate it reliably — and that is what the capability model below describes.
04The auxfirst capability model
The auxfirst Agent-First Platform Capability Model names eight capabilities and groups them under the four questions an evaluator should be able to answer for any delegated workflow. It is an analytical model developed from auxfirst's work, not an industry standard.
| Capability | What it covers | Example evidence |
|---|---|---|
| 01 · Capability discovery | How the agent learns which operations exist and what parameters they take | A tool catalog or an API description |
| 02 · Meaningful action coverage | Whether the agent can complete a real workflow, not just read | The set of operations needed to finish the task |
| 03 · Structured context | Whether the agent gets the right data and its meaning | Schemas, identifiers, relationships, timestamps |
| 04 · Identity and scoped authority | Whether access is attributed and limited | Access scopes, the identity of the actor, revocation |
| 05 · Operational state | Whether a task can be inspected and resumed | Status, task identifiers, checkpoints where needed |
| 06 · Reliable execution | How delays and failures are handled | Timeouts, retries, deduplication, events |
| 07 · Human control | How people approve and interrupt the work | Approval, escalation, cancellation |
| 08 · Evidence and inspection | How execution and its effect can be verified | Operation results, change history, audit trail |
↔ scroll table
Discovery and structured context
An agent cannot use what it cannot find or cannot interpret. A machine-readable description — an OpenAPI document, a tool catalog — tells it which operations exist; stable identifiers, typed fields and timestamps tell it what a record means. The common failure is ambiguity: two accounts with the same name, a status field with undocumented values.
Action coverage and reliable execution
Read access is not agency. The platform has to expose the operations a workflow needs from start to finish, and they have to behave predictably under failure: clear errors, safe retries and protection against duplicate writes, for example through idempotency keys or request identifiers.
Identity, scoped authority and human control
Actions should be attributable to a specific agent acting for a specific person or role, limited by scope, and revocable without switching everything else off. Where a workflow needs it, the platform supports approval of a specific action and cancellation of work in progress.
Operational state and evidence
Long-running work needs a status someone can check — an operation identifier to poll, or an event when it completes. Google's AIP-151 describes one well-established pattern. After the fact, someone must be able to see which calls were made, what they returned and what actually changed.
- Full parity between the interface and the API. Only the capabilities needed for the delegated tasks are assessed.
- Long-term memory or asynchronous execution for every operation. Both matter for some workflows and not for others.
- MCP. The Model Context Protocol can be part of the answer — its current specification includes an optional extension for long-running tasks — but exposing an MCP server does not, on its own, demonstrate complete permissions, context or reliable execution. The specification itself notes that the protocol cannot enforce its security principles; implementors have to.
05Illustrative platform examples
Three hypothetical examples — not descriptions of specific products — show how the same model reads in different contexts. Named products change quickly, so this guide stays at the level of capabilities.
Follow up an account
An agent reads the account's context, creates a follow-up task and checks that the task exists. It leans on structured context to pick the right account among near-duplicates, on scoped authority to create tasks without touching deal values, and on evidence to confirm the result.
Prepare a change
An agent prepares a code change, runs validation and hands the result to a reviewer. It leans on action coverage to branch, commit and trigger checks, on operational state for a pipeline that runs for minutes, and on human control — the review is the approval.
Respond to an incident
An agent analyzes an incident, proposes a remediation and escalates when the change exceeds its limit. It leans on discovery of the available runbook actions, on reliable execution under partial failure, and on an escalation path that carries the evidence to the on-call engineer.
06The Agent-First Platform Test
Run the test against one specific workflow — “an agent follows up stalled opportunities in our CRM”, not “our CRM”. For each of the ten questions, record four things:
There is deliberately no total score. Ten unweighted answers do not add up to a meaningful number, and a single missing capability — no way to revoke access, say — can block a workflow on its own.
07Adapting an existing platform
Most platforms become agent-first by adaptation rather than a rebuild. The route is incremental and starts narrow:
- 01
Choose one specific workflow
One delegated task with a clear owner and outcome. “Agent-ready” in general is not something you can test.
- 02
Map the data and actions it requires
Every read, every write and every decision point — and the identifiers that connect them.
- 03
Expose the missing interfaces
Add or document the operations the workflow needs, with their effects stated.
- 04
Define permissions and approval rules
Scopes for the agent's identity; which actions need approval, and from whom.
- 05
Add statuses, identifiers and error handling
So that work can be tracked, retried safely and resumed.
- 06
Test execution and human intervention
Run the workflow end to end, including approval, rejection, cancellation and failure.
- 07
Expand the scope based on results
Add the next workflow when the evidence from the first justifies it.
The same sequence works whether the agents are your own or your customers'. For B2B products that want agents to act inside the user's browser session, WebMCP for B2B SaaS covers one emerging route; for the product side of the change, see Agent-First Design for Legacy SaaS Retrofits.
08Build, buy or combine?
If the platform is yours, the question is how to make it operable. If you are choosing the layer that runs the agents, the question is whether to build it, buy a managed service, or combine the two. Compare the options on the same criteria, against a specific workflow — there is no universal winner.
| Criterion | Build | Buy | Combine |
|---|---|---|---|
| Time to the first workflow | Longest; everything is yours to assemble | Shortest, if the service fits the workflow | Moderate; buy the runtime, build the edges |
| Operational responsibility | All of it, including runtime reliability | Shared; the provider runs a defined part | Split along a line you must document |
| Integrations | Whatever you build | What the provider supports | The provider's, plus your own adapters |
| Access and isolation | Fully under your control | Governed by the provider's model | Depends on where sensitive data flows |
| Cost of a completed task | Your infrastructure and your people | Provider pricing plus your integration | Both — measure per completed task |
| Export of state and evidence | Native | Check formats and completeness | Check at every boundary |
| Dependence on a vendor | Low | Higher | Moderate, concentrated in the bought layer |
| Skills to maintain | Runtime, security and operations | Integration and vendor management | Both, in smaller measure |
↔ scroll table
Whichever you choose, measure the cost of a completed task rather than a single call, and confirm you can take the state and the evidence with you. The managed options are mapped, with links to each provider's documentation, in Managed Agent Platforms.
09Frequently asked questions
What is an agent-first platform?
An agent-first platform is a software platform whose relevant capabilities are designed to be discoverable, understandable and operable by AI agents within explicit permission and control boundaries. For the workflows you intend to delegate, an agent can find the right operations, act through them, stay within scope and leave evidence, while people can approve and stop the work.
How does it differ from an AI agent platform?
An AI agent platform provides tools and services for building or running agents. An agent-first platform is one that agents can operate: its records, workflows and actions are usable by an agent within clear boundaries. One product can play both roles, but offering one does not establish the other.
Is an API enough to make a platform agent-first?
An API is the starting point. An agent also needs to discover the right operations, understand their parameters and effects, act under a scoped identity, handle failures without duplicating work, and confirm what changed. Many APIs were designed for developers who read documentation and debug by hand, and they leave those gaps open.
Does an agent-first platform need MCP?
No. The Model Context Protocol is a useful way to expose tools and context to agents and can reduce integration effort. It does not, on its own, prove that permissions are scoped, context is complete or execution is reliable. Assess those capabilities whatever the interface.
Can an existing SaaS platform become agent-first?
Yes, usually by adaptation rather than a rebuild. Start with one workflow, map the data and actions it needs, expose what is missing, define permissions and approval rules, add statuses, identifiers and error handling, test with people in the loop, then expand based on results.
Do agents replace the user interface?
No. People still configure the platform, delegate work, review outcomes, approve consequential actions and step in when something goes wrong. The interface shifts toward inspection, approval and intervention for the delegated workflows, while the rest of the product can stay as it is.
Does every workflow need persistent memory?
No. Many delegated tasks need only the context of the task and its execution state. Persistent memory helps when the work depends on history across tasks, such as account preferences, and it brings retention and correction decisions with it. Decide per workflow.
How should enterprises evaluate agent-first capabilities?
Against a specific workflow, with evidence. For each of the ten questions in the Agent-First Platform Test — discover, understand, read, act, identify, limit, continue, inspect, recover, escalate — record a status, the evidence, the gap and an owner. Avoid single scores: one missing capability can block a workflow.
10Terms used on this page
- Agent-first platform
- A software platform whose relevant capabilities are designed to be discoverable, understandable and operable by AI agents within explicit permission and control boundaries.
- Agent-operable
- Usable by an AI agent to complete delegated work: discoverable, understandable, actionable within scoped permissions, and verifiable afterwards.
- AI agent platform
- Tools and services for building or running agents.
- Managed agent platform
- A service that takes over a defined part of hosting and runtime operations for agents.
- Agent framework
- A library or set of abstractions for constructing agent behavior.
- Agent-first product
- A product in which an agent performs a significant part of the delegated work.
11Sources and further reading
Standards and specifications cited on this page
- Model Context Protocol specification, version 2026-07-28: resources, prompts and tools, the optional Tasks extension, and the security principles left to implementors
- OpenAPI Initiative — OpenAPI Specification: machine-readable descriptions of HTTP APIs
- JSON Schema: describing and validating the structure of data
- Google — AIP-151: Long-running operations: status and results for work that outlasts a request
- Google — AIP-155: Request identification: request identifiers that make retries safe
- IETF — The Idempotency-Key HTTP Header Field (Internet-Draft)
- IETF — RFC 9110, 202 Accepted: acknowledging work that has not finished yet
- IETF — RFC 6749, access token scope, and RFC 7009, token revocation
- IETF — RFC 8693: OAuth 2.0 Token Exchange: acting on behalf of another party
- CloudEvents: a common format for describing events
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency: minimal permissions and authorization enforced outside the model
- OpenTelemetry — GenAI semantic conventions: model, agent and MCP activity as telemetry
The agent-first series
- Agent-first design — what to delegate, and how people supervise it
- Agent-first architecture — the reference model for the system that performs the work
- AI agent development lifecycle — how the system is built, released, run and retired
Related on auxfirst
- Managed Agent Platforms — hosted agent platforms mapped, with links to each provider's documentation
- Agent-First API Design — principles for APIs that autonomous agents can use safely
- WebMCP for B2B SaaS — making the agent a guest in your product
- Agent-First Design for Legacy SaaS Retrofits — converting copilot-era products without a rewrite
- the Action Heat Ladder — grading actions by consequence before granting autonomy
Method · This guide presents auxfirst's working model for agent-first platforms. It combines established API, identity and operations practice with our approach to delegation, authority and human supervision. The capability model and the ten-question test are analytical frameworks, not an industry standard, and the test deliberately produces no score. The three examples are illustrative, not descriptions of specific products. External sources checked on 13 September 2026.
Preparing your platform for agent-operated workflows?
Work with auxfirst to identify gaps in tool access, context, permissions and operational control. For one workflow end to end, the fixed-price engagement is an AI agent readiness assessment.