Editorial policy 1.1 · Effective 22 October 2026
Only tools built for agents belong in this directory. Product fit is decided before evidence review. Passing fit is necessary, not acceptance: each listing must then have public evidence for its claimed role and fit exactly one classification.
Working definition
Judge the intended user, core job, and operating model. Agent-oriented infrastructure, protocols, and agent-builder tools can qualify when designed for agent operation; exclusive agent use or agent-only origins are not required. An AI agent serving humans is not, by itself, a tool built for agents. A human-first app with REST, MCP, or SDK access does not qualify, regardless of integration depth or tool count.
Agent-native
The product's core abstraction, actor, runtime, or participant is an agent. Removing agents would fundamentally change what the product is.
Example: an orchestrator that assigns work across agent runtimes, or a service that provisions persistent communication identities for agents.
Counterexample: a conventional task manager or inbox with a generic API that an agent can call.
Agent-enabling
Infrastructure or builder tooling is designed for agent operation and gives agents meaningful capabilities, even when people and conventional applications can also use it. This classification cannot bypass product fit or rescue a human-first app through its integrations.
Example: an isolated execution environment designed for agent-controlled code runs, or a memory layer that preserves and retrieves agent state across sessions.
Counterexample: a general virtual machine, database, or storage API with no substantive agent-oriented capability.
Agent internet protocol
An interoperable protocol or standard enables agents to communicate, transact, identify, coordinate, or interact across the internet.
Example: an open specification for agent-user events or machine-readable payment negotiation with independently implementable messages and behaviour.
Counterexample: a vendor-specific integration endpoint or proprietary payload without an interoperable specification.
Product-fit-first inclusion test
Before reviewing any evidence, use only the product description and operating model, plus canonical homepage positioning if necessary. Do not inspect evidence arrays, documentation, MCP details, implementation, pricing, licence, or validation results at this stage. Record the intended user, core job, and why it is or is not built for agents, with one decision:
Category and classification answer different questions. A category describes the capability area; a classification explains why the listing belongs in an agent-first directory.
What does not qualify
A coding-agent orchestrator qualifies only when the system owns a material lifecycle across agent runs. Evidence must show task assignment, isolation, retained or shared state or validation evidence, and a completion, review, or landing gate separate from execution. Merely launching a single agent, supplying prompts, wrapping an API or MCP server, adding agent compatibility, or providing ordinary developer automation is insufficient.
Classification describes why an accepted listing belongs. It is not a quality score, endorsement, or substitute for reviewing security, reliability, pricing, and fitness for a particular use.
Accountability
Read the editorial standards for source hierarchy, conflicts, sponsorship, ordering, and review cadence. If a published claim is wrong or a product has changed, use the corrections and appeals process. Policy changes are versioned from the effective date shown above. This product-fit gate takes precedence over category or contribution guidance suggesting internal autonomous agents alone qualify. Historical reassessments and public corrections require separate owner approval; this policy update authorizes no existing-listing changes.
Have an evidence-backed tool that passes the test?
Read the submission guide