What makes a product agent-first?
The person who chooses a product and the software that uses it no longer have to be the same actor. That changes how products are discovered, evaluated, and operated.
A familiar need. A different user.
A person needs an inbox to receive messages. An agent does, too—but it needs to create that inbox, retrieve a conversation, and respond through software interfaces. AgentMail is a concrete example of that shift. The task is familiar; the interface and operator change.
Browsers, memory, compute, and payments follow a similar pattern. A research agent needs fresh evidence. A coding agent needs somewhere to run its code. A purchasing agent needs authority to spend within a person's instructions.
Discover → evaluate → approve → act
Imagine asking an agent to find a service for a specific job. It compares capabilities, checks documentation, and presents an option. You approve the choice and define its permissions. The agent then invokes the service in the background and returns a result.
Human control can mean approving every consequential action, or granting a limited budget and scope in advance. Good product design makes that boundary explicit and makes it possible to inspect what happened afterward.
Four things builders need to make legible
- Capabilities. What can the product do, what input does it require, and what output or error should an agent expect?
- Access. Who is the agent acting for, and which operations is it allowed to perform?
- Cost. What will the operation cost, what limits apply, and when is additional approval required?
- Evidence. Can the human inspect the result, trace a change, and recover when something goes wrong?
These questions extend beyond adding a chatbot. The product itself becomes a dependable tool another piece of software can use. APIs, SDKs, command-line tools, and protocols such as MCP are different ways to expose that capability.
Agent native and agent ready
We use agent native for products centered on capabilities consumed by agents: browser infrastructure, persistent memory, search, or dedicated inboxes. We use agent ready for broader platforms with documented agent-facing tools or services. These are editorial labels, not certifications or judgments of quality.
Both belong in this directory. New companies can build around agents from the start; established companies can make useful capabilities accessible to them. Each listing explains the specific reason it is included.
Explore the actual products
Start with a task. Compare the tools in that category. Read the official documentation before choosing an integration. Popularity can help surface recognizable products, but a search-traffic estimate cannot tell you whether a product fits your agent's needs.
Further reading
This guide is an original editorial synthesis. For the underlying ideas, read Mathias Biilmann on agent experience, Anthropic on designing effective tools, and Stripe on machine payments.