Editorial policy 1.0 · Effective 3 September 2026

What belongs in an agent-first directory

We include products, infrastructure, and protocols that give AI agents a material role or capability. Each listing must have public evidence for its claimed role and fit exactly one classification.

Working definition

Agent-first means the agent role is material

A product is agent-first when an AI agent is a core actor, or when the product removes a substantial constraint from an agent workflow. A protocol is agent-first when it gives independent systems a documented way to let agents communicate, transact, identify, coordinate, or interact. Merely exposing an API that an agent could call is not enough.

Agent-native

Agents are core participants

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 materially empowers agents

The product gives agents meaningful capabilities or removes a material constraint from agent-first workflows, even when people and conventional applications can also use it.

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

Protocols let agents participate online

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.

Evidence-based inclusion test

Evidence before labels

Identify the agent role. State what agents do and why that role is material.
Use first-party evidence. Verify the claim in product docs, a maintained repository, a specification, or the official website.
Test materiality. Generic API access or ordinary automation is not enough; the capability must substantially improve an agent-first workflow.
Choose one classification. Select the most specific class supported by the evidence, not the most flattering label.

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

Compatibility alone is insufficient

A generic developer tool that an agent could happen to call.
A thin MCP or API wrapper with no material agent-first capability.
Unsupported marketing claims without first-party product evidence.
A conventional workflow with “AI” or “agent” added only as positioning.

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

How this policy is applied

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.

Have an evidence-backed tool that passes the test?

Read the submission guide