Your AI Product Needs an Agent Catalog, Not Just an API
An API makes your product callable. It does not make your product discoverable.
That distinction is about to matter.
As AI agents take on more work, they need to find the right tool for a task, determine who published it, and connect through the correct protocol. Today, much of that still depends on a developer manually configuring an integration. The capability exists, but the agent cannot reliably find it on its own.
Google and its partners recently announced Agentic Resource Discovery, or ARD, an open specification for publishing, discovering, and verifying agentic resources across the web. Then, on August 6, Google backed Agent Plugins 1.0, a vendor-neutral format for packaging skills and MCP servers so they can travel across compatible clients.
The founder lesson is bigger than either specification.
Your next AI product may need two forms of distribution: one for people, and one for agents.
The missing layer is discovery
Most founders think about an AI integration in terms of execution.
Can the model call the API? Can it use the MCP server? Can it complete the workflow?
Those are necessary questions. But before execution comes discovery.
ARD is designed to help agents answer three different questions:
- Where does the right capability live?
- Which capability matches the task?
- Can the publisher be verified before a connection is made?
The specification introduces two main primitives. A catalog is published by the organization that owns the capabilities. A registry indexes catalogs and helps agents search them. Once a capability is selected and verified, ARD steps aside and the agent connects through the resource’s native protocol.
That separation matters. ARD is not another tool runtime. It is the directory and trust layer that can point an agent toward an MCP server, an A2A agent, an API, a skill, a plugin, or another catalog.
Think of it as search infrastructure for callable software.
Your domain expertise becomes searchable product metadata
This is where domain experts have an advantage.
A generic developer may expose a tool called analyze_document. A healthcare operator knows whether that tool reviews prior-authorization packets, checks missing documentation, or prepares a case for human review. A logistics leader knows the difference between estimating a late shipment and identifying the exact exception that requires intervention.
That language is not marketing decoration. It helps define what the capability actually does.
The ARD publishing guide asks organizations to create an ai-catalog.json manifest and host it at:
https://your-domain.com/.well-known/ai-catalog.json
A catalog entry can include a display name, resource type, URL, capabilities, description, and representative natural-language queries. The guide recommends representative queries so a discovery service can match a user’s intent to the right resource.
For a founder, that creates a useful product exercise. Write down:
- The job your capability performs
- The exact situation that should trigger it
- The inputs it needs
- The result it returns
- The actions it must never take without approval
- Three questions a real buyer might ask before using it
If those answers are vague, your product wedge is probably vague too.
Packaging and discovery are different jobs
The August 6 Agent Plugins announcement makes the architecture easier to understand.
Agent Plugins 1.0 defines a portable directory structure that can package skills and MCP servers together. Its scope is intentionally narrow. It does not define installation, permissions, trust, sandboxing, or distribution.
The announcement describes the layers clearly:
- Find it: Agentic Resource Discovery
- Describe it: AI Catalog
- Package it: Agent Plugins
- Run it: MCP and Agent Skills
You do not need every layer on day one. A single skill for one client may not need a plugin. A private product may not need public discovery. And ARD itself is still evolving; the public specification repository currently labels the work as a draft.
But the direction is useful now. It tells founders to stop treating every integration as one giant, custom connector. Discovery, description, packaging, and execution can be designed separately.
That makes your product easier to adapt as platforms change.
A practical validation plan for domain-expert founders
Do not start by building a sprawling agent marketplace. Start with one capability that is valuable enough to be discovered.
Use this sequence:
- Choose one high-friction job. Pick a recurring workflow where your domain knowledge changes the quality of the result.
- Define the boundary. Decide what the AI can reason about and what deterministic software must enforce.
- Write the catalog entry first. Describe the capability, endpoint, and representative queries before polishing the interface.
- Test the language with buyers. Ask prospects how they describe the problem when it happens, not what feature name they prefer.
- Keep a human approval point. Payments, deployments, customer messages, record changes, and other consequential actions should pause for review unless the operating context clearly supports automation.
- Package only when reuse appears. If the same skill and server need to work across multiple clients, then a portable plugin becomes valuable.
This is product validation in a new form. You are testing whether the capability is clear enough for both a person and an agent to understand when it should be used.
Build for the second customer: the agent
Human buyers will still judge your product by trust, outcomes, and ease of use. That does not change.
What changes is the path into the product.
A future customer may ask an assistant to solve a problem, and that assistant may search for a verified capability rather than wait for the customer to browse a software directory. Products with precise descriptions, clear boundaries, portable packaging, and trustworthy endpoints will be easier to evaluate in that environment.
Your domain experience is the raw material. The product is the repeatable capability. The catalog is how the next generation of software may find it.
If you want to turn a workflow you already understand into a focused AI product, book a strategy call. AI Product Accelerator helps experienced professionals validate the problem, build the product, and launch it in 12 weeks.