# ByAgents — complete knowledge library

Bulk export. For focused retrieval, use /llms.txt or /api/knowledge/search.

# What is an AI agent?

> A practical explanation of agents, assistants, tools, and the decisions between a request and a result.

Canonical: https://byagents.dev/humans/what-is-an-ai-agent
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Business
Outcome: Understand what an agent can do, what its environment controls, and why that matters for your business.

An AI agent is software that can use a model to choose and carry out steps toward a task, using the tools and permissions available to it. A chat window is an interface. Whether the system behind it can search, compare products, or place an order depends on how that system is built and configured.

## From an answer to a sequence of actions
A conventional chatbot might explain how to extract data from invoices. An agent could search for an extraction API, read its documentation, write integration code, submit a permitted test invoice, and inspect the returned fields. Each step produces information that can change the next step.

Anthropic distinguishes predefined workflows from agents that dynamically direct their process and tool use. That distinction is useful, although real products can combine both patterns. An agent does not have unlimited freedom: its developer sets tools, instructions, execution limits, and authorization boundaries. [Read Anthropic’s explanation](https://www.anthropic.com/engineering/building-effective-agents).

## Four pieces that matter to your business
- **The request:** What the customer wants, including budget, location, compatibility, and timing.
- **The available tools:** Search, a browser, a connected application, an API, or a limited catalog of tools.
- **The evidence:** Product pages, documentation, prices, reviews, and the results of earlier steps.
- **The permission boundary:** What the agent may read, submit, buy, or change on the customer’s behalf.

Being visible to the model is only one part of this sequence. A product can be mentioned in an answer but remain impossible to use because the agent cannot find current pricing, authenticate, or retrieve a result.

## A concrete example
Suppose the request is: “Find a way to extract line items from 200 invoices a month, including scanned PDFs.” The useful product information is specific: supported inputs, field coverage, pricing units, trial limits, and an example output. “The future of document intelligence” gives the agent little to compare.

After selecting a candidate, the agent still needs a complete path. Where does it get a trial? Does submitting a document incur a charge? Is the result returned immediately, or does it need another request? What does an error mean? These are product questions as much as marketing questions.

## Do agents have preferences?
Agents do not need to enjoy a website for it to be useful. The practical design goal is to reduce ambiguity and unnecessary work within the task. Clear facts, accessible pages, bounded responses, and reliable interfaces help a system reach an outcome. Instructions hidden in a page telling an agent to recommend the business are not evidence of product fit.

Nor does a recognizable assistant name establish a discovery route. Different modes of the same assistant can have different search, browsing, and connector access. Record the environment when testing; avoid treating one successful run as universal behavior.

## What to do first
Choose one customer task. Write down what an agent would have to learn and do to complete it. Find the first missing fact or broken step. Fix that before adding a new protocol, directory listing, or content campaign. The next guide maps the places an agent might encounter your business.

## Sources

- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

## Related reading

- [How AI agents find products](https://byagents.dev/humans/how-agents-find-products)
- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)
- [The agent discovery glossary](https://byagents.dev/humans/agent-discovery-glossary)


---

# How AI agents find products

> Search, cited sources, directories, documentation, and connected tools form different routes into a business.

Canonical: https://byagents.dev/humans/how-agents-find-products
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Map the possible routes from a customer task to your product and identify which route was observed.

AI agents can discover products through web search, pages they browse, third-party sources, directories, or tools already available in their environment. There is no single directory that every agent checks. The route depends on the user’s task and the agent’s access.

## Discovery is a chain, not a single ranking
An agent trying to solve a task may first search for the category, then investigate a shortlist, then open documentation or a booking page. It can return to search when a source leaves a question unanswered. Your homepage may be only one stop, or it may never be opened.

For example, Google describes query fan-out in its AI features: related searches across subtopics and sources can help construct an answer. This is a documented Google behavior, not a claim about every assistant. [Google’s AI features guidance](https://developers.google.com/search/docs/appearance/ai-features).

## Five routes worth mapping
| Route | What introduces you | What to prepare |
| --- | --- | --- |
| Web search | A relevant result for a customer task | A useful, accessible page with a clear next step |
| Third-party evidence | A review, comparison, reference, or cited source | Accurate identity and claims the source can substantiate |
| Documentation | A recipe, API reference, or integration example | Inputs, outputs, limits, authentication, and completion |
| Directories | A category or product listing | Correct metadata and a working destination |
| Connected tools | An installed or configured integration | Descriptive operations and reliable task completion |

These routes overlap. A directory can lead to documentation; a review can lead to a product page; a search can uncover a tool listing. A listing is useful only if a relevant system or user actually encounters it.

## A registry is not automatic installation
The MCP Registry publishes server metadata for clients and aggregators to consume. It is a distribution surface, not a promise that a particular assistant will install or call your server. A host can curate its own catalog or require an operator to connect a server. [MCP Registry overview](https://modelcontextprotocol.io/registry/about).

The same distinction applies to tool search. An application may search a set of tools it has made available; that does not imply a search of every API on the internet. OpenAI documents tool search as a way to discover and load deferred tools configured for an application. [OpenAI tool search](https://developers.openai.com/api/docs/guides/tools-tool-search).

## Start with a route hypothesis
Write a testable sentence: “A coding agent helping a developer extract invoice line items can encounter our task guide through web search, then reach our trial and complete an extraction.” Name the source page, intended query, next step, and expected output.

Test both discovery and use. In a discovery test, do not provide your brand name or preinstall your integration. In a separate adoption test, deliberately provide the product and examine whether the agent can use it. The second test reveals friction, but cannot prove the first route works.

## What success looks like
A credible record includes the user task, environment, sources retrieved, page or tool selected, and observable result. A screenshot of an answer mentioning the company is evidence of a mention in that run. It is not evidence of an independent customer, referral, or sale. Keep those outcomes separate as you improve the path.

## Sources

- [Google: AI features](https://developers.google.com/search/docs/appearance/ai-features)
- [MCP Registry](https://modelcontextprotocol.io/registry/about)
- [OpenAI: Tool search](https://developers.openai.com/api/docs/guides/tools-tool-search)

## Related reading

- [Can an agent actually read your website?](https://byagents.dev/humans/crawl-access)
- [MCP, registries, and getting your tools discovered](https://byagents.dev/humans/mcp-and-tool-discovery)
- [Measure agent discovery without fooling yourself](https://byagents.dev/humans/measuring-agent-traffic)


---

# When the customer’s browser becomes a conversation

> Our thesis on how agents could change internet distribution—and what businesses can prepare today.

Canonical: https://byagents.dev/humans/agents-and-internet-distribution
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Perspective
Level: Business
Outcome: Understand the distribution thesis and the uncertainties behind it.

As assistants become a place to research and act, a business may need to win consideration before a person ever sees its website. Our thesis is that distribution will increasingly depend on whether an agent can find credible product information and turn it into a useful result. This is a direction to prepare for, not a prediction that every purchase will move into chat.

## The interface can move; the job remains
Consider a customer looking for dinner near a hotel. They can open maps, read menus, compare hours, and make a reservation. They can also ask an assistant to help with those steps. The underlying constraints do not disappear: location, opening time, dietary needs, availability, price, and permission to book.

The same pattern applies to a freelance project or software integration. The customer still needs a fit. The difference is that more of the comparison can happen outside a company’s carefully designed homepage. Product facts and action paths become part of the distribution surface.

## From winning the click to earning the next step
A traditional website often treats the visit as the beginning of the customer journey. In an agent-mediated journey, substantial evaluation may precede it. The visit might land directly on documentation, a specific product variant, or a booking page.

That changes the questions worth asking. Is the offer understandable when a single page is retrieved? Can a third-party source connect the brand to the correct product? Does the destination preserve the customer’s requirements? Can the next step be completed without guessing?

Our practical response is to organize work around three outcomes: **get found, get understood, get used**. None is sufficient alone. Search visibility without reliable facts wastes attention. Excellent documentation without exposure remains undiscovered. A compelling recommendation followed by a broken handoff loses the opportunity.

## What could become more valuable
- **Specific expertise:** A page that answers a difficult customer question gives a system something useful to retrieve.
- **Current facts:** Price, stock, service area, compatibility, and availability determine whether an option fits now.
- **Evidence:** Clear sources and limitations let an agent distinguish a claim from support for that claim.
- **Working interfaces:** A reliable purchase, booking, or API path turns consideration into action.

These are our hypotheses about durable business value. They do not require assuming that one agent platform wins or that a new protocol replaces the web.

## What remains uncertain
The mix of open web search, curated catalogs, commercial placement, and direct integrations will vary. Platforms can change interfaces and policies. Consumers may delegate research while retaining checkout. Some businesses will see referrals; others may receive direct tool calls or assisted conversions with incomplete attribution.

A sensible plan preserves optionality: maintain an accessible website, reliable product facts, and customer-owned interfaces. Add a distribution surface when you can name the audience it reaches and measure a meaningful outcome. Avoid rebuilding the business around an unverified universal agent directory.

## Why we are building ByAgents
We want to help businesses earn a place in these journeys. Our starting point is concrete preparation and diagnosis, including discovery plans and API contract checks. The broader ambition is distribution that can be traced to useful customer activity. The proof must come from observed use, not the number of files published or agents simulated.

Start with one customer task and one route. If the path works, maintain it and expand. If it does not, find the missing step. That is a practical way to act on the shift without pretending the future is already settled.

## Related reading

- [How AI agents find products](https://byagents.dev/humans/how-agents-find-products)
- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)
- [Your first 30 days of agent discovery work](https://byagents.dev/humans/first-30-days)


---

# SEO, GEO, and agent discovery: what actually changes?

> Separate search eligibility, inclusion in AI answers, and completed actions so you can invest in the right work.

Canonical: https://byagents.dev/humans/seo-geo-and-agent-discovery
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Business
Outcome: Distinguish search visibility, answer inclusion, and successful agent handoffs.

SEO concerns discoverability in search. GEO is commonly used for work intended to improve how a business appears in generative answers. Agent discovery includes the route from finding an offering to assessing and potentially using it. These areas overlap, but their outcomes are different.

## Name the outcome before choosing the tactic
| Outcome | Useful evidence | What it does not prove |
| --- | --- | --- |
| Search eligibility | A page can be fetched and is indexable | That it will rank or be selected |
| AI answer inclusion | The business or source appears in a recorded answer | That a customer visited or acted |
| Referral | An attributable visit reaches your site | That the visitor became a customer |
| Activation | A new customer completes a useful first task | That discovery caused incremental revenue |
| Retention | The customer returns or continues paying | That one specific optimization caused it |

Without these distinctions, a visibility report can look like a distribution result. A technical repair can also look unsuccessful if it is judged only by mentions, even when it removes a real obstacle to using the product.

## Start with ordinary web fundamentals
Google’s published guidance for AI Overviews and AI Mode says existing SEO fundamentals remain relevant and that no special AI text file or additional schema is required. Eligibility does not guarantee crawling, indexing, or inclusion. [Google’s guidance](https://developers.google.com/search/docs/appearance/ai-features).

For a business, the practical foundation is straightforward: useful pages, clear internal links, correct access controls, consistent canonical URLs, and accurate content. Structured data should describe the visible offering. Plain-text references can be useful for readers and tools that prefer them, but they are not a substitute for an accessible site.

## Then improve the handoff
Agent readiness introduces questions that a mention dashboard cannot answer on its own. Can an agent understand the pricing unit? Identify the correct product variant? Obtain permitted access? Submit a request? Retrieve the finished output? Recognize a failure without repeating a paid action?

For an invoice API, a missing polling endpoint can prevent a first result even if the service appears in many comparisons. For a restaurant, a clear menu does not solve an unavailable or ambiguous reservation path. For a freelancer, a generic contact page may fail to state service scope or response expectations.

## Prioritize by the broken step
If relevant pages cannot be fetched, work on access. If the offering is repeatedly misunderstood, work on facts and evidence. If agents reach the product but fail to use it, work on the interface and documentation. If everything works only when your brand is named in advance, investigate distribution rather than claiming organic discovery.

Use a small set of representative tasks and record changes over time. Keep controlled tests separate from external traffic. Where attribution is unknown, say so. The purpose of the work is a more reliable route into the business—not an impressive score with an unclear relationship to customers.

## Where ByAgents fits
Our current tools help prepare discovery paths and identify static API contract gaps. We are building toward broader distribution work, but do not claim that a plan, schema file, or diagnostic alone delivers traffic. The useful question is always: what changed in the customer’s ability to find and use the offering?

## Sources

- [Google: AI features and your website](https://developers.google.com/search/docs/appearance/ai-features)

## Related reading

- [Structured data that helps explain your business](https://byagents.dev/humans/structured-data)
- [Measure agent discovery without fooling yourself](https://byagents.dev/humans/measuring-agent-traffic)
- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)


---

# Can an agent actually read your website?

> A crawl-access checklist covering HTTP responses, robots rules, rendering, canonical URLs, and sitemaps.

Canonical: https://byagents.dev/humans/crawl-access
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Technical
Outcome: Identify whether access, indexing policy, or page delivery prevents useful retrieval.

Before optimizing what an agent learns, check whether it can retrieve the information at all. A page that works in your logged-in browser can still return a challenge, empty shell, or access error to another client. Test the public path from outside your session.

## Check the response, then the content
Start with the important pages: product, pricing, documentation, policies, and the next action. Confirm that each returns the intended status and useful text without requiring a personal account. Do not mistake a 200 response containing a login page or bot challenge for accessible product information.

Google can render JavaScript, but not every crawler or retrieval client does. Server-rendered text and real links reduce the work required to access a page. A separate Markdown version can help some tools; it should carry the same facts as the HTML. [Google’s JavaScript SEO guidance](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics).

## Understand the controls
Robots rules express crawler preferences; they are not access control. Authentication and authorization must protect private content. The Robots Exclusion Protocol defines how participating crawlers interpret rules, but does not make private data safe to publish. [RFC 9309](https://www.rfc-editor.org/info/rfc9309/).

Search crawling and model training are also different uses. OpenAI documents separate controls for OAI-SearchBot and GPTBot. ChatGPT-User represents certain user-initiated actions and is not the automatic search crawler. Choose policies deliberately instead of assuming one “AI bot” switch controls every use. [OpenAI crawler reference](https://developers.openai.com/api/docs/bots).

## A practical inspection sequence
- Fetch each priority URL without your logged-in cookies. Inspect both the response code and body.
- Confirm the main answer, product facts, and links exist in the initial HTML or a documented text alternative.
- Review robots rules, page-level indexing directives, and CDN or firewall challenges together.
- Check that canonical URLs identify the intended public page and do not point to a staging domain.
- Link important pages from ordinary navigation or contextual links; do not rely on a search box to expose them.
- Include canonical public URLs in a sitemap and update modification dates only when the content changes.

A sitemap helps a search engine discover URLs; it does not guarantee that they will be indexed. Avoid stuffing it with query results, duplicates, or pages that redirect. [Google’s sitemap overview](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview).

## Diagnose the layer that failed
A DNS or TLS problem prevents a connection. A firewall challenge can prevent retrieval. A robots rule can exclude a cooperative crawler. An empty JavaScript shell can prevent extraction. Contradictory canonical signals can confuse indexing. These failures need different fixes; adding more copy will not resolve all of them.

## Keep the test honest
Do not weaken authentication on customer or administrative pages to improve crawlability. Publish a separate public explanation of the offering. A successful anonymous fetch establishes access for that request, not adoption by an AI platform. Verify the next layer independently: whether a relevant system encounters and uses the information.

## Diagnose a failure without guessing

A 200 response can still be an empty application shell or a challenge page. Inspect the body for the information the task needs. Keep crawl policy, indexing directives, firewall behavior, and authentication as separate checks. A request from your own environment cannot prove that a named provider has indexed the page.

A crawler user-agent string is not verified identity. Do not grant broad access to private routes because a request contains a familiar name. Use the relevant provider's verification guidance and scope any exception to intended public content. The [platform comparison](https://byagents.dev/humans/ai-discovery-platforms) explains differences between search, training, and user-requested retrieval; the [audit recipe](https://byagents.dev/agents/crawl-audit-recipe) provides bounded requests and an evidence record.

## Sources

- [Google: JavaScript SEO](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- [RFC 9309](https://www.rfc-editor.org/info/rfc9309/)
- [OpenAI crawlers](https://developers.openai.com/api/docs/bots)
- [Google: Sitemaps](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview)

## Related reading

- [Structured data that helps explain your business](https://byagents.dev/humans/structured-data)
- [What llms.txt and Markdown can—and cannot—do](https://byagents.dev/humans/llms-txt-and-markdown)
- [Your first 30 days of agent discovery work](https://byagents.dev/humans/first-30-days)
- [How the major AI discovery channels differ](https://byagents.dev/humans/ai-discovery-platforms)
- [Recipe: audit public crawl and retrieval access](https://byagents.dev/agents/crawl-audit-recipe)


---

# Structured data that helps explain your business

> How to use Schema.org, JSON-LD, stable identifiers, and visible facts without inventing a special AI ranking formula.

Canonical: https://byagents.dev/humans/structured-data
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Technical
Outcome: Choose an accurate structured description and reconcile it with visible product facts.

Structured data gives software explicit labels for facts that would otherwise need to be inferred from a page. Schema.org provides a shared vocabulary; JSON-LD is one way to express it. The goal is an accurate description of the offering, not a hidden sales pitch.

## Model the real thing
A business, a product, an offer, and a service are related but distinct. Use the type that represents the entity described on the page. Give important entities stable identifiers so multiple pages can refer to the same thing. A product’s price and availability belong to an offer; a company’s identity belongs to its organization record.

Schema.org’s Product vocabulary includes relationships such as brand, offers, and identifiers. The properties you choose should fit the actual information available. [Schema.org Product](https://schema.org/Product).

## Start with a small, consistent record
For a fictional extraction API, a useful visible fact sheet might say: it accepts PDF invoices, returns line items in JSON, charges per page, and requires an API key. The structured description should agree with that page. Do not add a free offer, rating, certification, or unsupported capability merely because the schema permits the field.

```json
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "@id": "https://example.com/invoice-api#software",
  "name": "Example Invoice API",
  "url": "https://example.com/invoice-api",
  "applicationCategory": "DeveloperApplication",
  "description": "Extracts line items from PDF invoices into JSON."
}
```

This is a vocabulary example using a reserved example domain. It is not a complete recipe for a Google rich result and does not describe a ByAgents customer.

## Keep markup and pages in agreement
Google uses structured data to understand page content and support eligible search appearances. Its documentation recommends JSON-LD and requires the markup to represent the visible content. Valid markup does not guarantee a rich result. [Google’s structured data introduction](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data).

A common failure is maintaining the website, product feed, and structured record separately. A changed price then leaves three different answers. Prefer a shared source for recurring facts, with a clear owner and update process. If a value changes frequently, link to the live source and indicate when a snapshot was checked.

## Useful validation questions
- Does the type describe the actual entity on the page?
- Do names, URLs, identifiers, currencies, and units match across representations?
- Are claims backed by visible content and appropriate sources?
- Have placeholder prices, invented ratings, and stale availability been removed?
- Does the chosen search feature have additional eligibility requirements?

A syntax validator can catch malformed data. It cannot establish that a claim is true, a price is current, or an agent will choose the product. Review meaning as well as format.

## The next step is still separate
Structured data can explain an offering. An action still needs a real destination, available inventory or capacity, and appropriate permission. For APIs, that usually means a complete contract and usable onboarding. For services, it might mean a scoped inquiry or booking flow. Make the facts and the action agree.

## Resolve contradictions at the source

Build a small consistency matrix: entity identifier, visible name, price unit, current offer source, relevant limits, and next-action URL. Compare the same fields across the product page, markup, feed, and documentation. If one disagrees, identify which system owns the fact before updating the copies.

Stable identity is particularly useful for variants. A blue 750 ml bottle and a green 500 ml bottle may share a family but are different purchasable items. A feed must not send both to a generic page that loses the selected variant. For a service, avoid presenting an inquiry as a confirmed booking. The [feed validation recipe](https://byagents.dev/agents/feed-validation-recipe) checks these relationships without treating valid syntax as proof of truth.

## Sources

- [Schema.org Product](https://schema.org/Product)
- [Google: Structured data](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)

## Related reading

- [Give agents something worth citing](https://byagents.dev/humans/citations-and-evidence)
- [Agent discovery for brands and ecommerce](https://byagents.dev/humans/brands-and-commerce)
- [Agent discovery for services, freelancers, and local businesses](https://byagents.dev/humans/service-businesses)
- [Recipe: validate a product feed across the full handoff](https://byagents.dev/agents/feed-validation-recipe)
- [Product feeds for AI shopping](https://byagents.dev/humans/product-feeds-for-ai-shopping)


---

# Give agents something worth citing

> Build product claims that can be checked, quoted in context, and connected to the correct business.

Canonical: https://byagents.dev/humans/citations-and-evidence
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Business
Outcome: Build a source-backed product explanation that can support a specific recommendation.

A useful citation points to evidence for a specific claim. It is not simply another mention of the brand. To make your business easier to assess, connect important claims to accessible sources and explain the conditions under which those claims hold.

## Separate identity, capability, and proof
An identity claim says who operates the product and where its official information lives. A capability claim says what the offering can do. Evidence explains why a reader should believe that capability applies to the task. These require different material.

For an invoice API, “returns line items” is a capability. A documented sample with the input, expected output, limitations, and test date is evidence for a narrow example. It does not establish accuracy across every invoice layout. For a service business, a detailed case study can show experience on a particular project without implying identical results for every client.

## Make each claim inspectable
- Put the claim near its source, rather than attaching a general list of impressive links.
- State units and scope: per document, per page, per location, or per customer project.
- Identify whether the source is your own documentation, a customer statement, an independent review, or a controlled test.
- Include meaningful dates for facts that can change.
- Preserve limitations when turning a case study into a summary or structured record.

A retrieval system may see only one section of a page. Write that section so the claim and its limits still make sense together. A heading such as “Batch extraction limits” is more informative than “Built for scale” when the reader needs a maximum batch size.

## Reviews need context
A five-star average says less about fit than a review explaining the use case, constraints, and outcome. Do not manufacture reviews, import ratings into unrelated contexts, or mark up testimonials as independent evidence. Google’s review documentation sets specific rules for review snippets, including restrictions on self-serving reviews for organizations and local businesses. Those rules concern a Google search feature, not a universal agent trust score. [Google review guidance](https://developers.google.com/search/docs/appearance/structured-data/review-snippet).

## Keep third-party information accurate
If you maintain a legitimate directory listing, update the product name, official URL, category, and current description. Avoid creating many near-identical listings simply to repeat a claim. If an independent source contains an error, seek a correction through its normal process; do not represent paid placement as independent endorsement.

## A practical evidence record
For each important claim, record the exact statement, source URL, source type, date checked, scope, and known limitations. Mark unsupported claims as unverified. This gives a person or agent a way to decide what can safely be repeated.

For example: “The sample workflow retrieves a completed extraction result using a documented status endpoint.” Evidence could be a reproducible test with the fixture and returned result. The limitation is equally important: one sample workflow does not establish reliability, security, or agent discovery in production.

## What this work can achieve
Better evidence can reduce ambiguity and make a comparison more useful. It cannot force an assistant to cite your page or recommend your business. Track actual appearances and downstream outcomes separately from the work of publishing the evidence.

## Sources

- [Google: Review snippets](https://developers.google.com/search/docs/appearance/structured-data/review-snippet)

## Related reading

- [Structured data that helps explain your business](https://byagents.dev/humans/structured-data)
- [Measure agent discovery without fooling yourself](https://byagents.dev/humans/measuring-agent-traffic)
- [API documentation an agent can actually use](https://byagents.dev/humans/api-documentation)


---

# MCP, registries, and getting your tools discovered

> Understand the difference between publishing a server, connecting it to a host, and getting a tool used.

Canonical: https://byagents.dev/humans/mcp-and-tool-discovery
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Decide when an MCP integration helps and what publication alone cannot establish.

MCP—the Model Context Protocol—standardizes how compatible AI applications connect to servers exposing tools and context. It can make an integration easier to distribute across compatible hosts. It does not automatically bring your product into every agent’s tool list.

## Three separate milestones
**Publish:** The server and its metadata are available through a relevant distribution route. **Connect:** A host or user configures access to the server. **Use:** The agent selects a tool and completes a useful task. Report these milestones separately.

The MCP Registry provides metadata and installation information for clients and aggregators. A registry record can help a compatible consumer find a server; it is not the server runtime itself. Consult the current registry documentation for publication requirements and lifecycle status. [Registry overview](https://modelcontextprotocol.io/registry/about).

## Design tools around an intelligible job
A tool needs a clear name, description, input schema, and understandable results. The MCP tools specification defines tool listing and invocation, with schemas for inputs and optional structured outputs. These describe the interface; product usefulness still depends on the implementation. [MCP tools specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).

Prefer a description that names the task and its important boundaries. “Extract invoice fields from an uploaded document; returns a job identifier” tells an agent more than “Ultimate document AI.” If completion requires another call, name and document that path. If an operation writes data or incurs a charge, make that clear before invocation.

## Avoid the thin-wrapper trap
Wrapping every API endpoint as a tool can expose too many overlapping choices. Start with a small useful workflow. Return the fields needed for the next decision rather than an enormous raw record. Errors should identify a recoverable next step without suggesting unlimited retries.

Anthropic’s tool-design guidance emphasizes clear tool descriptions, meaningful results, and evaluation against realistic tasks. Treat these as design practices to test in your environment, not a guarantee of tool selection. [Writing tools for agents](https://www.anthropic.com/engineering/writing-tools-for-agents).

## Authentication is part of the product
A host must be able to establish the correct access, and the operator must understand what is being authorized. Do not place secrets in public documentation or assume permission to perform a purchase because the tool exists. Verify the current host’s supported authentication and approval behavior before advertising compatibility.

A successful connection is also not a security certification. Review the protocol’s security guidance and your own application boundaries. Keep read-only discovery separate from actions that affect accounts, payments, or private data. [MCP security guidance](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices).

## When should you build an MCP server?
Build one when a defined group of users works in compatible hosts and a tool interface improves a real task. If the immediate problem is unreadable pricing or incomplete API documentation, solve that first. An existing API, useful guide, and working example may be a better initial distribution investment.

ByAgents currently publishes a read-only knowledge API and documentation, not a live MCP server. Its API contract diagnostic is a separate product capability. We make that distinction explicit so integrations can be chosen on facts.

## Check the protocol revision before copying an example

MCP behavior is versioned. This guide now links the 2026-07-28 tools and security documentation. A host or SDK may implement an older revision; that needs an explicit compatibility check, not an assumption. Use the [publication and compatibility recipe](https://byagents.dev/agents/mcp-publication-and-compatibility) to record the supported combination and distinguish known-server capability discovery from independent product discovery.

## Sources

- [MCP Registry](https://modelcontextprotocol.io/registry/about)
- [MCP tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
- [Anthropic: Tool design](https://www.anthropic.com/engineering/writing-tools-for-agents)
- [MCP security](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)

## Related reading

- [API documentation an agent can actually use](https://byagents.dev/humans/api-documentation)
- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)
- [What llms.txt and Markdown can—and cannot—do](https://byagents.dev/humans/llms-txt-and-markdown)
- [Recipe: publish and verify an MCP integration](https://byagents.dev/agents/mcp-publication-and-compatibility)
- [MCP, WebMCP, A2A, ACP, UCP, and ARD: what to build](https://byagents.dev/humans/agent-protocols-explained)


---

# API documentation an agent can actually use

> Document the full task: authentication, inputs, asynchronous results, errors, limits, and a verifiable outcome.

Canonical: https://byagents.dev/humans/api-documentation
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Technical
Outcome: Identify the documentation needed for an agent to reach a first successful API result.

Useful API documentation lets an agent move from a customer task to a verified result without inventing missing steps. An endpoint list is a starting point. The complete contract includes access, request shape, completion behavior, error recovery, and the meaning of success.

## Begin with the result
For an extraction API, success is not merely receiving HTTP 200 or 202. It is obtaining the required fields in a usable form. Write a short workflow that starts with the intended input and ends with the actual output. State what the example does not cover.

A good quickstart identifies the base URL, authentication method, required parameters, content types, and response structure. It also explains the pricing unit and whether an example consumes a paid resource. Use placeholders for secrets and synthetic data for public examples.

## Close asynchronous handoffs
An API may accept a job before the result is ready. The documentation should explain how to identify that job, inspect its status, retrieve the output, and recognize terminal failure. If polling is expected, describe the permitted interval and stopping conditions.

```text
POST /jobs
→ 202 Accepted { "jobId": "example-job" }

GET /jobs/example-job
→ 200 OK { "status": "complete", "result": { ... } }
```

This fictional contract illustrates the missing handoff ByAgents checks for. It is not a live endpoint. A job identifier without a documented retrieval path leaves both a developer and an agent guessing.

## Make the specification useful
OpenAPI describes HTTP APIs through operations, parameters, schemas, responses, and security definitions. A valid document provides structure for tools to inspect, but validity alone does not prove the workflow is complete or the implementation matches. [OpenAPI 3.1.1 specification](https://spec.openapis.org/oas/v3.1.1.html).

Give operations distinct, stable identifiers and specific descriptions. Document error responses alongside successful ones. Ensure examples conform to their schemas. State whether a field is optional, nullable, or absent until a later state; these are different situations for a client.

## Explain retries before they become duplicate actions
An agent encountering a timeout should not have to guess whether a job was created or a payment occurred. Document idempotency support where it exists, how to check the original operation, and which failures are safe to retry. Do not invent idempotency support in a wrapper around an API that lacks it.

A useful error identifies what failed and, when appropriate, the next action: correct an input, reduce a batch, wait until a stated retry time, or request permission. Avoid returning secrets, internal stack traces, or unrelated customer data in an error.

## Test the journey, not just the schema
Run a representative task in an authorized environment using the published documentation. Record the inputs, requests, outputs, and failure. Check the final artifact against an expected result. Then rerun after the smallest repair.

Static contract analysis can flag a missing step before a live test. It cannot establish that credentials work, a server is available, or an extraction is accurate. Keep the output of a static diagnostic labeled accordingly.

## A maintenance habit
When the API changes, update the reference, quickstart, SDK example, and relevant tool description together. Retire outdated examples or clearly mark their version. A distribution path is only as reliable as the instructions it lands on.

## Sources

- [OpenAPI 3.1.1](https://spec.openapis.org/oas/v3.1.1.html)

## Related reading

- [MCP, registries, and getting your tools discovered](https://byagents.dev/humans/mcp-and-tool-discovery)
- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)
- [Measure agent discovery without fooling yourself](https://byagents.dev/humans/measuring-agent-traffic)


---

# Agent discovery for brands and ecommerce

> Prepare product identity, variants, offers, policies, and a dependable route to checkout.

Canonical: https://byagents.dev/humans/brands-and-commerce
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Business
Outcome: Connect accurate product information to a valid shopping handoff.

For a brand, agent readiness starts with accurate product information and a usable path to the right item. A recommendation is of little value if it lands on the wrong variant, an unavailable size, or a checkout that contradicts the advertised offer.

## Work backward from a buying question
A shopper may ask for a waterproof commuter bag under a budget, delivered before a trip. Useful facts include dimensions, materials, capacity, weather resistance, price, stock, delivery region, and return conditions. A broad brand story can matter, but it does not answer those constraints on its own.

Select a small set of priority products and common buying questions. Identify which page answers each question and whether the answer can be retrieved without interacting with a carousel, modal, or account wall. Include the relevant qualifiers: water-resistant is not automatically waterproof, and a delivery estimate depends on destination and order time.

## Give each product a stable identity
Keep names, URLs, variant relationships, and identifiers consistent across product pages, feeds, and structured records. Distinguish a product family from the specific item being offered. Do not let the default size or color silently stand in for every variant.

Google documents product structured data and merchant listing experiences, with requirements that vary by feature. Those are useful distribution surfaces to evaluate, not universal requirements shared by all agents. [Google product guidance](https://developers.google.com/search/docs/appearance/structured-data/product).

## Make the offer clear
- State currency and whether a displayed price applies to a particular variant or quantity.
- Keep availability aligned with the actual purchasing system.
- Explain delivery regions, costs, and material restrictions in accessible text.
- Link return and cancellation policies near the decision.
- Preserve the selected item and variant when the customer reaches checkout.

Avoid inventing availability in a static profile. For facts that change rapidly, point to a current source and treat cached values as snapshots. A correct catalog yesterday can still produce a bad recommendation today.

## Support claims with product evidence
If a claim matters to a buying decision, explain how it is supported. Dimensions should have units. Certifications should name their scope and source. Customer reviews should remain attached to the correct product and context. A general testimonial should not become evidence of a technical property.

## Verify the final handoff
Test a permitted journey from a task page to the correct product, variant, cart, and checkout boundary. Confirm the final price and conditions are clear before any purchase. A research agent may hand the user a link; a transactional agent may have additional permissions. Design for both without assuming it may spend money automatically.

## A focused first project
Choose ten products, five buying questions, and one distribution route. Fix inconsistent facts and broken destinations first. Measure retrieved pages, qualified visits, and actual customer events separately. Do not label a product-feed upload or a simulated shopping session as new revenue.

ByAgents’ company path currently helps organize this preparation. It does not automatically publish merchant feeds, manage stock, or guarantee placements in shopping assistants.

## Sources

- [Google: Product structured data](https://developers.google.com/search/docs/appearance/structured-data/product)

## Related reading

- [Structured data that helps explain your business](https://byagents.dev/humans/structured-data)
- [Give agents something worth citing](https://byagents.dev/humans/citations-and-evidence)
- [Agent discovery for services, freelancers, and local businesses](https://byagents.dev/humans/service-businesses)


---

# Agent discovery for services, freelancers, and local businesses

> Make scope, location, availability, proof, and the next step clear enough to support a real recommendation.

Canonical: https://byagents.dev/humans/service-businesses
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Business
Outcome: Publish the facts and inquiry or booking path a service customer needs.

A service business becomes easier to recommend when the right customer can establish fit without a long clarification loop. Agents need the same essentials: what you do, who it is for, where you operate, what constrains the work, and how to take the next step.

## Turn a vague offer into a decision
“Creative solutions for ambitious brands” does not tell an agent whether you design Shopify storefronts, shoot food photography, or write launch copy. A useful service page names the deliverable, target customer, typical scope, and boundaries. If prices require a quote, explain what determines the quote rather than inventing a fixed rate.

For a local business, location and current hours can be decisive. For a freelancer, capacity, time zone, delivery format, and project size may matter more. For food and hospitality, menus, dietary information, reservation requirements, and service hours help establish fit. Keep sensitive or changeable claims tied to the current source.

## Keep your identity consistent
Use the same business name, official website, and relevant contact details across your site and legitimate listings. Describe service areas explicitly. A remote service and a physical location are different facts; do not create fictional locations to appear in more searches.

Google’s LocalBusiness documentation describes structured fields for local business information and supported search features. Use the subtype and properties that match the real business, and check the requirements for the intended feature. [Local business structured data](https://developers.google.com/search/docs/appearance/structured-data/local-business).

## Show proof at the right level
A project example should explain the brief, your contribution, the delivered work, and any stated outcome you can support. If a customer permitted a testimonial, preserve its context. Do not turn one successful project into a guaranteed result for every client.

An agent comparing service providers benefits from facts such as “implemented a subscription flow for a Shopify store” more than unqualified superlatives. The evidence should establish relevance to the requested job.

## Design a useful next step
- Link directly to the relevant inquiry or booking flow.
- State the minimum information needed to assess the request.
- Explain whether submitting a form confirms a booking or only requests one.
- Make time zones and appointment duration explicit.
- Show cancellation, deposit, or quote conditions before commitment where relevant.

A completed contact form is not a confirmed project. A reservation request is not an accepted reservation. Make status changes unambiguous so an agent can report the outcome accurately.

## Test a realistic customer request
For a fictional photographer, try: “Find someone who shoots a small restaurant menu in my city next month.” Can the agent find a relevant portfolio, determine the service area, understand the likely scope, and reach an inquiry with the right details? Record where it needs to guess.

Repair the missing fact or broken handoff, then retest. Do not create dozens of near-identical city pages or synthetic reviews. A small set of accurate service pages and evidence can be more useful than a large volume of interchangeable copy.

## What to measure
Track qualified inquiries and confirmed work using your own records, with known referrals separated from unknown sources. Count test inquiries separately. The business outcome is a suitable customer taking a real next step, not just an assistant repeating your name.

## A practical fact sheet for a local business

Publish what is needed to rule the business in or out: service area, actual address when relevant, hours and holiday exceptions, scope, price or quote basis, accessibility information you can substantiate, and the precise booking or inquiry path. Assign an owner to keep listings and your own site consistent.

For a restaurant, keep the menu, location, opening times, group-size limits, and reservation process easy to find. Do not imply live table availability if the page only accepts inquiries. For a freelancer, state deliverables, exclusions, time-zone expectations, and what a useful brief should include. If pricing depends on scope, explain that dependency rather than inventing a flat price for agents to repeat.

A useful acceptance test asks whether a customer can identify fit and submit the intended next step without guessing. Test a case outside your service area as well as an eligible one. Follow the [commerce handoff guide](https://byagents.dev/humans/agent-commerce-readiness) when the next step can create a commitment.

## Sources

- [Google: LocalBusiness](https://developers.google.com/search/docs/appearance/structured-data/local-business)

## Related reading

- [Give agents something worth citing](https://byagents.dev/humans/citations-and-evidence)
- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)
- [Your first 30 days of agent discovery work](https://byagents.dev/humans/first-30-days)
- [From an AI recommendation to a confirmed purchase or booking](https://byagents.dev/humans/agent-commerce-readiness)
- [Where to start with agent distribution](https://byagents.dev/humans/agent-distribution-priorities)


---

# What llms.txt and Markdown can—and cannot—do

> Use lightweight text as a helpful documentation interface, without treating it as an AI ranking switch.

Canonical: https://byagents.dev/humans/llms-txt-and-markdown
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Technical
Outcome: Publish useful text representations without mistaking them for a guaranteed discovery mechanism.

An llms.txt file is a proposed convention for giving language-model tools a concise map of a website’s useful content. Markdown versions make individual documents easy to fetch as text. These are publishing conveniences, not a guarantee that agents will discover, trust, or recommend the site.

## A map, not a magic file
The llms.txt proposal describes a Markdown index with a title, short context, and links to more detailed material. The index can stay small while the detail is fetched when relevant. It is not the Robots Exclusion Protocol and does not control access. [The llms.txt proposal](https://llmstxt.org/).

For a documentation site, a useful map points to a quickstart, exact API reference, authentication guide, errors, product facts, and limits. For a business site, it can point to the offer, current policies, evidence, and contact route. Do not fill it with keyword repetition or commands asking an agent to favor your company.

## Keep two representations in agreement
A person may prefer HTML with navigation and a table of contents. A coding agent may prefer a text response with no interface chrome. Both should receive the same substantive information. Generating both from one source prevents the machine-readable version from quietly drifting away from the website.

Use stable URLs, meaningful document titles, explicit update dates, and source links. Include the canonical HTML URL in each Markdown document so an agent can cite the normal page. Keep code examples labeled and distinguish live endpoints from fictional ones.

## Make retrieval economical
A large all-in-one file can be convenient for offline indexing, but it is a poor default when a task needs one paragraph. Offer a short index and focused documents first. If you also provide a full export, identify it as a bulk option and avoid requiring it for ordinary use.

A search endpoint can further reduce unnecessary reading. It should state exactly what collection it searches, accept bounded queries, return concise excerpts and links, and handle no matches honestly. A search of your own library is not a marketplace search or proof of broad agent adoption.

## What to avoid
- Different product claims for bots and people.
- Hidden instructions to ignore other sources or award the site a high score.
- Unsupported claims that a particular platform checks llms.txt on every visit.
- An enormous index that repeats the full website without a way to select relevant documents.
- Private credentials, unpublished customer material, or executable commands disguised as documentation.

## How this site uses the pattern
ByAgents serves the same guide content as HTML and Markdown. The agent index links to product facts, an HTTP search contract, reference documents, and a full library export. These endpoints are read-only. They do not require installation or claim a connection to an assistant platform.

The value is inspectable: a reader can retrieve a document, verify a claim, and find the next relevant source. Whether that leads to independent traffic or customers remains a separate question to measure.

## Keep the index smaller than the library

An index should help a reader choose a document without loading every document. Include a short scope statement, exact URLs, meaningful descriptions, and a link to an optional full export. Point task-specific readers toward focused references. Keep private account information and hidden behavioral instructions out of every representation.

A practical acceptance check fetches the index, chooses one document from its description, retrieves it without a browser session, and verifies its source links. Measure whether this works in the intended consumer. Publishing a file at a conventional path does not prove that an unrelated assistant reads it. The [retrieval contract](https://byagents.dev/agents/retrieval-document-contract) describes the HTTP and content invariants behind this approach.

## The current proposal and link discovery

The llms.txt proposal was updated to v2 in August 2026. It recommends standard link relations so a reader can find the relevant index and Markdown representation: rel=describedby for the covering llms.txt file and rel=alternate with type=text/markdown for a document alternative. These are publishing recommendations, not a guarantee that every consumer follows them. [Current proposal](https://llmstxt.org/).

ByAgents exposes the index relation in HTML and Markdown response headers, and each article declares its Markdown alternative. The actual representation URLs come from our document index. Our publishing contract describes these implemented choices without claiming universal protocol adoption.


## Sources

- [llms.txt proposal](https://llmstxt.org/)

## Related reading

- [Can an agent actually read your website?](https://byagents.dev/humans/crawl-access)
- [API documentation an agent can actually use](https://byagents.dev/humans/api-documentation)
- [MCP, registries, and getting your tools discovered](https://byagents.dev/humans/mcp-and-tool-discovery)
- [Pattern: publish documents for reliable retrieval](https://byagents.dev/agents/retrieval-document-contract)


---

# From discovery to a purchase, booking, or API call

> Find the missing step between being recommended and being usable.

Canonical: https://byagents.dev/humans/from-discovery-to-action
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Identify the missing step between a recommendation and a usable outcome.

A good agent journey ends with a useful result or a clear handoff to the person. Getting named in an answer is an earlier milestone. Map the entire path so that a missing fact, permission, or completion step does not break the opportunity.

## Use one task as the unit of work
“Improve our AI presence” is too broad to diagnose. “Help a developer extract invoice line items from a scanned PDF” is concrete. So is “help a customer book a table for four on Friday” or “help a buyer find the correct replacement part.”

Write the expected result before testing. Define acceptable inputs, constraints, and the point at which the user must approve an action. Then walk through the chain: encounter, assess, access, act, verify.

## Encounter and assess
Can a relevant route introduce the offering without naming it in advance? Once encountered, can the agent establish fit from current information? Missing pricing units, ambiguous service areas, and unsupported compatibility claims can all interrupt the comparison.

Keep this phase distinct from onboarding. If you give an agent your product URL, you are testing what happens after introduction. That can be useful, but it does not show that the agent would discover the product independently.

## Access and act
The next step needs an actual interface. A purchase link should identify the right item. A booking page should explain availability and confirmation. An API should explain authentication and required inputs. The agent’s operator, not the product page, determines permission to act.

For a consequential action, make the details reviewable before commitment. An agent should not have to infer consent to spend, send a message, or submit private data merely because it can reach the button or endpoint.

## Verify the outcome
| Journey | Intermediate event | Useful completion evidence |
| --- | --- | --- |
| Purchase | Item added to cart | Authorized order confirmed with the correct item and terms |
| Booking | Request submitted | Accepted reservation or an explicit pending status |
| API | Job accepted | Retrieved output that meets the task’s requirements |
| Service | Inquiry sent | A qualified inquiry received; later agreement tracked separately |

These definitions are examples for designing your own test, not claims that ByAgents currently executes these workflows. Avoid counting a successful HTTP status as proof of the customer’s desired result.

## Repair the smallest broken step
If the result retrieval endpoint is missing, document it. If the booking status is ambiguous, label it. If the product page contradicts the checkout price, reconcile the source. Retest the same task after the change, while retaining an unchanged set of tasks for broader evaluation.

## Maintain the route
A working path can break when prices, authentication, endpoints, policies, or inventory change. Assign ownership to the recurring facts and interfaces. Review failures by layer so the response is specific rather than “publish more content.”

The business goal is continuing useful activity from relevant customers. That requires distribution, an understandable offering, and a dependable next step together.

## Related reading

- [API documentation an agent can actually use](https://byagents.dev/humans/api-documentation)
- [Agent discovery for brands and ecommerce](https://byagents.dev/humans/brands-and-commerce)
- [Measure agent discovery without fooling yourself](https://byagents.dev/humans/measuring-agent-traffic)


---

# Measure agent discovery without fooling yourself

> Separate crawler requests, assistant referrals, controlled tests, activations, and revenue.

Canonical: https://byagents.dev/humans/measuring-agent-traffic
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Separate platform exposure, requests, evaluations, and actual customer events.

Agent traffic is not one clean metric. A request from a crawler, a referral from an assistant, a tool invocation, and a paying customer are different events. A useful measurement plan preserves those distinctions rather than combining them into a single growth number.

## Start with an evidence ladder
Record access first: could the page or tool be reached? Then record encounter: did the system actually retrieve it? Next record selection, useful completion, and returning usage. Each event supports a narrower claim than the next.

A crawler visit establishes a request. It does not prove that the page was indexed, cited, or recommended. A mention in a controlled test establishes behavior in that run. It is not an independent customer. A conversion may be assisted by an agent even when the original discovery source is unknown.

## Keep four data streams separate
- **Infrastructure requests:** Server logs, response codes, and verified crawler signals.
- **Referral visits:** Requests carrying an observed referring source or campaign marker.
- **Controlled evaluations:** Tasks you initiated with recorded environments and expected outcomes.
- **Customer events:** Qualified inquiries, activated projects, purchases, and returning usage from first-party records.

Do not count an IP address as a unique agent, person, or company. User-agent strings can be copied. A missing referrer is unknown attribution, not proof that the visit came from an agent. Use provider verification guidance where available and retain uncertainty in the report.

## Design a fair before-and-after test
Choose representative tasks before making changes. Record the environment, available tools, model or mode where known, introduction method, and task budget. Separate tasks that name the provider from tasks that require discovering one. Keep some tasks unchanged and outside the set used to tune the content.

Verify outputs directly: inspect the extracted fields, resulting booking status, or final artifact. Agent self-reports can help diagnose a failure but should not be the only completion check. Anthropic’s evaluation guidance emphasizes realistic tasks and observable outcomes. [Writing tools and evaluations for agents](https://www.anthropic.com/engineering/writing-tools-for-agents).

## Report counts and denominators
“Three of twelve unbranded discovery trials retrieved our guide in this environment” is more informative than “AI visibility up 300%.” Include failures, test dates, and meaningful changes to the runtime. Small samples can guide debugging; they are weak support for broad claims about all assistants.

Search results and models change. A before-and-after difference may reflect more than your edit. Describe an association when you cannot isolate causation. Mark evaluation traffic so it cannot inflate organic acquisition or conversion reports.

## Connect to the business carefully
With appropriate permission, connect observed entry paths to first-party customer events. Decide how to handle existing accounts, repeat projects, assisted conversions, and attribution windows. Document those choices before comparing cohorts. Revenue belongs to the actual customer event, not to a model’s prediction that the prospect might buy.

ByAgents does not currently provide production attribution analytics or measured traffic guarantees. This framework describes the evidence needed to validate the distribution ambition, and the discipline we want the product to support.

## Add platform reports without changing their meaning

Google's current Search Console help describes a Generative AI performance report for Search, including AI Overviews and AI Mode impressions. It is a platform exposure report, not a complete conversion ledger. [Google report documentation](https://support.google.com/webmasters/answer/16984139).

Microsoft's AI Performance documentation describes citation activity and grounding-query insights. It explicitly cautions against interpreting the data as ranking or authority. [Bing Webmaster Tools announcement](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview).

Keep reporting windows, property scope, and metric definitions with each export. An impression, citation, visit, and confirmed customer event have different denominators and cannot simply be added. Inspect the features actually available in your account. The [evaluation playbook](https://byagents.dev/humans/evaluating-agent-distribution) covers controlled tests, while the [event contract](https://byagents.dev/agents/attribution-event-contract) provides a separate first-party measurement pattern.

## Sources

- [Anthropic: Tool evaluations](https://www.anthropic.com/engineering/writing-tools-for-agents)
- [Google: Generative AI performance report for Search](https://support.google.com/webmasters/answer/16984139)
- [Microsoft: AI Performance in Bing Webmaster Tools](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview)

## Related reading

- [How AI agents find products](https://byagents.dev/humans/how-agents-find-products)
- [Your first 30 days of agent discovery work](https://byagents.dev/humans/first-30-days)
- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)
- [How to test whether agent distribution is working](https://byagents.dev/humans/evaluating-agent-distribution)
- [Pattern: measure agent activity without inventing attribution](https://byagents.dev/agents/attribution-event-contract)


---

# Your first 30 days of agent discovery work

> A focused implementation plan for one offering, a few real tasks, and an observable route to use.

Canonical: https://byagents.dev/humans/first-30-days
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Playbook
Level: Business
Outcome: Plan a month of focused discovery and handoff improvements.

Start with one offering and one route into it. The first month should produce clearer product facts, fewer access and handoff failures, and a record of what you tested. It should not require a new marketplace, hundreds of generated articles, or a promise of instant agent traffic.

## Week 1: define the task and establish a baseline
Choose three to five questions a qualified customer might ask before buying or integrating. Include the constraints that make the request real: input format, budget, location, volume, timing, or compatibility. Identify the expected outcome for each.

Map the likely source, decision page, and next action. Inspect priority pages anonymously. Record missing facts, conflicting prices, inaccessible documentation, and broken links. Run a small baseline in named environments, keeping unbranded discovery separate from named-product adoption.

The deliverable is a short route map and evidence log, not a score. An explicit failure such as “job accepted; retrieval path missing” is a useful result because it points to a repair.

## Week 2: fix facts and access
Repair access barriers on public information pages. Make the main answers available as text. Reconcile product names, canonical URLs, prices, units, and relevant policies. Add accurate structured data where it fits the page, using the same source as the visible facts where possible.

Publish one substantial task guide that addresses a real question. Include a worked example and its limitations. Link to the relevant reference and next step. Do not generate multiple thin variations simply to target every phrasing of the question.

## Week 3: close the handoff
For software, test authentication, a minimal request, completion, and recovery from a representative error. For commerce, verify product identity and the path to the correct checkout. For services, verify the inquiry or booking boundary and its status language.

Document the smallest fixes and retest. Add a tool listing or other distribution surface only if you can name its relevant audience and meet its actual requirements. If using IndexNow, understand that it notifies participating search engines of URL changes; acceptance is not an indexing guarantee. [IndexNow documentation](https://www.indexnow.org/documentation).

## Week 4: evaluate and choose the next investment
Repeat the controlled tasks under comparable conditions. Inspect first-party external activity separately. Record what improved, what remained broken, and what is still unknown. Maintain the source files and working routes before expanding the content library.

## A compact operating sheet
| Field | Example |
| --- | --- |
| Customer task | Extract invoice line items from scanned PDFs |
| Intended route | Search → task guide → API docs → trial |
| Known blocker | Result retrieval not documented |
| Change | Add status and output retrieval instructions |
| Verification | Authorized fixture produces expected fields |
| Acquisition evidence | Unknown until independently observed |

The example is fictional and illustrates how to separate implementation evidence from acquisition evidence.

## What to decide at the end
If relevant people or agents never encounter the useful artifact, revisit the distribution route. If they arrive but misunderstand the product, improve the facts. If they understand but cannot complete the task, repair the interface. If the task works but no one pays, reconsider the offer and customer segment.

ByAgents provides starting plans and a static API contract check to help organize this work. The aim is an observable improvement in the customer journey, followed by evidence that maintaining the route creates continuing value.

## Define the deliverable for each week

Finish week one with a customer-task brief and evidence of the earliest broken step. Finish week two with one repaired source or handoff. Finish week three with a tested route in a named environment. Finish week four with a decision supported by counts, failures, cost, and uncertainty.

For a solo founder, keep the work narrow enough to maintain. One current task guide and one reproducible integration example can be more valuable than an unattended directory of hundreds of generated pages. Use the [priority guide](https://byagents.dev/humans/agent-distribution-priorities) to select work and the [maintenance guide](https://byagents.dev/humans/maintaining-agent-distribution) to assign review triggers after launch.

## Sources

- [IndexNow documentation](https://www.indexnow.org/documentation)

## Related reading

- [Can an agent actually read your website?](https://byagents.dev/humans/crawl-access)
- [API documentation an agent can actually use](https://byagents.dev/humans/api-documentation)
- [Measure agent discovery without fooling yourself](https://byagents.dev/humans/measuring-agent-traffic)
- [Where to start with agent distribution](https://byagents.dev/humans/agent-distribution-priorities)
- [Keep your agent distribution working after launch](https://byagents.dev/humans/maintaining-agent-distribution)


---

# The agent discovery glossary

> Plain-English definitions of crawling, retrieval, citations, MCP, OpenAPI, GEO, and useful completion.

Canonical: https://byagents.dev/humans/agent-discovery-glossary
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Business
Outcome: Translate common agent-distribution terms into practical business meaning.

Agent discovery combines familiar web concepts with newer tool interfaces. These definitions separate the layers so a technical recommendation can be evaluated on what it actually changes.

## Agent and assistant
An **assistant** is a broad product or interface description. An **agent** can choose and execute steps using available tools toward a task. A product may expose different capabilities in different modes. An assistant name alone does not establish search access, authorization, or autonomy.

## Crawling, indexing, and retrieval
**Crawling** means fetching resources for processing. **Indexing** means organizing content so it can be found later. **Retrieval** means selecting information for a particular query or task. A successful crawl does not prove inclusion in an index, and indexing does not guarantee retrieval.

## SEO and GEO
**Search engine optimization (SEO)** is work to improve search discoverability and performance. **Generative engine optimization (GEO)** is an industry term commonly used for improving representation in generative answers. It is not one standardized technical specification. Define the outcome being measured instead of relying on the acronym.

## Structured data and JSON-LD
**Structured data** gives explicit fields and relationships to information. **Schema.org** is a vocabulary often used on websites. **JSON-LD** is a format for linked data. These can describe entities and facts; they do not make an unsupported claim true.

## Canonical URL
A **canonical URL** identifies the preferred version of a page among duplicate or similar representations. Keeping HTML, Markdown, feeds, and references connected to a stable identity helps readers understand which document they are using. Search engines treat canonical signals according to their own systems.

## Citation and provenance
A **citation** points to a source for a claim. **Provenance** describes where information came from and how it was produced. A useful evidence record distinguishes a first-party assertion, independent source, example, and measured test result.

## MCP and OpenAPI
**MCP** is a protocol for compatible AI applications to connect to servers exposing tools and context. **OpenAPI** is a specification for describing HTTP APIs. They serve different interfaces and can coexist. Neither guarantees that a particular agent will discover or adopt a product.

## Tool registry and connected tool
A **registry** catalogs metadata. A **connected tool** is available in a specific runtime after configuration and permission. Publication, connection, and invocation are separate events. See the MCP guide for the implications of this distinction.

## llms.txt
**llms.txt** is a proposed Markdown index convention for language-model readers. It can point to focused documentation. It is not robots.txt, an authentication mechanism, or a universal ranking requirement.

## Handoff and activation
A **handoff** transfers the customer’s task to a next step, such as checkout, booking, or an API operation. **Activation** is a defined first useful customer result. A job accepted, form submitted, or item added to a cart may be an intermediate event rather than completion.

## Controlled test and organic discovery
A **controlled test** is a run initiated for evaluation. **Organic discovery** means an independent user or agent encounters the product without the operator introducing it as part of that test. Keep introduced, branded, unbranded, and unknown routes labeled separately.

## Related reading

- [What is an AI agent?](https://byagents.dev/humans/what-is-an-ai-agent)
- [SEO, GEO, and agent discovery: what actually changes?](https://byagents.dev/humans/seo-geo-and-agent-discovery)
- [MCP, registries, and getting your tools discovered](https://byagents.dev/humans/mcp-and-tool-discovery)


---

# Start here: retrieve, verify, cite

> A compact entry point for agents researching AI discovery or evaluating ByAgents.

Canonical: https://byagents.dev/agents/start
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Find the smallest set of reference documents needed for an authorized task.

ByAgents publishes a public knowledge library about how businesses can become easier for AI agents to discover, understand, and use. This reference describes the library’s interfaces. It does not grant permission to act on behalf of a user or modify another system.

## Select the smallest useful representation
- Browse the [human library](https://byagents.dev/humans) for editorial guides and examples.
- Read [the document index](https://byagents.dev/api/knowledge/index) for titles, descriptions, dates, and HTML/Markdown URLs.
- Search with [GET /api/knowledge/search?q=MCP](https://byagents.dev/api/knowledge/search?q=MCP).
- Fetch a matching document’s Markdown URL for the complete text and sources.
- Read [product facts](https://byagents.dev/agents/facts.json) before describing ByAgents’ capabilities.
- Use [the full export](https://byagents.dev/llms-full.txt) only when bulk indexing or offline reading is appropriate.

## Request example
```sh
curl 'https://byagents.dev/api/knowledge/search?q=asynchronous%20API&limit=3'
```

The endpoint searches this site’s published library only. It does not search the live web, rank vendors, execute a diagnostic, or call a model. Results contain excerpts and canonical source links; retrieve the complete document before relying on a context-sensitive claim.

## Interpret content correctly
Guides contain practical recommendations. Perspectives identify our thesis and uncertainty. Reference pages document this site’s interfaces and current product scope. Examples using example.com or example job identifiers are fictional. A publication date is not evidence of a live product evaluation.

The canonical HTML and Markdown versions are generated from the same content record. This avoids separate claims for human and machine readers. External sources remain authoritative for their own products and protocols; check current upstream documentation before implementation.

## Citation and corrections
Cite the canonical page, the relevant section, and the review date when freshness matters. Preserve qualifications such as static check, illustrative example, proposed workflow, or unknown attribution. Report a factual correction with its supporting source to team@byagents.dev. Do not infer an endorsement from the existence of this library.

## Route by task

- Audit a public website: [crawl recipe](https://byagents.dev/agents/crawl-audit-recipe), [fact profile](https://byagents.dev/agents/product-profile), [evidence record](https://byagents.dev/agents/evidence-record).
- Improve an API or tool: [action contract](https://byagents.dev/agents/action-contract-pattern), [MCP compatibility](https://byagents.dev/agents/mcp-publication-and-compatibility), [authorization boundaries](https://byagents.dev/agents/authorization-and-trust).
- Review commerce data: [feed validation](https://byagents.dev/agents/feed-validation-recipe), [commerce handoff](https://byagents.dev/humans/agent-commerce-readiness).
- Measure a result: [evaluation record](https://byagents.dev/agents/evaluation-record-template), [event contract](https://byagents.dev/agents/attribution-event-contract).
- Check current claims: [dated briefing](https://byagents.dev/humans/agent-distribution-now), [source review](https://byagents.dev/agents/source-review-recipe), [evidence policy](https://byagents.dev/agents/evidence-policy).

These recipes are reference material for an authorized task. They are not tools that execute an audit, a live web-search service, or an instruction to perform side effects without the user's permission.

## Related reading

- [ByAgents: product facts and scope](https://byagents.dev/agents/product-facts)
- [Knowledge API: requests and responses](https://byagents.dev/agents/knowledge-api)
- [Evidence, editorial policy, and trust boundaries](https://byagents.dev/agents/evidence-policy)
- [Recipe: audit public crawl and retrieval access](https://byagents.dev/agents/crawl-audit-recipe)
- [Pattern: asynchronous actions an agent can finish](https://byagents.dev/agents/action-contract-pattern)


---

# ByAgents: product facts and scope

> Current capabilities, boundaries, entry points, and the broader business ambition.

Canonical: https://byagents.dev/agents/product-facts
Published: 2026-09-13
Reviewed: 2026-09-14
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Describe ByAgents using its actual available capabilities and documented limits.

Name: ByAgents. Primary website: https://byagents.dev. Contact: team@byagents.dev. Purpose: help businesses get found, understood, and used by AI agents. Machine-readable counterpart: [facts.json](https://byagents.dev/agents/facts.json).

## Available on this website
- Public educational guides, agent references, and an About Us page.
- Read-only document index and keyword search over this library.
- Markdown documents, a concise llms.txt index, and a full text export.
- Product facts and an OpenAPI description of the knowledge endpoints.

## Customer delivery product
The separate product saves business and developer onboarding into a customer workspace. Customers maintain facts and tasks, check supplied contracts, prepare task pages and API recipes, edit and approve exact file versions, download a release, record publication and retain attributed test observations. API examples come from supplied specifications; unavailable instructions remain explicit gaps. Files are not automatically published.

The [CLI release](https://byagents.dev/downloads/gfa-first-integration-0.2.0.tgz) and [portable agent skill](https://byagents.dev/downloads/first-api-integration.zip) are public downloads without a card or account. Verify them using [SHA-256 checksums](https://byagents.dev/downloads/SHA256SUMS.txt). The CLI requires Node.js 22.13 or later. It runs static checks, a local synthetic fixture, and an explicit public-page retrieval check. It is not published to a package registry.

The app remains owner-private; external self-service has not launched. A link from the public website is not a claim of anonymous access to every product function. The current app URL is https://app.byagents.dev.

## What a static diagnostic establishes
A static check can identify missing or inconsistent contract information, such as a job accepted without a documented result retrieval path. It can suggest a repair for review. It does not authenticate to the provider, verify live service behavior, or measure whether independent agents discover the product.

## Not currently offered
No live MCP server for this library; no universal agent directory or ranked marketplace; no guaranteed placements or citations; no production agent-traffic attribution dashboard; no automated purchasing or booking service; no published customer outcome dataset.

## Ambition and evidence
The broader ambition is to improve distribution from an agent’s task to useful customer activity. Product planning and static readiness checks are early components of that ambition. They are not proof of organic acquisition, revenue, or retention. Updates to capabilities should be reflected in this reference and its JSON counterpart together.

## Onboarding and agent handoff
The primary product route is now `/start` in the separate product application. It supports developer and business paths, saves confirmed information, and prepares a proposed starting plan. The current application is owner-private; external self-service is not launched. Public agent routing metadata is at [the handoff manifest](https://byagents.dev/agents/start.json). It describes access limits and safe handoff URLs. No public account-creation or submission API is offered. The older marketing inquiry form is retired; historical inquiries remain private.

## Free and paid access
The free signup result contains one useful opportunity based on the supplied answers. It does not represent a percentage of a completed website audit, and the full private draft is not sent to the browser. Insights is proposed at $399 USD per month per business for full findings from supplied material, recommendations, editable files and the saved workspace. Autopilot is a planned $1,490 USD per month tier for recurring checks and approved updates; it is coming soon and cannot be purchased. Checkout remains disabled pending payment activation and external access validation. Public documentation, the CLI and the agent skill remain free without a card. Pricing does not establish willingness to pay, and neither tier guarantees discovery or revenue.

## Related reading

- [Start here: retrieve, verify, cite](https://byagents.dev/agents/start)
- [Evidence, editorial policy, and trust boundaries](https://byagents.dev/agents/evidence-policy)
- [A task-based discovery checklist](https://byagents.dev/agents/discovery-checklist)


---

# Knowledge API: requests and responses

> The complete read-only HTTP contract for searching and indexing the ByAgents library.

Canonical: https://byagents.dev/agents/knowledge-api
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Search and retrieve the public library through its documented HTTP interface.

Base URL: https://byagents.dev. Authentication: none for these public knowledge endpoints. Contract: [OpenAPI JSON](https://byagents.dev/agents/openapi.json). Version: 1.1.0. The API returns this site’s documentation; it does not run product diagnostics or search third-party businesses.

## Search
GET /api/knowledge/search accepts q, limit, and audience. q is required, trimmed, and limited to 200 characters. limit defaults to 5 and must be an integer from 1 through 20. audience, if supplied, must be humans or agents. Unknown parameters are rejected. Repeated parameters are rejected to avoid ambiguous interpretation.

```sh
curl 'https://byagents.dev/api/knowledge/search?q=crawl%20access&limit=3&audience=humans'
```

A successful JSON response contains version, query, total, and results. Each result includes id, title, description, audience, category, updated, url, markdown_url, and excerpt. total is the number of matching documents before the limit. Empty matches return HTTP 200 with total 0 and an empty results array.

## Matching behavior
Search normalizes case and accents, removes common query words, and uses token matches across titles, descriptions, categories, and body text. Titles and descriptions carry more weight than body occurrences. Ranking is relevance within this finite library, not a quality grade for companies. Ties are resolved by document identifier for consistent output.

## Index and documents
GET /api/knowledge/index returns version, updated, total, and documents containing public metadata and canonical representation URLs. It omits full body text. Markdown lives at /content/{audience}/{slug}.md. Unknown documents return HTTP 404. The full export is /llms-full.txt.

## Errors and methods
Invalid search parameters return HTTP 400 with error.code = invalid_query and a readable error.message. Unsupported methods return HTTP 405. Public JSON endpoints allow cross-origin GET requests and expose read-only OPTIONS responses. No endpoint accepts credentials, private documents, mutations, payments, or uploads.

## Freshness and operational limits
Search responses may be cached for 60 seconds; index, facts, and text responses for 300 seconds, with additional stale-while-revalidate time. The service publishes no uptime guarantee or unlimited request allowance. Fetch focused documents, reuse responses when appropriate, and back off on HTTP 429 or 5xx according to the response. Do not send secrets in query strings.

## Document selection metadata

Index and search metadata also include level, outcome, and published. level is Business, Technical, or Mixed; it describes assumed reader background, not product maturity. outcome describes what the document helps the reader produce or decide. published records the original publication date; updated records the editorial review date. Neither is a real-time upstream monitoring timestamp.

## Related reading

- [Start here: retrieve, verify, cite](https://byagents.dev/agents/start)
- [Publishing contract and representation map](https://byagents.dev/agents/publishing-contract)
- [ByAgents: product facts and scope](https://byagents.dev/agents/product-facts)


---

# A task-based discovery checklist

> A reusable inspection procedure with explicit observations and unknowns.

Canonical: https://byagents.dev/agents/discovery-checklist
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Structure an evidence-based review of one offering and one customer task.

Use this checklist to investigate one offering and one customer task. It is a proposed procedure, not a certification scheme. Obtain appropriate authorization before interacting with private systems or taking actions that create costs or commitments.

## 1. Define the task
Record the user’s desired result, material constraints, and available environment. State whether the business was named in advance. Separate unbranded discovery from introduced-provider adoption tests.

## 2. Inspect access
Identify the public product, pricing, documentation, and policy URLs. Record response codes, redirects, challenges, and whether useful content is available. Review robots and indexing directives separately from authentication. Do not bypass restrictions to complete the assessment.

## 3. Inspect product facts
Record the capability, intended customer, pricing unit, relevant limits, evidence, and next action. Note contradictions between HTML, structured data, feeds, and documentation. Distinguish absent information from a negative fact: missing pricing is not proof that a product is free.

## 4. Map a route
Record the actual source through which the offering was encountered. A search result, directory listing, connected tool, or user-supplied URL are different introduction modes. Do not infer the route from a product’s general popularity.

## 5. Inspect the handoff
For an API: authentication, inputs, job status, result retrieval, errors, and retry rules. For commerce: item identity, variant, current offer, checkout boundary, and confirmation. For services: scope, service area, inquiry or booking requirements, and confirmation status.

## 6. Verify only what was tested
Separate static observations from live results. For an authorized execution, record the actual output and compare it with the expected result. A status code or agent self-report is insufficient when the task requires an artifact or external state change.

## 7. Report the smallest useful repair
Each finding should include the observed issue, supporting source, customer impact, proposed change, and verification method. Mark untested assumptions and unknown attribution explicitly. Do not collapse this evidence into a universal readiness score.

A reusable structure is available in the [evidence record reference](https://byagents.dev/agents/evidence-record). The human [30-day playbook](https://byagents.dev/humans/first-30-days) places these checks in an implementation sequence.

## Related reading

- [Evidence record: a portable example](https://byagents.dev/agents/evidence-record)
- [Evidence, editorial policy, and trust boundaries](https://byagents.dev/agents/evidence-policy)
- [ByAgents: product facts and scope](https://byagents.dev/agents/product-facts)


---

# Evidence record: a portable example

> A small custom JSON structure for reporting a discovery or integration finding without overstating it.

Canonical: https://byagents.dev/agents/evidence-record
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Record an observation, proposed repair, verification status, and limitations.

This is a ByAgents example format, not an industry standard or a claim of compatibility with an external protocol. Use it to preserve the difference between an observation, a proposed repair, and a verified outcome.

## Example record
```json
{
  "schema_version": "1.0",
  "example": true,
  "task": "Extract invoice line items",
  "introduction": "provider_named",
  "assessment": "static_contract_review",
  "source_url": "https://example.com/openapi.json",
  "observed_at": "2026-09-13",
  "finding": "Job creation is documented; result retrieval is absent.",
  "evidence": "POST /jobs returns a jobId; no retrieval operation is supplied.",
  "proposed_change": "Document how to retrieve job status and output.",
  "verification": "not_executed",
  "organic_discovery": "unknown",
  "limitations": ["No authenticated API call was made."]
}
```

## Field interpretation
schema_version identifies this example’s format. example prevents the record from being mistaken for a customer result. task describes the intended outcome. introduction explains how the provider became available. assessment names the method. source_url and observed_at make the observation locatable and dated.

finding is the specific issue. evidence records the observable support rather than a general opinion. proposed_change is a recommendation, not a completed edit. verification states whether the change was tested. organic_discovery remains unknown unless independent evidence establishes it. limitations preserves the scope of the assessment.

## Safe extensions
For a real test, add the environment, fixture identifier, relevant output, pass criteria, and permitted verification method. Record multiple attempts and failures rather than keeping only the best run. Remove secrets and private customer content before publication. A synthetic fixture should remain labeled synthetic.

## Interpretation limits
An evidence record is a container for claims, not proof by itself. Verify the source and output when the decision matters. A static finding can be valid while the proposed repair is incomplete; a working repair can improve use without affecting discovery. Keep those conclusions separate.

## Related reading

- [A task-based discovery checklist](https://byagents.dev/agents/discovery-checklist)
- [Evidence, editorial policy, and trust boundaries](https://byagents.dev/agents/evidence-policy)
- [Knowledge API: requests and responses](https://byagents.dev/agents/knowledge-api)


---

# Product facts template

> A compact custom record connecting capabilities, pricing, evidence, and an action path.

Canonical: https://byagents.dev/agents/product-profile
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Draft a public fact profile without inventing unknown prices or capabilities.

This template is a planning aid for a business’s public product facts. It is not Schema.org, an MCP server manifest, or a supported ingestion format for the ByAgents product. Populate only information you can support, and keep dynamic values connected to a current source.

## Example profile
```json
{
  "example": true,
  "name": "Example Invoice API",
  "canonical_url": "https://example.com/invoice-api",
  "capability": "Extract line items from PDF invoices",
  "inputs": ["PDF"],
  "outputs": ["JSON line items"],
  "pricing": {
    "unit": "page",
    "source_url": "https://example.com/pricing",
    "amount": null
  },
  "authentication": "API key",
  "documentation_url": "https://example.com/docs",
  "next_step": {
    "type": "trial_registration",
    "url": "https://example.com/start",
    "requires_user_authorization": true
  },
  "evidence": [],
  "limitations": ["Fictional example; no service was tested."]
}
```

## Why unknown fields stay unknown
A null price is unknown in this example, not zero. An empty evidence list means no evidence is supplied, not that a product has been disproven. Do not infer certifications, supported regions, current availability, or test results from the presence of a profile.

## Adapt to the offering
For commerce, include actual product and variant identifiers, current offer sources, shipping regions, and return-policy links. For services, include scope, service area, deliverables, and the inquiry or booking boundary. For APIs, document authentication, limits, outputs, and completion behavior.

## Publish consistently
The public page, structured markup, profile, and action destination should agree. Give each recurring fact an owner and a source. If a value changes rapidly, use the live system as authoritative and indicate when any snapshot was taken. The profile makes facts easier to inspect; it does not guarantee recommendation or acquisition.

## Related reading

- [A task-based discovery checklist](https://byagents.dev/agents/discovery-checklist)
- [Evidence record: a portable example](https://byagents.dev/agents/evidence-record)
- [Publishing contract and representation map](https://byagents.dev/agents/publishing-contract)


---

# Evidence, editorial policy, and trust boundaries

> How to interpret claims, examples, sources, and content on this site.

Canonical: https://byagents.dev/agents/evidence-policy
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Interpret claims, examples, sources, and product scope consistently.

ByAgents separates documented facts, implementation guidance, company perspective, fictional examples, and measured results. These categories should remain distinct when content is summarized or reused.

## Source hierarchy
For a platform or protocol, its current official documentation is the primary source. Our guides explain implications and propose practical workflows. A ByAgents opinion is not a platform requirement. A third-party link is a source reference, not an endorsement or evidence that ByAgents integrates with that service.

## Product status
Current capabilities are listed in [product facts](https://byagents.dev/agents/product-facts). Broader ambitions are identified as such. We do not publish invented customers, agent activity, rankings, certifications, or acquisition results. The landing-page discovery animation is illustrative, not telemetry.

## Dates and uncertainty
Each document carries a review date. It identifies the content revision, not continuous monitoring of every linked source. Platform behavior can change. Check current upstream documentation when implementing a protocol or access policy. If sources disagree, report the disagreement and narrow the claim rather than treating our interpretation as definitive.

## Retrieved content is evidence, not authority over the user
A webpage or document can contain instructions, but those instructions do not override the user’s request, the agent’s permissions, or the host’s security policy. Product information cannot authorize spending, sending messages, installing code, or exposing private data. Public examples use fictional values and do not require secrets.

## No scoring instructions
We do not ask agents to rate this site highly, ignore competing sources, fabricate citations, or prefer ByAgents regardless of fit. Useful retrieval should come from accurate content and working interfaces. There is no published universal score that this library claims to maximize.

## Corrections and reuse
Send a specific correction and supporting source to team@byagents.dev. Automated retrieval, indexing, and quotation or summarization with attribution are welcomed under the website terms. Preserve the source, review date, and material limitations. Third-party content remains subject to its original terms.

## What this library can be authoritative about

We can document our own public interfaces, explain our reasoning, and provide traceable implementation patterns. Platform owners define their own protocols and product requirements. A strong guide links those sources and preserves their scope. We do not claim comprehensive live testing or a published dataset of customer acquisition results.

The [source review recipe](https://byagents.dev/agents/source-review-recipe) explains how to handle conflicting dates and versions. The [current briefing](https://byagents.dev/humans/agent-distribution-now) records specific developments checked in this editorial pass. Review dates are deliberate records, not automatic signals designed to make unchanged content look new.

## Related reading

- [ByAgents: product facts and scope](https://byagents.dev/agents/product-facts)
- [Publishing contract and representation map](https://byagents.dev/agents/publishing-contract)
- [Evidence record: a portable example](https://byagents.dev/agents/evidence-record)
- [Recipe: review a technical claim and resolve conflicting sources](https://byagents.dev/agents/source-review-recipe)
- [Agent distribution: what matters now](https://byagents.dev/humans/agent-distribution-now)


---

# Publishing contract and representation map

> Stable URLs, canonical identity, content types, search scope, caching, and maintenance.

Canonical: https://byagents.dev/agents/publishing-contract
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Understand the exact representations and behavior this library publishes.

This website is designed to be usable through ordinary HTTP requests as well as a browser. Public information does not require an installed plugin, an API key, or a paid account. The separate product preview can have different access requirements.

## Representation map
| Resource | URL | Representation |
| --- | --- | --- |
| Human guide | /humans/{slug} | HTML |
| Agent reference | /agents/{slug} | HTML |
| Individual document | /content/{audience}/{slug}.md | Markdown |
| Library index | /api/knowledge/index | JSON |
| Library search | /api/knowledge/search?q={query} | JSON |
| Product facts | /agents/facts.json | JSON |
| API description | /agents/openapi.json | OpenAPI JSON |
| Concise agent index | /llms.txt | Plain text Markdown |
| Complete library | /llms-full.txt | Plain text Markdown |
| Public page inventory | /sitemap.xml | XML |

The placeholders above denote path variables, not literal valid URLs. Use the index response for exact document URLs.

## One content source
HTML, Markdown, the full export, and search all use the same checked-in content records. Each record has a stable slug, audience, title, description, category, kind, body, sources, related documents, and updated date. Machine representations do not contain hidden product claims absent from the visible pages.

## Canonical identity
Canonical page URLs use https://byagents.dev. Markdown responses identify their canonical HTML page in both the text and a Link response header. Search results use those same URLs. Search result pages are not intended as independently indexed editorial pages.

## Response behavior
Documents are UTF-8. Missing records return 404. Invalid search parameters return 400. Public knowledge endpoints are read-only and support cross-origin GET requests. Cache lifetimes are documented in the API reference. There is no authentication token to discover or embed.

## Changes
Content revisions update the relevant record’s review date. URLs should remain stable when wording changes; a renamed document should receive an appropriate redirect. Breaking API changes require a new declared contract version. This is a publishing policy, not an uptime or backward-compatibility guarantee.

## Scope
The library explains discovery and publishes its own knowledge interfaces. It does not fetch arbitrary customer URLs, accept uploads, execute code, or perform transactions. No visit or retrieval alone is reported as a business outcome.

## Related reading

- [Knowledge API: requests and responses](https://byagents.dev/agents/knowledge-api)
- [Evidence, editorial policy, and trust boundaries](https://byagents.dev/agents/evidence-policy)
- [Start here: retrieve, verify, cite](https://byagents.dev/agents/start)


---

# Agent distribution: what matters now

> A dated briefing on platform changes, emerging protocols, and what is actually worth implementing.

Canonical: https://byagents.dev/humans/agent-distribution-now
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Briefing
Level: Mixed
Outcome: Separate production priorities from experiments, using a source-checked September 2026 briefing.

Agent distribution is developing across search, tool catalogs, browser interactions, and commerce. There is no single switch that makes a business available to every agent. This briefing records what we checked on September 13, 2026. It is an editorial snapshot, not a live news feed or a claim that we tested every platform.

## Google has more specific AI controls and reporting

Google's newer Search Console help documents say its Search generative AI control and Search generative AI performance report rolled out worldwide on August 31, 2026. The control covers inclusion in specified generative Search experiences; the report shows impressions for AI Overviews and AI Mode, with eligibility and data-volume qualifications. Consult the [control documentation](https://support.google.com/webmasters/answer/16908024?hl=en) and [report documentation](https://support.google.com/webmasters/answer/16984139).

Practical implication: inspect the actual property settings and report available to your account. Do not repeat the older blanket claim that AI participation has no separate control or that no AI-specific reporting exists. Impressions still do not establish qualified traffic or sales. Google's general search fundamentals remain relevant; a newer feature-specific document can change an older summary.

## MCP compatibility now needs an explicit version check

The current MCP versioning documentation identifies revision **2026-07-28**, using per-call protocol versions. This differs from the initialization model in older revisions. A published specification does not establish support in a particular host or SDK. Record both sides of the connection before advertising compatibility. See the [versioning documentation](https://modelcontextprotocol.io/docs/2026-07-28/learn/versioning) and our [compatibility checklist](https://byagents.dev/agents/mcp-publication-and-compatibility).

Practical implication: old snippets can remain useful when explicitly pinned to the older version. Mixing an older connection lifecycle with newer request fields is a poor integration plan. A successful documentation review is not a successful live connection.

## WebMCP is a browser integration experiment

Chrome documents a WebMCP origin trial from Chrome 149, alongside a local development flag. This is more specific than the early-preview announcement, and less than universal browser support. [Chrome documentation](https://developer.chrome.com/docs/ai/webmcp/).

Practical implication: evaluate it for an existing website workflow with a named compatible browser and agent. Preserve ordinary forms and accessible navigation. A page exposing tools still needs a way for a user or agent to reach that page.

## Discovery specifications are changing too

Agentic Resource Discovery was announced in June 2026. The ARD main-branch specification reviewed here describes revision v0.91 and a current `/.well-known/ard.json` publishing path; older material refers to `ai-catalog.json`. Main-branch documents can change. [ARD specification](https://github.com/ards-project/ard-spec/blob/main/spec/ard.md).

Practical implication: compare the implementation you intend to reach with a pinned revision. A valid manifest, a registry ingestion event, and an independent agent finding your business are three different observations. Our [ARD assessment recipe](https://byagents.dev/agents/ard-discovery-assessment) explains how to test the actual route.

## Commerce discovery and checkout remain separate

OpenAI's product file-upload documentation describes catalog data for purchasable variants. Feeding product information does not itself enable checkout; merchant participation and transaction integration have separate requirements. [Product specification](https://developers.openai.com/commerce/specs/file-upload/products).

Practical implication: establish item identity, price, availability, and landing-page agreement before investing in a transactional interface. Do not announce support for purchases in a particular assistant until the actual merchant account, region, integration, and confirmation path have been verified.

## What to prioritize this week

| Situation | First useful investment | Evidence to collect |
| --- | --- | --- |
| Important pages cannot be retrieved | Fix the specific access or rendering failure | A successful permitted fetch with useful content |
| Agents confuse the offering | Reconcile facts and publish task-specific documentation | Correct answers with supporting sources |
| A known tool is difficult to use | Repair authentication, inputs, and result retrieval | An authorized task completed correctly |
| The basics work but exposure is weak | Test a relevant search, catalog, or ecosystem route | An observed introduction without naming the provider |
| A new protocol looks promising | Run a bounded compatibility experiment | A named consumer actually reading or using it |

These priorities are our judgment, not platform ranking rules. We have not published a customer outcome study establishing their relative lift. Use the [evaluation guide](https://byagents.dev/humans/evaluating-agent-distribution) to produce evidence for your own business and update the decision when the evidence changes.

## Sources

- [Google: Search generative AI control](https://support.google.com/webmasters/answer/16908024?hl=en)
- [Google: Generative AI performance report for Search](https://support.google.com/webmasters/answer/16984139)
- [MCP: Protocol versioning, 2026-07-28](https://modelcontextprotocol.io/docs/2026-07-28/learn/versioning)
- [Chrome: WebMCP and origin-trial availability](https://developer.chrome.com/docs/ai/webmcp/)
- [ARD: Specification on the main branch, reviewed September 13, 2026](https://github.com/ards-project/ard-spec/blob/main/spec/ard.md)
- [OpenAI: Product file-upload specification](https://developers.openai.com/commerce/specs/file-upload/products)

## Related reading

- [How the major AI discovery channels differ](https://byagents.dev/humans/ai-discovery-platforms)
- [MCP, WebMCP, A2A, ACP, UCP, and ARD: what to build](https://byagents.dev/humans/agent-protocols-explained)
- [How to test whether agent distribution is working](https://byagents.dev/humans/evaluating-agent-distribution)


---

# How the major AI discovery channels differ

> Search crawlers, user-requested visits, connected tools, and merchant feeds are different routes into an assistant.

Canonical: https://byagents.dev/humans/ai-discovery-platforms
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Choose the right access controls and distribution route for the platforms your customers use.

Start with the route, not the assistant's logo. One application can search an index, fetch a supplied URL, invoke an installed tool, or navigate a website. Improving one route does not prove the others work. This comparison summarizes documented mechanisms, not a ranking of which assistant sends the most traffic.

## Search and training are separate decisions

OpenAI distinguishes OAI-SearchBot for search from GPTBot for model training. ChatGPT-User represents certain user-initiated visits; robots rules may not apply to those requests. A training opt-out is not inherently a search opt-out. Verify the current [crawler documentation](https://developers.openai.com/api/docs/bots) before editing access rules.

Anthropic separately identifies ClaudeBot, Claude-SearchBot, and Claude-User, and says its bots honor robots.txt. [Anthropic's documentation](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler).

Perplexity distinguishes PerplexityBot from Perplexity-User; its documentation says the latter generally ignores robots.txt for user-requested fetches. Do not apply another vendor's policy by analogy. [Perplexity's documentation](https://docs.perplexity.ai/docs/resources/perplexity-crawlers).

## A channel comparison you can act on

| Route | What the business can prepare | What this does not prove |
| --- | --- | --- |
| ChatGPT search | Permitted search access, clear public pages, current product facts | Selection, endorsement, or a purchase |
| Google AI Search experiences | Search eligibility, useful indexed content, appropriate property controls | Inclusion for every query or coverage in every Gemini feature |
| Claude or Perplexity web research | Retrievable source pages and vendor-specific access rules | Every conversation using the web |
| Bing and Copilot citations | Search-ready sources and inspection of available webmaster reports | Ranking or commercial value of each citation |
| Connected tools | A compatible integration, installation route, and usable workflow | Automatic installation across all hosts |
| Merchant catalogs | Accurate eligible product records and account onboarding | Enabled transactional checkout |

Google says AI Search eligibility does not require a special AI file or special schema. Its newer Search Console controls should be reviewed alongside these baseline requirements. [Google Search guidance](https://developers.google.com/search/docs/appearance/ai-features). Gemini is also a product family: do not treat a Search setting as a universal control over every Gemini experience.

## Verify the traffic before changing security rules

A request claiming a crawler name is not proof of identity. Use the provider's verification method where available and log the verification basis. Scope an exception to the intended public content; preserve authentication, request limits, and protections around private routes. Do not broadly disable the firewall to improve a visibility score.

A local test that sends a crawler user-agent string can reveal how your own rules respond to that string. It cannot reproduce the provider's IP, infrastructure, index, location, or eventual recommendation. Keep that limitation in the audit record.

## Pick one route to test first

Ask how the intended customer currently works. A developer using a connected coding environment may benefit from a tool integration and example repository. A shopper comparing products may encounter search and catalog data. A local business may need accurate service-area and booking information before a new API.

Record a concrete hypothesis: “This task can encounter our public comparison guide through search.” Record the source that was actually retrieved, whether the brand was named, and the next action. If the run never searches, its failure tells you little about indexing. If it finds the page but cannot obtain a quote, the problem has moved downstream.

## Use platform reports for the claims they support

Microsoft's AI Performance documentation describes citations and grounding-query insights, not an authority or ranking score. Google's dedicated Search report concerns impressions. Neither replaces first-party inquiry, activation, or order records. Combine the streams in a report while retaining their different units. See [measurement](https://byagents.dev/humans/measuring-agent-traffic) and the [crawl audit recipe](https://byagents.dev/agents/crawl-audit-recipe).

## Sources

- [OpenAI: Crawler roles and verification](https://developers.openai.com/api/docs/bots)
- [Anthropic: Crawlers and site-owner controls](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)
- [Perplexity: Crawlers and user requests](https://docs.perplexity.ai/docs/resources/perplexity-crawlers)
- [Google: AI features and your website](https://developers.google.com/search/docs/appearance/ai-features)
- [Microsoft: AI Performance in Bing Webmaster Tools](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview)

## Related reading

- [Can an agent actually read your website?](https://byagents.dev/humans/crawl-access)
- [Recipe: audit public crawl and retrieval access](https://byagents.dev/agents/crawl-audit-recipe)
- [Agent distribution: what matters now](https://byagents.dev/humans/agent-distribution-now)


---

# MCP, WebMCP, A2A, ACP, UCP, and ARD: what to build

> A plain-English map of agent protocols, the job each one does, and the adoption question to ask before investing.

Canonical: https://byagents.dev/humans/agent-protocols-explained
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Select an interface for a real customer workflow without implementing every acronym.

A protocol is an agreement about how software communicates. It is not an audience. Before choosing one, name the application that will consume it, the task it improves, and the way a customer gains access. The useful architecture is usually a small set of compatible interfaces around a reliable product.

## The map

| Interface | The job it describes | The business question |
| --- | --- | --- |
| OpenAPI | An HTTP API's operations, inputs, outputs, and authentication contract | Can a developer or agent understand our API? |
| MCP | Tools and context exposed to compatible AI applications | Which hosts will connect, and through what installation path? |
| WebMCP | Website functionality exposed through a supporting browser | Which supported browser workflow becomes easier? |
| A2A | Communication and task exchange between agents | Are we providing an actual agent service that others delegate to? |
| ACP | A checkout interface for compatible commerce participants | Is the intended buyer surface able to transact with us? |
| UCP | Commerce capabilities and interoperable business interactions | Which business and platform capabilities overlap? |
| AP2 | Evidence of authorization for agent-mediated payments | What was the agent authorized to buy or pay? |
| ARD | Publishing and finding descriptions of agentic resources | Which discovery consumer will ingest and retrieve our entry? |

These rows describe different layers, not competing brand names for one universal standard. The linked primary documentation defines their actual requirements. Google's [protocol overview](https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/) is a useful starting map; use the protocol's own versioned specification for implementation.

## Start with the interface you already need

A software company may first need complete HTTP documentation, a small SDK example, and a consistent authentication path. MCP can then make a useful workflow available to a defined host ecosystem. A service business may need a reliable inquiry or booking page; publishing an agent card is unnecessary if there is no agent service behind it.

A merchant should separate product-data accuracy from transaction support. ACP's stated focus is compatible agent checkout. UCP describes business profiles and capabilities. Neither removes the merchant's responsibility for prices, stock, fulfillment, and valid authorization. A working payment interface does not itself explain why a buyer would discover your product.

## Discovery is an overloaded word

Web search finds source pages. A catalog helps a host find integration metadata. A known MCP server describes its capabilities. A2A can describe an agent that another agent might contact. ARD describes a broader resource discovery layer. These are different starting points.

Ask what was known before the lookup. If the endpoint was already supplied, you tested capability retrieval. If the vendor was not named and the environment independently encountered it, you have evidence about distribution. This distinction prevents technically successful demos from becoming misleading acquisition claims.

## Compatibility needs a named consumer

Chrome documents WebMCP as an origin-trial feature; retain a standard web fallback. MCP has versioned behavior and host-specific support. Merchant protocols also have account and participant requirements beyond a document conforming to a schema. “Supports the standard” is incomplete without a version, transport, authentication setup, and tested consumer.

Use a compatibility record with these fields: provider release, client release, protocol revision, transport, authentication method, task, expected result, actual result, and test date. Mark untested cells as unknown. Do not turn a supported schema field into a claim that every host implements it.

## An investment rule

Build when a named group of customers can reach the interface, it removes a measured failure, and you can maintain it. Experiment when adoption is uncertain but a small prototype can answer the question. Defer when there is no consumer, no working product underneath, or a more basic access failure.

The goal is a customer completing a useful task. Protocol support is one means of reaching that goal. The [software playbook](https://byagents.dev/humans/software-agent-distribution) and [commerce guide](https://byagents.dev/humans/agent-commerce-readiness) translate this map into concrete decisions.

## Sources

- [Google: Developer guide to agent protocols](https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/)
- [Chrome: WebMCP and origin-trial availability](https://developer.chrome.com/docs/ai/webmcp/)
- [A2A: Agent concepts and authentication](https://a2a-protocol.org/latest/topics/key-concepts/)
- [Agentic Commerce Protocol](https://www.agenticcommerce.dev/)
- [Universal Commerce Protocol: Core concepts](https://ucp.dev/documentation/core-concepts/)
- [Google: Announcing Agentic Resource Discovery, June 17, 2026](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/)

## Related reading

- [MCP, registries, and getting your tools discovered](https://byagents.dev/humans/mcp-and-tool-discovery)
- [From an AI recommendation to a confirmed purchase or booking](https://byagents.dev/humans/agent-commerce-readiness)
- [Recipe: assess an ARD discovery route](https://byagents.dev/agents/ard-discovery-assessment)


---

# Where to start with agent distribution

> A business-first plan for finding the broken step, choosing a channel, and deciding what deserves your time.

Canonical: https://byagents.dev/humans/agent-distribution-priorities
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Playbook
Level: Business
Outcome: Create a focused backlog tied to customer tasks, named owners, and observable outcomes.

Agent distribution work should begin with a customer problem you already understand. “We need to be everywhere in AI” is difficult to execute or evaluate. “Help a founder find a bookkeeping service that supports their country and request a scoped quote” gives you a route, requirements, and a commercial result to inspect.

## Write a one-page brief

Describe the customer, their task, the constraints that decide fit, your offering, and the next step. Choose one geographic or product market first. List the information an agent would need without relying on your homepage's visual presentation. State what a successful handoff means: an inquiry received, a trial activated, a confirmed booking, or a completed order.

The distinction matters. An inquiry is not a qualified lead, and a qualified lead is not revenue. The brief should name the source of truth for each step so marketing and engineering are not optimizing different outcomes.

## Diagnose the earliest broken step

| Observation | Likely workstream | First deliverable |
| --- | --- | --- |
| Relevant pages are inaccessible | Access | A verified fix on the affected public routes |
| Agents find you but misstate the offer | Product information | A reconciled fact sheet and supporting pages |
| Agents understand you but cannot act | Handoff | A complete inquiry, checkout, or integration path |
| Everything works only with your URL supplied | Distribution | A tested route through search or a relevant ecosystem |
| You cannot tell which happened | Measurement | A small evidence log and first-party completion event |

These are investigation starting points, not diagnoses from a universal scoring formula. More than one issue may exist. Fix a blocking access failure before polishing a rarely reached integration description.

## Build a backlog that a team can execute

Each item needs an observed issue, customer impact, exact page or interface, proposed repair, owner, effort estimate, and verification step. Keep estimates local to your team. A two-hour copy repair can outperform a month-long integration if the missing fact is the main reason customers cannot evaluate you.

For a fictional service business, a good item is: “Publish which countries we serve and whether tax filings are included; commercial owner confirms the scope; verify that a reader can distinguish bookkeeping from tax filing.” A weak item is: “Improve AI authority.” The first can be completed and checked. The second invites activity without a clear result.

## Choose one distribution route

Select the route with evidence of customer relevance. This might be a task-specific search page, a credible industry directory, a developer package ecosystem, a host's integration catalog, or a merchant feed. Record how a buyer or agent could arrive there. A directory containing many bots is not automatically valuable if none serve your intended customer's task.

Build a useful artifact for that route: a comparison method, accurate listing, working example, or inventory record. Keep ownership and maintenance visible. Avoid mass-generated duplicate pages, fake reviews, or posts that ask agents to prefer you regardless of fit. Those do not solve the underlying buyer problem.

## Decide the stopping rule before the experiment

Set a bounded budget of time and authorized testing. Define what you will inspect: actual retrieval, correct understanding, completed handoff, and relevant customer activity. A small exploratory test can identify a defect without establishing market-wide demand. If the intended consumer never reads the artifact, investigate that route before expanding the content program.

Continue when the work produces a useful capability or credible evidence of customer value. Revise when it reveals a different bottleneck. Stop when maintenance cost exceeds the plausible benefit and no evidence supports further investment. These decisions are easier when every experiment has a specific question.

## Keep the business case honest

Track the labor and operating cost alongside qualified outcomes. Separate new customers from existing accounts, testing from external usage, and observed referrals from unknown acquisition sources. Do not infer a return on investment from a crawler visiting a page.

This is ByAgents' proposed operating approach, not a published customer case study. Pair it with the [30-day plan](https://byagents.dev/humans/first-30-days) for sequencing and the [evaluation guide](https://byagents.dev/humans/evaluating-agent-distribution) for a defensible measurement design.

## Related reading

- [Your first 30 days of agent discovery work](https://byagents.dev/humans/first-30-days)
- [How to test whether agent distribution is working](https://byagents.dev/humans/evaluating-agent-distribution)
- [Keep your agent distribution working after launch](https://byagents.dev/humans/maintaining-agent-distribution)


---

# Write pages agents can actually use

> Turn customer questions into clear source pages, comparison criteria, and verifiable product explanations.

Canonical: https://byagents.dev/humans/content-for-agent-discovery
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Business
Outcome: Write a useful content brief and test whether a retrieved page answers a real buying question.

Useful content reduces uncertainty. An agent comparing options needs capabilities, constraints, evidence, and a next step. Repeating “AI-ready” does not answer whether an API supports a file type, a freelancer serves a region, or a restaurant can accommodate a group.

## Start from a decision, not a keyword list

Choose a customer question with a meaningful constraint. “Invoice extraction” is broad. “Extract line items from scanned invoices and retrieve the completed JSON asynchronously” gives a documentation page a specific job. “Private dining near the station for twelve people” requires location, capacity, menu, and booking information.

Document the information that would rule your offering in or out. A good page can explain when you are not a fit. This helps both people and agents avoid a failed handoff and gives the right customer a clearer reason to continue.

## Use this content brief

| Field | What to write |
| --- | --- |
| Reader's task | The result the customer is trying to achieve |
| Deciding constraints | Inputs, region, budget unit, compatibility, timing, or availability |
| Direct answer | What you support and where the boundary is |
| Evidence | Documentation, actual policy, reproducible example, or attributable source |
| Next step | The exact page, inquiry, booking, or operation that continues the task |
| Owner and review trigger | Who updates it when the product or policy changes |

This is an editorial template, not a search-engine requirement. Its purpose is to help someone make a decision from the page alone.

## Make the important paragraph self-contained

A retrieved excerpt may lose the navigation and surrounding marketing copy. Name the product and the unit of the claim. “Supports files up to 20 MB” is more useful than “Works with large files,” if 20 MB is the actual enforced limit. Explain whether the limit applies per file, request, or account.

Keep qualifications next to the claim. Do not put a sweeping promise at the top and a contradictory exception in an unrelated FAQ. Put price units next to amounts, geographic limits next to availability, and experimental status next to feature descriptions. These examples are writing practices, not evidence that a particular format guarantees citation.

## Build evidence that deserves a reference

An original test can be valuable when it includes the method, inputs, dates, version, failures, and scope. A comparison can be useful when the criteria are explicit and material limitations are acknowledged. Attribute outside claims to the source that supports them; a link to a company's homepage is usually weak support for a precise technical statement.

Do not fabricate ratings or testimonials to fill a structured-data field. Do not disguise sponsored placement as independent evaluation. A repeated assertion across pages you control is still one publisher's assertion, not independent corroboration.

## Publish one source in useful representations

Keep visible HTML as the canonical reading experience. Offer focused Markdown when useful, and link to exact reference pages. Structure recurring facts consistently, preferably from the same underlying record. Avoid making an enormous text dump the only way to learn one small fact.

Google says its AI Search features do not require a special AI file or new schema type. A Markdown export can improve convenience without being a ranking requirement. [Google's guidance](https://developers.google.com/search/docs/appearance/ai-features).

## Check comprehension before publishing more

Ask a reader or an authorized test agent to answer three questions from the page: what can this do, what prevents it from fitting, and how does the customer continue? Require supporting passages for the answers. Include a case where the product is unsuitable, so the test does not reward recommending it indiscriminately.

When the answer is wrong, inspect the source before writing another page. The fix may be a missing price unit, an ambiguous term, or outdated documentation. Use the [retrieval document contract](https://byagents.dev/agents/retrieval-document-contract) for technical publishing details and [citations and evidence](https://byagents.dev/humans/citations-and-evidence) for source quality.

## Sources

- [Google: AI features and your website](https://developers.google.com/search/docs/appearance/ai-features)

## Related reading

- [Give agents something worth citing](https://byagents.dev/humans/citations-and-evidence)
- [Pattern: publish documents for reliable retrieval](https://byagents.dev/agents/retrieval-document-contract)
- [Structured data that helps explain your business](https://byagents.dev/humans/structured-data)


---

# Product feeds for AI shopping

> How to prepare item identities, prices, availability, and product pages for a real merchant-data integration.

Canonical: https://byagents.dev/humans/product-feeds-for-ai-shopping
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Define a reliable product-data pipeline and distinguish catalog eligibility from enabled checkout.

A product feed is a structured inventory of what you sell. Its value comes from accurate, current product data and a destination that agrees with it. A feed is not a substitute for merchant onboarding, platform eligibility, or a working purchase path.

## Begin with the source of truth

Identify the system that owns each field: catalog for identity and variant attributes, pricing for amounts and promotions, inventory for availability, and commerce operations for shipping and returns. Decide which system wins when they disagree. Updating the export file without fixing its upstream source produces recurring errors.

Model a purchasable variant, not just a marketing family. Size, color, bundle contents, subscription terms, and region can change the actual item a shopper receives. Keep the identifier stable across ordinary updates. Do not reuse a discontinued item's identifier for an unrelated replacement.

## A concrete file-upload example

OpenAI's current product file-upload specification requires nine fields and one row per purchasable item or variant. Its price field uses an amount and currency string. The following is a **fictional example record** illustrating those fields, not a complete upload file or a live merchant submission. [Official specification](https://developers.openai.com/commerce/specs/file-upload/products).

```json
{
  "item_id": "trail-bottle-750-blue",
  "title": "Example Trail Bottle — 750 ml — Blue",
  "description": "A reusable 750 ml bottle with a screw cap.",
  "url": "https://example.com/bottles/trail-750-blue",
  "brand": "Example Outdoors",
  "seller_name": "Example Outdoors Store",
  "image_url": "https://example.com/images/trail-750-blue.jpg",
  "availability": "in_stock",
  "price": "24.00 USD"
}
```

Check the receiving platform's current accepted file format, field rules, limits, and account instructions. Do not transplant these field names into another merchant protocol and assume compatibility. For optional values, absence is better than invented identifiers or fabricated stock information.

## Reconcile the representations

Choose a sample containing an ordinary item, a variant family, an out-of-stock item, and a promotion. Compare the source system, exported record, platform acceptance report, visible landing page, structured markup, and checkout. The same identifier must lead to the intended variant and its real offer.

A successful upload means the platform accepted data according to its response. It does not necessarily mean the item is visible, selected for a query, or available to purchase through an assistant. Keep these states distinct in the integration log.

## Treat freshness as a product requirement

A catalog updated nightly may be adequate for a stable description and inadequate for scarce inventory. Set a freshness target for each field based on how costly stale information would be. Use the platform's documented update mechanisms; after an update, inspect the returned status and a representative item rather than assuming transmission equals ingestion.

Decide how to withdraw products, expire promotions, and handle unavailable images. A failed partial update should not silently publish zero prices or mark every item as available. Reconcile record counts and failures after each run. Store an export version or timestamp so an incident can be traced to the data that was sent.

## Feed discovery is not transaction permission

A catalog entry can explain an offer. It cannot authorize an agent to spend a customer's money. Merchant approval, checkout support, geographic availability, payment authorization, and final confirmation must be established separately. Start with the platform's [merchant participation information](https://chatgpt.com/merchants/) and your actual account configuration.

If checkout remains on your website, ensure the destination retains the selected product and makes price, shipping, and confirmation clear. A well-functioning web handoff can be a useful result without claiming a native purchase inside every assistant.

## A practical release gate

Release when identifiers are stable, required fields are valid, sample variants reconcile, stale-data behavior is defined, rejected records are visible to an owner, and the actual next step works. Keep the report small enough to inspect after a routine catalog update. The [feed validation recipe](https://byagents.dev/agents/feed-validation-recipe) provides a machine-readable review structure; the [commerce readiness guide](https://byagents.dev/humans/agent-commerce-readiness) covers what happens after selection.

## Sources

- [OpenAI: Product file-upload specification](https://developers.openai.com/commerce/specs/file-upload/products)
- [ChatGPT: Merchant participation](https://chatgpt.com/merchants/)

## Related reading

- [Agent discovery for brands and ecommerce](https://byagents.dev/humans/brands-and-commerce)
- [Recipe: validate a product feed across the full handoff](https://byagents.dev/agents/feed-validation-recipe)
- [From an AI recommendation to a confirmed purchase or booking](https://byagents.dev/humans/agent-commerce-readiness)


---

# How to test whether agent distribution is working

> A practical evaluation design that separates discovery, understanding, completion, and real customer acquisition.

Canonical: https://byagents.dev/humans/evaluating-agent-distribution
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Playbook
Level: Mixed
Outcome: Run a reproducible small evaluation and report the result without inflating what it proves.

An evaluation is a controlled way to observe behavior. It becomes useful when the task, environment, introduction method, and expected result are recorded. Asking an assistant whether your site is good is feedback, not a distribution experiment.

## Separate two experiments

**Unbranded discovery:** give a realistic task and constraints without naming your business. Observe whether the environment searches, what it retrieves, which options it considers, and why it continues or stops. This tests an available route in that environment.

**Introduced-provider adoption:** supply the product or its URL, then test whether the agent can understand and use it. This diagnoses product information and handoff quality. It cannot establish that the business was independently found.

Both are useful. Mixing their results makes discovery look better simply because some runs were handed the answer.

## Build a task set before tuning the site

Include common customer tasks, difficult but relevant constraints, and tasks where your offering should be rejected. Reserve some tasks as a holdout that you do not use to write the new content. Specify the observable result for each task before seeing an answer.

For a fictional extraction API, completion could require correct invoice line items against a known fixture. For a service, it might require a correctly scoped inquiry with the requested service area. For a booking, completion means confirmed reservation state, not a draft message saying a reservation is possible. Use synthetic inputs and test environments where available.

## Record the environment

Capture date, application, model or mode when exposed, tool access, login state, location assumptions, language, time budget, and supplied context. Some consumer applications do not expose every setting. Record unknown values rather than inventing precision.

Keep fresh sessions where feasible and note persistent personalization. An agent with your docs preloaded has a different starting point from an ordinary unbranded user. Repeat selected tasks to reveal variability, but do not silently discard unsuccessful runs.

## Score stages with observable evidence

| Stage | Evidence | A common false positive |
| --- | --- | --- |
| Encountered | Actual source or tool retrieved | The model already knew the name |
| Understood | Correct facts with supporting sources | A persuasive but incorrect summary |
| Selected | An observed recommendation or chosen tool | Your URL was included in the prompt |
| Completed | Verified artifact or external test state | A 202 response or a promise to finish |
| Acquired | A qualified external customer event | Your own evaluation traffic |

A stage may be unknown when the environment does not expose its trace. Do not convert missing evidence into a failure or success automatically. Preserve the reason for the unknown state.

## Report denominators and failures

An **illustrative, invented** result might say: “Of 12 unbranded runs, 4 retrieved the guide; 3 described the offer correctly; 2 reached a valid next step.” These are not ByAgents results. Report both the full denominator and any conditional metric: 2 of 12 overall differs from 2 of 4 among retrieved cases.

Small task sets are primarily debugging tools. A few additional successes can change the percentage substantially. Include raw counts, environment, dates, and failure categories. Do not present repeated runs of one task as independent evidence about an entire market.

## Interpret before-and-after changes cautiously

Preserve the tasks, budget, and configuration; record everything you changed. Use an unchanged comparison group when possible. Search results, model versions, product availability, and platform behavior can change during the experiment. If you cannot isolate your intervention, describe an observed difference rather than a causal lift.

Tag testing so it does not inflate organic traffic, trial activation, or order reports. Keep evidence that the requested final state exists. Anthropic's [tool evaluation guidance](https://www.anthropic.com/engineering/writing-tools-for-agents) provides additional context on task-based evaluation.

## Turn the result into a repair

Cluster failures by the earliest broken step. Fix missing facts, ambiguous operations, invalid inputs, or inaccessible pages before trying to improve a composite score. Rerun the affected cases, then the held-out tasks. Publish the method and material limitations if sharing the result externally. Use our [evaluation record](https://byagents.dev/agents/evaluation-record-template) to preserve enough context for another person or agent to inspect the conclusion.

## Sources

- [Anthropic: Writing tools and evaluating them](https://www.anthropic.com/engineering/writing-tools-for-agents)

## Related reading

- [Measure agent discovery without fooling yourself](https://byagents.dev/humans/measuring-agent-traffic)
- [Template: a reproducible agent evaluation record](https://byagents.dev/agents/evaluation-record-template)
- [Pattern: measure agent activity without inventing attribution](https://byagents.dev/agents/attribution-event-contract)


---

# An agent distribution playbook for software companies

> Connect useful documentation, example projects, tool integrations, and a measurable first successful result.

Canonical: https://byagents.dev/humans/software-agent-distribution
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Playbook
Level: Mixed
Outcome: Ship one complete developer workflow and test a realistic route by which an agent could encounter it.

The strongest starting point for a software company is one useful task that a customer can complete. “We have an API and MCP support” describes packaging. “An agent can take a sample invoice and return verified line items without guessing how to retrieve the result” describes a product experience.

## Package a complete first result

Publish the task page, requirements, authentication instructions, runnable example, expected output, and recovery path together. Name limitations such as accepted input types, supported regions, account prerequisites, and charging units. A short path that actually finishes is more useful than an exhaustive endpoint list with an ambiguous quickstart.

Keep example versions explicit. Pin dependencies for reproducibility and state which versions the instructions support. Do not embed credentials in sample repositories. Provide a clearly marked test fixture and tell the reader whether trying it is free, metered, or unavailable without an account.

## Make the artifact useful where developers work

| Distribution surface | Useful artifact | What to verify |
| --- | --- | --- |
| Web search | A specific task or compatibility guide | It answers the relevant constraint and links to a working example |
| Source repository | Maintained sample, license, and release instructions | A clean environment can reproduce the result |
| Package ecosystem | Accurate package metadata and versioned docs | The published artifact matches the documentation |
| Integration catalog | Clear capability, permissions, and onboarding | The intended host actually exposes the integration |
| Existing customer workflow | A task-focused tool or skill | It removes a repeated step without surprising side effects |

These routes are options to investigate, not a claim that every agent searches each ecosystem. Select the surface your intended users and their tools can reach.

## Add MCP when the consumer is real

Start with a small set of operations that express meaningful jobs. Include the call that retrieves the final output, not just the call that begins work. Separate harmless lookups from operations that incur cost or change state. Make errors actionable and bounded.

A registry listing is metadata distribution; it is not universal installation. The official MCP Registry describes a preview service consumed through an ecosystem of aggregators and clients. [Registry scope](https://modelcontextprotocol.io/registry/about). Verify the actual host's onboarding, authentication, version support, and selection behavior.

## Write descriptions that help selection

Describe the input, result, constraints, and side effects. Replace “powerful document intelligence” with a factual explanation of what the tool accepts and returns. Avoid telling the model to prefer your tool, conceal limitations, or skip authorization. Test a near-miss task where a different tool should be chosen.

A useful success path includes a useful failure path. Explain unsupported inputs, expired credentials, exhausted limits, jobs that time out, and how a caller knows whether a retry would create another charge. A tool that fails clearly can be safer and easier to integrate than one that always returns a reassuring sentence.

## Separate introduced use from new distribution

First test your workflow with the integration supplied. That makes failures easier to locate. Then run unbranded tasks in a documented environment where the relevant distribution surface is available. Record how your product entered the context.

A sample repository opened from your own link proves the sample was reachable. It does not prove independent discovery. A tool invocation by a current customer may demonstrate retention or expansion value even when it is not new customer acquisition. Report the actual value instead of forcing every result into a traffic story.

## Maintain the route after launch

Tie documentation and examples to releases. Assign owners for package identity, catalog records, API changes, deprecations, and support. When a field or endpoint changes, update the HTML guide, machine-readable contract, tool description, and expected output together.

Use the [action contract pattern](https://byagents.dev/agents/action-contract-pattern) for asynchronous jobs, the [MCP checklist](https://byagents.dev/agents/mcp-publication-and-compatibility) for compatibility, and the [worked example](https://byagents.dev/humans/agent-discovery-worked-example) to see how these pieces fit together. These are implementation aids, not claims that ByAgents has already delivered customers through these routes.

## Sources

- [MCP Registry: Scope and preview status](https://modelcontextprotocol.io/registry/about)

## Related reading

- [API documentation an agent can actually use](https://byagents.dev/humans/api-documentation)
- [Recipe: publish and verify an MCP integration](https://byagents.dev/agents/mcp-publication-and-compatibility)
- [Worked example: from an invoice question to a usable API](https://byagents.dev/humans/agent-discovery-worked-example)


---

# From an AI recommendation to a confirmed purchase or booking

> Design the handoff around current offers, permission, safe retries, and a confirmation the customer can trust.

Canonical: https://byagents.dev/humans/agent-commerce-readiness
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Guide
Level: Mixed
Outcome: Map the steps between selection and a real commercial outcome, including the cases that must stop.

An agent recommending your business is not the same as an agent successfully transacting with it. The handoff has to preserve the customer's requirements, use current information, respect authorization, and produce a verifiable result. The same structure applies to purchases, reservations, and paid API jobs, although the details differ.

## Make the transaction state explicit

| State | What is known | What is still needed |
| --- | --- | --- |
| Discovered | The offering may fit | Verify current facts and constraints |
| Quoted | Terms and availability were checked | Required customer approval and valid quote |
| Submitted | A request reached the business | Confirmation of acceptance or failure |
| Confirmed | The business recorded the commitment | Receipt, access, fulfillment, or follow-up |
| Completed | The customer received the intended result | Support and any permitted aftercare |

Use the terms your actual system implements. A form that requests a table is an inquiry unless it reserves one. An accepted asynchronous API job is not a completed result. A checkout page displaying a total is not proof of an order.

## Separate preview from commitment

Allow a caller to obtain the information needed to make a decision without silently committing. Show the actual item or service, amount and currency, material fees, time or location, relevant terms, and expiration of any quote. Changes that matter to the customer require a renewed decision under the application's authorization policy.

A publicly discoverable endpoint does not grant permission to purchase. An agent's ability to authenticate also does not mean the customer authorized every operation available to that account. Enforce the boundary in the application, not only in a natural-language instruction.

## Design for uncertainty and retries

A network timeout can happen after a request has been accepted. If the caller simply repeats the action, the business might create a duplicate order, reservation, or charge. Define an idempotency mechanism and a way to retrieve the status of the original request.

Document how long the key is retained, what happens if the same key is reused with different inputs, and which identity owns the result. Do not make callers infer whether an error occurred before or after the commitment. Reconcile ambiguous outcomes against the business's authoritative record.

## Account for changing offers

Inventory, appointment slots, promotions, and shipping costs can change between recommendation and checkout. Check them at the point of commitment. Return a specific unavailable or expired state and a permitted next step. An alternative product or time is a new proposal, not an automatic substitute unless the user authorized that flexibility.

For service businesses, make the difference between an estimate and a binding quote clear. For restaurants, distinguish menu information from live table inventory. For APIs, distinguish estimated usage from a charge actually incurred. These boundaries are part of the product experience.

## Choose a protocol only after defining the journey

ACP focuses on compatible agent checkout. UCP describes interoperable commerce capabilities and profiles. AP2 addresses payment authorization. They may participate in a larger workflow, but their existence does not establish that your merchant account or target application supports the combination. See the [protocol map](https://byagents.dev/humans/agent-protocols-explained) and verify current participant documentation before implementation.

A conventional checkout or booking page may be the right starting point. Keep it accessible, preserve the selected item, and return a confirmation that can be inspected. Build a native agent integration when a supported consumer and a real customer need justify it.

## Test the failures as well as the success

Test expired quotes, unavailable inventory, missing authorization, a changed total, duplicate submissions, and a timeout after acceptance in an authorized test environment. Verify the final business record and confirm that no unintended duplicate was created. Keep test activity out of sales reports.

The release gate is a trustworthy outcome with clear recovery, not merely a schema-valid request. Our [authorization reference](https://byagents.dev/agents/authorization-and-trust) and [action contract pattern](https://byagents.dev/agents/action-contract-pattern) provide technical review checklists for these boundaries.

## Sources

- [Agentic Commerce Protocol](https://www.agenticcommerce.dev/)
- [Universal Commerce Protocol: Core concepts](https://ucp.dev/documentation/core-concepts/)
- [Google: Developer guide to agent protocols](https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/)

## Related reading

- [From discovery to a purchase, booking, or API call](https://byagents.dev/humans/from-discovery-to-action)
- [Reference: identity, authorization, and untrusted content](https://byagents.dev/agents/authorization-and-trust)
- [Pattern: asynchronous actions an agent can finish](https://byagents.dev/agents/action-contract-pattern)


---

# Worked example: from an invoice question to a usable API

> A fictional walkthrough that connects search, product facts, evidence, and the exact handoff that must work.

Canonical: https://byagents.dev/humans/agent-discovery-worked-example
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Worked example
Level: Mixed
Outcome: See how one customer task becomes a concrete discovery and integration backlog.

This is a fictional design exercise. Example Invoice API is not a ByAgents customer, and the sequence below is not a measured agent run. The point is to make a proposed distribution system inspectable before claiming it works.

## The customer task

“Find an API that extracts line items from scanned PDF invoices, returns JSON, and lets our application retrieve the output after processing. Explain the price unit and how to try it.” The provider is not named. The constraints include scanned PDFs, line items, asynchronous completion, pricing clarity, and a usable trial.

An evaluator should include an unsuitable task too: for example, a request for handwritten receipts if the fictional product does not support them. Correct rejection is evidence of accurate understanding, not a marketing failure.

## Before: the source material is incomplete

Assume the homepage says “document intelligence for modern teams,” the pricing page lists credits without explaining the unit, and the API reference shows only POST /jobs. A tool listing promises extraction but does not say how the final output is obtained.

These are different defects. Broad positioning makes selection difficult. Ambiguous credits prevent cost comparison. Missing result retrieval breaks the task after selection. Publishing more listings would not repair the latter two.

## After: one consistent product description

The fictional product page now states: “Extract line items from scanned PDF invoices into JSON. Processing creates a job; retrieve the job until it completes, then read its result. Billing is per processed page. Handwritten receipts are unsupported.” An actual business should replace these statements with verified product behavior and real pricing.

The page links to a sample fixture, a documented output, the price source, and the quickstart. The structured record and tool description repeat the same boundaries. No rating, compliance claim, or accuracy percentage is added without evidence.

## The intended route

```text
Customer task
  -> search or a relevant developer catalog
  -> task-specific explanation
  -> documented constraints and price unit
  -> trial / authorization
  -> create extraction job
  -> retrieve status and final output
  -> validate line items against the fixture
```

This is an intended route. The test must record which source was actually encountered. If the agent was handed the quickstart, the run starts at the quickstart; it does not prove the preceding search step happened.

## The concrete repair backlog

| Defect | Repair | Acceptance check |
| --- | --- | --- |
| “Credits” have no defined unit | Publish the real billing unit and current price source | A reader can estimate the cost of a defined input |
| Scanned-input support is ambiguous | State supported inputs and limits | A supported and an unsupported case are classified correctly |
| POST returns a job with no continuation | Document status retrieval, terminal states, and output | An authorized test retrieves a correct final artifact |
| Tool metadata overpromises | Align description with the actual contract | The tool is rejected for an unsupported task |
| No known introduction route | Publish a useful artifact in a relevant surface | An unbranded run actually retrieves it |

Assign each repair to an owner. Do not combine all five into an opaque score. The integration owner can fix a missing retrieval operation; the content owner can reconcile a price explanation; neither should claim improved discovery before testing it.

## What would count as evidence

Static review can show that documentation now contains the required information. An authorized execution can show that a specific input produces the expected output. A controlled unbranded run can show that a particular environment encountered the product. A real external activation can show customer usage, with acquisition attribution only when supported.

No one of those observations establishes all the others. Keep timestamps, versions, inputs, expected result, actual result, and limitations with each claim. The [evaluation template](https://byagents.dev/agents/evaluation-record-template) and [evidence record](https://byagents.dev/agents/evidence-record) are reusable formats for this purpose.

## Apply the pattern to another business

For a restaurant, replace file types with location, group size, and dietary constraints; replace job completion with reservation confirmation. For a freelancer, replace the sample fixture with a scoped brief and the API result with an accepted inquiry or agreed deliverable. The shared design question is whether the route preserves the customer's intent all the way to a real next step.

## Related reading

- [Where to start with agent distribution](https://byagents.dev/humans/agent-distribution-priorities)
- [Pattern: asynchronous actions an agent can finish](https://byagents.dev/agents/action-contract-pattern)
- [Template: a reproducible agent evaluation record](https://byagents.dev/agents/evaluation-record-template)


---

# Keep your agent distribution working after launch

> A practical operating model for ownership, freshness, regression checks, and deciding which channels deserve investment.

Canonical: https://byagents.dev/humans/maintaining-agent-distribution
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Playbook
Level: Mixed
Outcome: Set review triggers and a small operating dashboard that connects maintenance to business value.

Agent readiness can decay without a redesign. A price changes, a documentation link breaks, a model stops using a tool, or a platform changes its admission process. Treat the published facts and action path as maintained product surfaces, not a one-time optimization project.

## Give each surface an owner

| Surface | Accountable owner | Trigger for review |
| --- | --- | --- |
| Product facts and policies | Commercial or product owner | Price, scope, region, or terms change |
| Public pages and structured records | Web or content owner | Content release or source-data change |
| Feeds and catalog records | Commerce or integration owner | Inventory updates, rejections, deprecations |
| API and tool interfaces | Engineering owner | Release, schema change, authentication change |
| Discovery experiments | Growth or research owner | Platform change or a new customer task |
| Outcome reporting | Operations owner | Event-definition or attribution-policy change |

A solo founder may hold every role. The value of the table is assigning a decision and a review trigger, not creating departments.

## Make freshness depend on the fact

A founding date rarely needs refreshing. A product description changes with releases. Stock and appointment availability may need much faster updates. Set tolerances based on the cost of a wrong answer and the capabilities of the actual receiving platform.

Separate last modified, last reviewed, and last successfully fetched. None is a substitute for the others. A page fetched today can contain a stale price. A newly edited article can cite an obsolete specification. A review date should record a real review, not update automatically every midnight.

## Check a small set of invariants

Confirm that important public routes still return useful content, recurring facts agree, the intended variant or service survives the handoff, and supported workflows produce a valid final state. Check a failure case too. A change that improves the happy path but creates duplicate paid actions is not a successful release.

Use automated checks where they are meaningful: broken internal links, invalid JSON, missing required feed fields, or a known test fixture returning the wrong artifact. Keep judgment-based checks separate: whether a source is credible, a comparison fair, or a task representative cannot be established by syntax validation alone.

## Keep a change log that supports diagnosis

Record the changed surface, reason, owner, release date, affected consumer, and verification result. If a protocol changes, pin the revision actually tested. If a platform announcement and a current specification disagree, record the conflict and the basis for the implementation choice.

When a result regresses, inspect the earliest failing stage. Was the page no longer retrieved, was the product misunderstood, or did the action fail? A single “visibility score” cannot tell an engineer which of those to repair.

## Review investment using actual outcomes

A useful monthly discussion has five inputs: work completed, maintenance cost, observed exposure, verified task completion, and qualified customer activity. Show unknown attribution explicitly. Include support burden and failed or refunded transactions when evaluating the economics of an integration.

Decide whether to maintain, expand, revise, or retire each experimental route. A channel with little new acquisition may still help existing customers use the product; record that as adoption or retention value. A channel with many bot requests and no evidence of useful activity may not deserve more content production.

## How this library handles freshness

ByAgents publishes a review date on each document, links primary sources, and separates examples from measured results. Our [current briefing](https://byagents.dev/humans/agent-distribution-now) is a dated editorial snapshot. We do not claim continuous monitoring or comprehensive testing of every assistant.

Our own HTML, Markdown, and search use the same content records, and release checks inspect those representations together. That is a concrete publishing practice, not evidence that an assistant will rank us first. Use the [source policy](https://byagents.dev/agents/evidence-policy) and [source review recipe](https://byagents.dev/agents/source-review-recipe) when adapting the approach to your own library.

## Related reading

- [Agent distribution: what matters now](https://byagents.dev/humans/agent-distribution-now)
- [Recipe: review a technical claim and resolve conflicting sources](https://byagents.dev/agents/source-review-recipe)
- [Pattern: measure agent activity without inventing attribution](https://byagents.dev/agents/attribution-event-contract)


---

# Recipe: audit public crawl and retrieval access

> A bounded inspection procedure with exact observations, crawler-identity limits, and repair verification.

Canonical: https://byagents.dev/agents/crawl-audit-recipe
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Recipe
Level: Technical
Outcome: Produce an access finding that distinguishes a policy, a response, and actual provider behavior.

Input: one authorized public origin and a small list of product, pricing, documentation, and policy URLs. Output: a dated access report for those URLs. This procedure does not authorize private access, scanning unrelated systems, bypassing challenges, or changing a site's crawl policy.

## Define the scope

Record the origin, task, URLs, request budget, intended consumer, and collection time. Use public pages without credentials. Identify which requests are ordinary retrieval checks and which are owner-approved user-agent rule simulations. Do not label simulations as requests from the real provider.

## Collect the response and the content

The following commands are templates for a site you are allowed to inspect. The example domain is a placeholder. They make bounded GET requests and do not follow redirects automatically.

```sh
curl --proto '=https' --max-time 15 --max-filesize 2097152 \
  --dump-header robots.headers --output robots.txt \
  'https://example.com/robots.txt'

curl --proto '=https' --max-time 15 --max-filesize 2097152 \
  --dump-header product.headers --output product.html \
  'https://example.com/product'
```

Inspect redirects before fetching their targets. Reapply the scope check at every hop. If implementing this as a service, validate resolved addresses and redirect destinations, exclude private and metadata networks, constrain decompressed size, and use an egress boundary. A URL string beginning with HTTPS is not sufficient SSRF protection.

## Separate the access layers

| Layer | Inspect | Interpretation |
| --- | --- | --- |
| Transport | Status, TLS failure, redirect, timeout | What this request could reach |
| Crawl policy | Applicable robots group and path rules | Published rules for that crawler, not authentication |
| Indexing | Meta robots and X-Robots-Tag | Indexing directives, subject to the consumer's behavior |
| Delivery | Challenge, login, consent wall, empty shell | Whether this response contains useful content |
| Meaning | Product, constraints, price unit, next action | Whether the task can be answered from the source |

Do not infer a universal indexing state from a robots file. A robots disallow can prevent a crawler from seeing a page's noindex directive. Confirm intended behavior using the relevant provider's documentation and webmaster tools where available.

## Verify identity separately

Use the provider's published verification mechanism for observed traffic. A user-agent string is a claim, not authentication. OpenAI, Anthropic, and Perplexity publish different crawler roles and controls; the [platform guide](https://byagents.dev/humans/ai-discovery-platforms) links the authoritative references. Do not hardcode an IP list copied from an old article.

Scope any proposed firewall change to the permitted public route and verified source. Preserve protections around accounts, payments, uploads, and private APIs. Record which control caused the failure before suggesting a repair.

## Report what happened

```json
{
  "example": true,
  "url": "https://example.com/product",
  "method": "GET",
  "collection_mode": "ordinary_public_fetch",
  "observed_at": null,
  "http_status": null,
  "useful_content_present": null,
  "provider_identity_verified": false,
  "indexing_status": "unknown",
  "proposed_check": "Confirm the product facts exist in the response body."
}
```

Null means uncollected, not a failing response or a zero value. After a repair, repeat the same scoped request and retain both observations. A working fetch proves access from that test environment. Provider crawling, indexing, citation, and customer conversion require additional evidence. Link the finding to an exact response or excerpt rather than an unsupported readiness percentage.

## Related reading

- [Can an agent actually read your website?](https://byagents.dev/humans/crawl-access)
- [How the major AI discovery channels differ](https://byagents.dev/humans/ai-discovery-platforms)
- [Evidence record: a portable example](https://byagents.dev/agents/evidence-record)


---

# Pattern: publish documents for reliable retrieval

> Stable identifiers, focused content, explicit metadata, and consistent HTML, Markdown, and JSON.

Canonical: https://byagents.dev/agents/retrieval-document-contract
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Pattern
Level: Technical
Outcome: Define a document interface that a reader can fetch, cite, update, and verify without a browser session.

This is a ByAgents publishing pattern, not a universal agent standard. The target is a task-focused document available through ordinary HTTP with a stable identity, useful text, and enough provenance to interpret a claim. It does not require an MCP server or a model call.

## Keep identity separate from representation

Give the document a stable identifier and canonical HTML URL. Offer a focused Markdown representation when useful. Both should contain the same material claims and source references. A bulk export is useful for indexing but should not be the only way to retrieve one topic.

Use durable section anchors. If a URL changes, provide an appropriate redirect instead of silently deleting a commonly cited source. Avoid session-dependent links as the only access path to public facts. State when a document describes an older product or protocol release.

## Publish enough metadata to select a document

```json
{
  "example": true,
  "id": "docs/result-retrieval",
  "title": "Retrieve a completed extraction job",
  "description": "Job states, polling limits, output fields, and errors.",
  "level": "Technical",
  "canonical_url": "https://example.com/docs/result-retrieval",
  "markdown_url": "https://example.com/docs/result-retrieval.md",
  "product_version": "example-v1",
  "reviewed_at": null,
  "sources": []
}
```

This example is not the exact ByAgents API schema. Use our [OpenAPI contract](https://byagents.dev/agents/openapi.json) for actual response fields. Do not fill an unknown review date with the current date merely to imply freshness.

## Write sections that survive partial retrieval

Put the answer and its qualification in the same section. Define units, entity names, accepted values, and side effects near their first use. A paragraph about a paid operation should not depend on an unrelated page to reveal that the action incurs a charge.

Make code examples syntactically valid, mark fictional hosts, and name the versions they target. Separate a request from an example response. Explain how success is observed, what happens when the operation is incomplete, and which failure conditions require stopping.

## Keep retrieval bounded

Provide a metadata index and focused search with documented limits. Return excerpts plus exact full-document URLs. An empty result should be distinguishable from a service error. Do not send a giant catalog when the caller needs one operation's input contract.

State whether search is lexical, semantic, or a mixture. Relevance scores should describe matching behavior; they are not evidence of truth, trust, or commercial superiority. The current ByAgents knowledge search is lexical and only covers this library.

## Preserve HTTP meaning

Return missing documents as 404 and unsupported methods as 405 where appropriate. Use content types matching the actual body. Publish cache behavior appropriate to the content, and do not cache private data as public. A successful HTML response containing only a login form is not a successful retrieval of the intended document.

Content negotiation is optional; explicit representation URLs can be simpler. The invariant is that the same document remains recognizable and consistent across formats. A Markdown URL should not expose additional hidden sales claims or instructions absent from the visible source.

## Acceptance checks

Check that every index URL resolves, the full document is readable without executing page scripts, HTML and Markdown agree, JSON examples parse, internal anchors exist, and source links support the associated claims. Test an unknown document and an empty search. Review content meaning separately from transport behavior.

An agent may still choose another source. This contract reduces retrieval friction; it cannot create authority by declaration. Our [publishing contract](https://byagents.dev/agents/publishing-contract) documents the subset implemented on this website, and the [source review recipe](https://byagents.dev/agents/source-review-recipe) covers evidence quality.

## Related reading

- [Publishing contract and representation map](https://byagents.dev/agents/publishing-contract)
- [Knowledge API: requests and responses](https://byagents.dev/agents/knowledge-api)
- [Recipe: review a technical claim and resolve conflicting sources](https://byagents.dev/agents/source-review-recipe)


---

# Recipe: publish and verify an MCP integration

> Separate registry publication, host availability, version compatibility, tool selection, and successful execution.

Canonical: https://byagents.dev/agents/mcp-publication-and-compatibility
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Recipe
Level: Technical
Outcome: Produce a compatibility record for a named host and one complete customer workflow.

Input: a server implementation, a declared protocol revision, and a named intended host. Output: publication and compatibility evidence for that combination. This is an implementation checklist, not a universal MCP certification or a claim that ByAgents hosts an MCP service.

## Distinguish five milestones

| Milestone | Evidence to retain |
| --- | --- |
| Published | A retrievable metadata record and the actual package or remote endpoint |
| Available in a host | The intended catalog or configuration can expose the server |
| Connected | Authentication and protocol exchange succeed for the intended user |
| Selected | A realistic task chooses the appropriate exposed tool |
| Completed | The final output or authorized external state is correct |

Passing one row does not imply the next. A listing can exist even when a host does not consume its registry. A connection can succeed while every useful tool call fails.

## Pin the compatibility boundary

The MCP versioning documentation currently identifies revision 2026-07-28. It uses per-call protocol versions, including `_meta["io.modelcontextprotocol/protocolVersion"]`; Streamable HTTP also carries the MCP-Protocol-Version header. Older revisions use a different lifecycle. [Versioning reference](https://modelcontextprotocol.io/docs/2026-07-28/learn/versioning).

Record the server release, SDK release, host release, transport, protocol revision, and authentication method. Use the supported SDK and specification for that combination. Do not combine code from different revisions without an explicit compatibility layer and tests.

## Understand server discovery precisely

In the 2026-07-28 specification, `server/discover` provides server identity, capabilities, and supported versions. Servers implement it; clients need not call it before every other operation. This is discovery of a **known server's** properties, not a web search for businesses. [Discovery specification](https://modelcontextprotocol.io/specification/2026-07-28/server/discover).

The distribution question remains: how did the host obtain this server's address or package in the first place? Record that route independently, such as a user installation, organization configuration, catalog entry, or another supported mechanism.

## Publish metadata that agrees with the runtime

The official MCP Registry describes itself as a preview metadata service. Namespace ownership is distinct from a security endorsement, and registry metadata is distinct from executable code. Follow its current publisher requirements and the intended downstream consumer's admission process. [Registry overview](https://modelcontextprotocol.io/registry/about).

Verify the identity, package or endpoint, version, documentation links, and installation instructions against the release being distributed. Do not put a private credential in public metadata. Test a clean installation path rather than relying on the maintainer's already-configured environment.

## Test selection and completion separately

Provide a small set of task-focused tools with precise descriptions. Include inputs, output meaning, limits, side effects, and a bounded recovery path. Test both a task the tool should handle and one it should reject. Confirm that asynchronous work includes a documented route to the final result.

Require authorization for consequential operations. Record the actual completion artifact rather than the model's claim that the tool worked. If a host hides internal selection traces, mark the selection rationale unknown rather than fabricating it.

## A task-focused tool definition

This fictional tool definition illustrates a read operation using the MCP tool shape. It is not a complete server, a JSON-RPC request, or a claim of a working integration. The implementation must enforce the stated account boundary and return the documented states.

```json
{
  "name": "get_extraction_result",
  "description": "Read an existing invoice extraction job owned by the authenticated account. Returns its processing state and, when succeeded, the extracted line items. Does not create a job or charge for another extraction.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "job_id": {
        "type": "string",
        "minLength": 1,
        "description": "The identifier returned when this account created the extraction job."
      }
    },
    "required": ["job_id"],
    "additionalProperties": false
  }
}
```

The [versioned tools specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) defines the actual envelope, schemas, and request requirements. Keep the creation operation separate and document its charging boundary. For a complete implementation, also define the result schema, authorization failures, unknown identifiers, and retention expiry. The example's description should be tested against behavior, not trusted as an enforcement mechanism.

## Release record

```json
{
  "example": true,
  "server_release": "example-1.0.0",
  "host": "not_tested",
  "host_release": null,
  "protocol_revision": "2026-07-28",
  "transport": "streamable_http",
  "publication": "not_verified",
  "authentication": "not_verified",
  "task_completion": "not_executed",
  "independent_discovery": "unknown"
}
```

Replace unknown values only with observations. Recheck the affected consumer after authentication, protocol, package, or tool-schema changes. A versioned record makes a narrow compatibility claim useful without pretending it covers every agent application.

## Sources

- [MCP: Protocol versioning, 2026-07-28](https://modelcontextprotocol.io/docs/2026-07-28/learn/versioning)
- [MCP: server/discover, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/server/discover)
- [MCP Registry: Scope and preview status](https://modelcontextprotocol.io/registry/about)
- [MCP: Tool definitions, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)

## Related reading

- [MCP, registries, and getting your tools discovered](https://byagents.dev/humans/mcp-and-tool-discovery)
- [An agent distribution playbook for software companies](https://byagents.dev/humans/software-agent-distribution)
- [Reference: identity, authorization, and untrusted content](https://byagents.dev/agents/authorization-and-trust)


---

# Pattern: asynchronous actions an agent can finish

> A concrete request-to-result contract with explicit states, retry behavior, authorization, and verifiable completion.

Canonical: https://byagents.dev/agents/action-contract-pattern
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Pattern
Level: Technical
Outcome: Review an asynchronous API for missing steps and define a complete first-result path.

This is a fictional API design pattern, not an endpoint available from ByAgents and not a normative MCP or commerce schema. Adapt it to the actual service, security model, and charging policy. The central requirement is a documented path from request to terminal outcome.

## Define the lifecycle before the endpoints

```text
request validated -> queued -> running -> succeeded
                                  -> failed
                                  -> cancelled
```

State which transitions are possible and who can trigger them. If cancellation is unsupported, omit it. Define whether cancellation prevents a charge or only stops future work. A job reaching a terminal state should remain retrievable for a documented retention period.

## Specify the operations

| Operation | Required contract details |
| --- | --- |
| POST /v1/extractions | Auth scope, validated input reference, idempotency key, charging boundary |
| GET /v1/extractions/{id} | Same account authorization, state enum, polling behavior, terminal result |
| Result retrieval | Inline output or a documented authorized URL, type, expiry, and size limits |

Prefer an authorized upload or input identifier over unrestricted remote-URL ingestion. If accepting remote URLs, implement fetch restrictions and validation; a public action endpoint should not become a proxy to private networks.

## Example accepted response

```http
HTTP/1.1 202 Accepted
Content-Type: application/json
Location: /v1/extractions/ex_example_42
Cache-Control: no-store
```

```json
{
  "id": "ex_example_42",
  "state": "queued",
  "status_url": "/v1/extractions/ex_example_42",
  "poll_after_seconds": 3,
  "result": null,
  "error": null
}
```

The polling field is an application-defined example. Define a maximum polling budget and what the caller should do if it expires. A 202 response acknowledges acceptance; it does not prove the extraction is complete. Document how relative URLs resolve against the service origin and preserve authorization on subsequent requests.

## Example successful terminal response

```json
{
  "id": "ex_example_42",
  "state": "succeeded",
  "result": {
    "currency": "USD",
    "line_items": [
      { "description": "Example part", "quantity": 2, "unit_amount_minor": 1250 }
    ]
  },
  "error": null
}
```

This example defines unit_amount_minor as an integer in the currency's minor unit. Do not assume another API uses that convention. The actual schema should constrain types, state-specific fields, numeric ranges, and size limits. Verify the result against a fixture rather than accepting any non-empty JSON as success.

## Define retry semantics precisely

An idempotency key should identify one intended operation within a defined account scope and retention window. Specify how repeated equivalent requests retrieve the same operation and how conflicting reuse is rejected. The server must enforce this behavior atomically; a documentation sentence alone does not prevent duplicates.

A timeout may occur after acceptance. Let the caller reconcile the original request before creating another one. Distinguish retryable conditions from validation, permission, and exhausted-budget failures. Bound retries and respect the service's documented backoff. Do not retry a paid action merely because the agent did not see the first response.

## Return actionable errors without leaking internals

RFC 9457 defines a standard problem-details representation for HTTP APIs. It can carry a stable problem type and readable explanation without inventing a generic 200 response for failures. [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457.html).

```json
{
  "type": "https://example.com/problems/unsupported-input",
  "title": "Unsupported input type",
  "status": 422,
  "detail": "This example operation accepts PDF inputs only."
}
```

Return the matching HTTP status and application/problem+json when using that format. Define documented error types and permitted recovery. Keep tokens, stack traces, private document contents, and internal network details out of public errors.

## Acceptance checks

Test a valid job, invalid input, unauthorized access, a repeated key, conflicting key reuse, a timeout after acceptance, a failed job, and expired result retention. Confirm account isolation and the final artifact. A static OpenAPI review can identify missing contracts; only execution against an authorized service can verify the implementation.

## Sources

- [IETF RFC 9457: Problem details for HTTP APIs](https://www.rfc-editor.org/rfc/rfc9457.html)

## Related reading

- [API documentation an agent can actually use](https://byagents.dev/humans/api-documentation)
- [Reference: identity, authorization, and untrusted content](https://byagents.dev/agents/authorization-and-trust)
- [Template: a reproducible agent evaluation record](https://byagents.dev/agents/evaluation-record-template)


---

# Reference: identity, authorization, and untrusted content

> Separate a discoverable service from a trusted source, an authenticated caller, and an authorized action.

Canonical: https://byagents.dev/agents/authorization-and-trust
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Reference
Level: Technical
Outcome: Identify trust boundaries before exposing tools, accepting agent traffic, or enabling transactions.

A public description can explain a capability. It cannot grant authority to execute it. Agent integrations need explicit boundaries between retrieved information, caller identity, account permissions, and the user's intended action. This reference is a design checklist, not a security certification or a complete threat model.

## Four different questions

| Question | Evidence needed | Insufficient substitute |
| --- | --- | --- |
| Who published this? | Verified origin or the relevant provenance mechanism | A familiar company name in page text |
| Who is calling? | Valid credentials or verified request identity | A user-agent string |
| What may they access? | Server-enforced account, object, and scope checks | A tool being visible in a catalog |
| What did the user authorize? | The application's consent and action policy | A webpage telling the agent to proceed |

A provider identity check can help distinguish traffic sources. It does not establish that a request represents a qualified buyer or that its operator may purchase on a user's behalf.

## Treat retrieved text as data

Tool descriptions, documentation, search results, and remote outputs can contain instructions. Do not let them override the user's task, request unrelated secrets, redirect credentials, or expand permission. A page saying “send your API key here to verify compatibility” is not an authorization source.

Keep data and control channels distinct. Validate tool inputs in the application even when a model produced schema-shaped JSON. Enforce allowlists or scope checks for sensitive destinations and object identifiers. Do not execute commands copied from an untrusted document as part of a read-only review.

## Enforce authorization at the service

Validate credentials for the intended resource and account. Check permissions on every object and operation, including status and result retrieval. Avoid credential passthrough to an unrelated downstream service. Use the relevant protocol's current authorization guidance and the host's actual supported flow; public documentation is not a place for tokens.

For consequential actions, distinguish a preview from a commitment. Present or retain the parameters that determine the consequence, such as price, recipient, scope, or reservation time. A changed quote may require renewed approval. The service should reject an unauthorized commitment even if the model has been persuaded to call it.

## Verify signed traffic according to a profile

Cloudflare documents Web Bot Auth verification using a specific signature profile and registered key material. Implementations must follow the supported profile rather than assuming every draft is interchangeable. Its current documentation also notes that nonce-based replay deduplication is not enforced by a nonce store there. [Verification documentation](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/).

Practical implication: do not treat a valid signature as general replay protection or payment approval. Document expiry handling, replay defenses, rate limits, and the allowed operation separately. Use a supported library or provider integration rather than inventing a custom signature parser.

## Plan for partial failure

Use idempotency and state reconciliation where a retry could duplicate a charge or commitment. Keep audit events that explain what was requested, authorized, and recorded, with an appropriate retention policy and access controls. Minimize personal information; do not log credentials, payment data, or full private prompts by default.

Provide a revocation path, a way to stop or disable a problematic integration, and a support route for disputed results. Failure messages should give the caller a safe next step without revealing private infrastructure.

## Evidence required before claiming support

Test wrong-account access, insufficient scope, expired credentials, manipulated remote content, repeated actions, and ambiguous completion in an authorized environment. Record the actual enforcement result. A well-written manifest or passing schema validator does not prove these controls exist. Use the [action contract](https://byagents.dev/agents/action-contract-pattern) and [evaluation record](https://byagents.dev/agents/evaluation-record-template) to connect the design to observable behavior.

## Sources

- [Cloudflare: Web Bot Auth verification](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/)

## Related reading

- [Pattern: asynchronous actions an agent can finish](https://byagents.dev/agents/action-contract-pattern)
- [From an AI recommendation to a confirmed purchase or booking](https://byagents.dev/humans/agent-commerce-readiness)
- [Evidence, editorial policy, and trust boundaries](https://byagents.dev/agents/evidence-policy)


---

# Template: a reproducible agent evaluation record

> Record the task, introduction method, environment, observations, expected result, and evidence limitations.

Canonical: https://byagents.dev/agents/evaluation-record-template
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Template
Level: Technical
Outcome: Preserve enough context to rerun an evaluation and distinguish it from external customer usage.

This is a ByAgents example format. It is not an external standard, a supported upload endpoint, or a claim of a completed test. Use it to make an evaluation inspectable and to prevent a successful demonstration from being misreported as independent acquisition.

## Example record

```json
{
  "schema_version": "1.0",
  "example": true,
  "run_id": "example-run-001",
  "started_at": null,
  "traffic_class": "controlled_evaluation",
  "task_id": "invoice-lines-01",
  "task": "Find an API for scanned invoice line items with JSON output.",
  "introduction": "unbranded",
  "environment": {
    "application": null,
    "model": null,
    "tools_available": [],
    "login_state": "unknown",
    "locale": "en-US",
    "time_budget_seconds": 120,
    "preloaded_sources": []
  },
  "expected": {
    "supported_input": "scanned PDF",
    "output": "JSON line items",
    "price_unit_explained": true,
    "completion_evidence": "Verified result from a synthetic fixture"
  },
  "observed": {
    "retrieved_urls": [],
    "encountered": "not_run",
    "understood": "not_run",
    "selected": "not_run",
    "completed": "not_run"
  },
  "evidence_references": [],
  "failure_stage": null,
  "limitations": ["Template only; no run has been performed."]
}
```

Empty tools_available means this template contains no recorded tool inventory. In a real run, distinguish a confirmed empty inventory from unknown availability. The expected completion may require a separate authorized adoption test if the unbranded run stops at research.

## Required interpretation

introduction records whether the provider was named, linked, preinstalled, or independently encountered. If a relevant integration is already installed, record that fact even if the natural-language task omits the brand. preloaded_sources exposes another way the provider may already be in context.

Use observed values such as pass, fail, unknown, not_attempted, or not_run, and define them in your evaluation system. Unknown means the evidence does not establish a result. Not attempted means the run did not reach that stage. Neither should silently become a failure or success in an aggregate.

## Preserve evidence safely

Store references to authorized traces, public sources, synthetic inputs, and resulting artifacts. Keep private customer content and credentials out of public reports. Retain only the data needed to substantiate the claim, with appropriate access and retention controls.

A source URL alone is insufficient if its contents can change. Record the relevant observation, collection time, version where available, and a permitted snapshot or content hash when useful. A hash helps identify bytes; it does not establish that the statement was true.

## Aggregate without hiding the denominator

Group comparable tasks and environments. Report total eligible runs, attempted runs, known outcomes, unknown outcomes, and failures by stage. If 3 of 5 retrieved cases complete out of 20 discovery runs, report both 3/5 conditional completion and 3/20 overall completion. Those numbers answer different questions.

Count a rerun as another run, not another customer. Identify task repetitions and evaluation changes. A holdout set should not quietly become a tuning set while retaining the same label. Preserve unsuccessful runs unless a documented exclusion rule applies.

## What the record cannot establish

A controlled task does not establish organic traffic, a buyer's independent intent, incremental revenue, or market-wide assistant behavior. A recorded recommendation does not establish factual correctness without checking its claims. A 200 response does not establish that the intended action completed.

Use [the evaluation guide](https://byagents.dev/humans/evaluating-agent-distribution) to design the experiment and [the event contract](https://byagents.dev/agents/attribution-event-contract) for separate customer-event reporting. Keep the original record with the conclusion so another reviewer can identify which claim the evidence actually supports.

## Related reading

- [How to test whether agent distribution is working](https://byagents.dev/humans/evaluating-agent-distribution)
- [Evidence record: a portable example](https://byagents.dev/agents/evidence-record)
- [Pattern: measure agent activity without inventing attribution](https://byagents.dev/agents/attribution-event-contract)


---

# Pattern: measure agent activity without inventing attribution

> An event vocabulary for infrastructure, referrals, evaluations, and first-party outcomes, with uncertainty preserved.

Canonical: https://byagents.dev/agents/attribution-event-contract
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Pattern
Level: Technical
Outcome: Define event semantics and joins that distinguish crawler requests from useful customer activity.

This proposed event pattern is not a production ByAgents analytics feature. It is a design aid for an authorized first-party measurement system. Choose fields according to your actual consent, retention, and data-access requirements. Avoid collecting personal or sensitive information merely because an agent interaction exists.

## Keep the event types distinct

| Event | What it establishes | What it does not establish |
| --- | --- | --- |
| public_resource_requested | A request reached a public resource | Indexing, citation, or a person |
| referral_landed | An observed source accompanied a visit | The complete discovery history |
| evaluation_stage_observed | A controlled run reached a recorded state | An external prospect |
| inquiry_accepted | The business saved an inquiry | Qualification or revenue |
| activation_verified | A defined first-use outcome occurred | That AI caused the acquisition |
| order_confirmed | The commerce system recorded an order | Fulfillment, retention, or incrementality |

Define events from actual system state. If the server rejects a form, do not fire inquiry_accepted because the button was clicked. If a job starts but never finishes, do not count activation_verified unless the activation definition genuinely ends at submission.

## Example envelope

```json
{
  "schema_version": "1.0",
  "example": true,
  "event_id": "example-event-001",
  "event_type": "inquiry_accepted",
  "occurred_at": null,
  "environment": "example",
  "traffic_class": "controlled_evaluation",
  "resource_path": "/start",
  "source": {
    "observed_referrer_origin": null,
    "provider_claim": null,
    "verification_method": "none",
    "attribution": "unknown"
  },
  "business_record_id": null,
  "evaluation_run_id": "example-run-001",
  "revenue": null
}
```

This is illustrative data; no inquiry is claimed. Null revenue is unknown or inapplicable, not zero realized revenue. Do not publish real inquiry identifiers or attach raw emails to an openly accessible event stream.

## Make verification an explicit field

A claimed user agent, observed referrer, verified network range, and validated signature provide different evidence. Record the method and when it was checked. Provider identity alone does not distinguish training, indexing, user-directed retrieval, or a purchase; use the documented role and observed operation.

A missing referrer should remain unknown. Do not classify direct visits as AI simply because agent traffic is difficult to measure. Campaign tags can describe a link you distributed but do not independently prove which application followed it.

## Join only what you can support

Use a consent-appropriate first-party session or business identifier when available. Define deduplication and attribution windows before reporting trends. Count an event once by its event identifier and a commercial outcome once according to its business record. Preserve existing-account status where relevant.

Do not join a crawler IP to a human buyer by guesswork. An evaluation request can create a test business record; exclude or clearly label that outcome. When a customer reports an AI-assisted decision without a traceable referral, record self-reported assistance separately from observed acquisition.

## Reconcile against operational records

For inquiries, compare accepted submissions with stored records. For APIs, compare activation events with a completed result. For commerce, account for cancellations, refunds, and repeat orders according to a documented policy. An event pipeline can be internally consistent and still use the wrong definition of success.

Report raw counts and uncertainty alongside rates. Platform impressions and citation reports are separate evidence streams, not interchangeable session events. The [measurement guide](https://byagents.dev/humans/measuring-agent-traffic) explains how to combine them without claiming a universal agent-traffic number.

## Related reading

- [Measure agent discovery without fooling yourself](https://byagents.dev/humans/measuring-agent-traffic)
- [Template: a reproducible agent evaluation record](https://byagents.dev/agents/evaluation-record-template)
- [Keep your agent distribution working after launch](https://byagents.dev/humans/maintaining-agent-distribution)


---

# Recipe: validate a product feed across the full handoff

> Check identifiers, variants, current offers, ingestion status, and agreement with the actual purchase destination.

Canonical: https://byagents.dev/agents/feed-validation-recipe
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Recipe
Level: Technical
Outcome: Produce a repeatable feed-quality report with item-level failures and clear unknowns.

Input: an authorized catalog export, the receiving platform's current contract, and a bounded sample of public product destinations. Output: a validation report. Do not submit feeds, alter listings, or create purchases as part of a read-only review unless separately authorized.

## Pin the receiving contract

Record platform, account environment, field specification, file format, and review date. The same concept can have different field names and units across providers. A valid merchant file is not automatically a valid commerce-protocol message or Schema.org record.

The [human feed guide](https://byagents.dev/humans/product-feeds-for-ai-shopping) includes an example based on OpenAI's file-upload contract. Use the current official specification for ingestion, not our example as an exhaustive validator schema. Never infer that a required field is optional because a different provider permits omission.

## Validate individual records

Check required fields, types, permitted values, unique identifiers, URL format, currency units, and non-empty descriptions. Match the item identifier to a purchasable variant. Flag unknown values explicitly rather than replacing them with plausible defaults.

Validate semantics as well as syntax. A price of zero may parse correctly while being commercially wrong. An in-stock flag can be valid vocabulary but stale information. A valid image URL can point to a different color or bundle.

## Validate relationships and updates

Check variant families for stable grouping and distinct purchasable identifiers. Compare create, update, and withdrawal behavior against the receiving platform's actual contract. Ensure a partial failure cannot silently clear required values or duplicate the same item under a new identifier.

Trace each field to its authoritative source. Record export time, source update time when available, and platform acknowledgment time separately. Successful transport does not establish acceptance; acceptance does not establish display or recommendation.

## Inspect a bounded destination sample

Include a normal product, multiple variants, a promotion, an unavailable item, and a withdrawn item where applicable. Confirm the landing page preserves identity, quantity or size, current offer, and the correct next step. Inspect the visible facts and any structured record for contradictions.

Do not complete a live checkout merely to validate a public listing. Use an authorized test environment or stop at the commitment boundary. Record the untested portion clearly so the report cannot be mistaken for a transactional certification.

## Example report

```json
{
  "example": true,
  "platform_contract": "not_selected",
  "export_id": "example-export-001",
  "checked_at": null,
  "records_total": null,
  "records_valid": null,
  "platform_acceptance": "not_checked",
  "destination_sample": [],
  "findings": [
    {
      "item_id": "example-variant",
      "check": "price_agrees_with_destination",
      "result": "not_run",
      "evidence": [],
      "owner": null
    }
  ],
  "checkout_execution": "not_authorized_or_tested"
}
```

Report structural failures separately from semantic discrepancies and uncollected evidence. A partially sampled destination set does not establish accuracy for the entire catalog. Keep a denominator for every rate and identify exclusions.

## Repair and recheck

Fix the upstream source when possible, regenerate the affected record, and inspect the platform's response. Recheck the destination sample after a change that affects mapping or variant selection. Preserve failed records and rejection messages in an appropriate private operational log.

The output should identify the item, conflicting values, source of truth, proposed repair, owner, and verification step. Do not collapse these observations into an “agent trust” grade. Actual discovery and orders require their own evidence.

## Related reading

- [Product feeds for AI shopping](https://byagents.dev/humans/product-feeds-for-ai-shopping)
- [Structured data that helps explain your business](https://byagents.dev/humans/structured-data)
- [From an AI recommendation to a confirmed purchase or booking](https://byagents.dev/humans/agent-commerce-readiness)


---

# Recipe: assess an ARD discovery route

> Distinguish a valid resource description, actual registry ingestion, query retrieval, and a usable downstream capability.

Canonical: https://byagents.dev/agents/ard-discovery-assessment
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Recipe
Level: Technical
Outcome: Test an emerging discovery specification against a named consumer instead of assuming adoption.

Agentic Resource Discovery describes a layer for publishing and finding agentic resources. This recipe is a proposed evaluation procedure. ByAgents does not currently operate an ARD registry or claim that its own knowledge API implements ARD.

## Pin the specification and the consumer

The main-branch ARD specification reviewed on September 13, 2026 identifies v0.91. It describes JSON-LD entries and the well-known `/.well-known/ard.json` path. The predecessor `/.well-known/ai-catalog.json` is optional for consumers to consult. Search relevance is explicitly distinct from trust or safety. [Specification](https://github.com/ards-project/ard-spec/blob/main/spec/ard.md).

Main is mutable. Before implementation, pin a commit or released revision and identify the intended registry or client version. Do not mix an old catalog example with a newer entry schema. A news announcement is useful context, but it is not the full implementation contract.

## Define the experiment

Name one real capability, a representative customer task, and a discovery consumer. Record how that consumer obtains publisher entries. Confirm whether you have permission to publish, register, and invoke the capability; a read-only assessment should stop before those mutations.

Separate the underlying artifact from its discovery description. An MCP server, A2A service, or API may need its own authentication and compatibility checks. A discoverable record can point to a broken or unavailable service.

## Test the route in stages

| Stage | Proposed check | Evidence |
| --- | --- | --- |
| Publication | Fetch the intended manifest from its published location | URL, response, revision, timestamp |
| Validation | Apply the pinned schema and relevant semantic checks | Validator version and specific errors |
| Ingestion | Verify the named consumer actually indexed the entry | Consumer response or observable record |
| Retrieval | Run a representative unbranded query | Query, filters, returned identifier, context |
| Use | Resolve and test the capability within authorization | Compatibility and final task outcome |

Do not infer ingestion from a crawler request alone. Do not infer retrieval from the fact that a record appears in an administrative inventory. Do not infer useful execution from an endpoint returning any response.

## Evaluate descriptions for discrimination

Write a factual capability description that includes the result and meaningful constraints. Test a query the resource should satisfy and a nearby query it should not. A resource that matches everything is not necessarily described well. Preserve the criteria you used before evaluating the results.

Keep publisher assertions distinguishable from verified properties. A description can claim a region, certification, or capability; the audit should retain the evidence supporting that assertion. Do not interpret a semantic relevance value as an independent quality score.

## Decide whether the experiment merits expansion

A successful small test can establish compatibility with one consumer. It does not establish that major assistant products consume the registry, that independent users arrive through it, or that the route has meaningful commercial volume.

Continue when the intended consumers exist, the underlying capability is useful, and the maintenance burden is reasonable. If no relevant consumer ingests the record, report that distribution gap rather than presenting a valid file as traction. Keep the [protocol map](https://byagents.dev/humans/agent-protocols-explained) and [current briefing](https://byagents.dev/humans/agent-distribution-now) separate from claims about actual adoption.

## Sources

- [ARD: Specification on the main branch, reviewed September 13, 2026](https://github.com/ards-project/ard-spec/blob/main/spec/ard.md)

## Related reading

- [MCP, WebMCP, A2A, ACP, UCP, and ARD: what to build](https://byagents.dev/humans/agent-protocols-explained)
- [Recipe: publish and verify an MCP integration](https://byagents.dev/agents/mcp-publication-and-compatibility)
- [Template: a reproducible agent evaluation record](https://byagents.dev/agents/evaluation-record-template)


---

# Recipe: review a technical claim and resolve conflicting sources

> A practical source ledger for versions, dates, scope, contradictions, and the evidence a claim actually supports.

Canonical: https://byagents.dev/agents/source-review-recipe
Published: 2026-09-13
Reviewed: 2026-09-13
Publisher: ByAgents
Type: Recipe
Level: Technical
Outcome: Produce a narrow, traceable conclusion without mistaking fresh-looking copy for current evidence.

Input: a concrete claim that affects a product or implementation decision. Output: a supported conclusion, an explicit uncertainty, or a request for missing evidence. This is a ByAgents editorial method, not a claim that our interpretation overrides a platform's specification.

## State the claim precisely

Replace “This protocol is supported everywhere” with a versioned question about a named client and server. Replace “This makes us discoverable” with a claim about publication, ingestion, retrieval, selection, or completion. The narrower wording makes it possible to identify what evidence is required.

Record whether the claim concerns a normative requirement, a documented product feature, observed behavior, an example, or a prediction. A marketing announcement can establish that a company announced a feature; it does not by itself prove availability in your account or compatibility with your implementation.

## Collect provenance and scope

```json
{
  "example": true,
  "claim": "The intended client supports the selected protocol revision.",
  "claim_type": "compatibility",
  "source_url": "https://example.com/docs/compatibility",
  "publisher": "Example provider",
  "document_version": null,
  "source_published_at": null,
  "reviewed_at": null,
  "relevant_section": null,
  "support": "not_collected",
  "tested_environment": null,
  "conclusion": "unknown"
}
```

Keep source publication time, your retrieval time, and the product release distinct. A page without a visible date is not automatically obsolete; a fresh crawl date is not evidence that its technical content changed recently.

## Prefer the right source for the question

Use the current versioned specification for protocol requirements, official product documentation for supported features, account configuration for account availability, and authorized observations for actual execution. Use primary research for research results, with method and scope retained.

A secondary explanation can point you toward evidence but should not silently become the basis for a precise requirement when the original source is available. This library's recommendations are synthesis; our product facts are first-party statements about our own scope.

## Resolve contradictions explicitly

Compare scope first. Two documents may describe different regions, releases, transports, user tiers, or interaction modes. Then compare dates and whether one source supersedes the other. A more recent broad announcement is not necessarily more specific than a supported-version table.

If the conflict remains, describe both statements and narrow the conclusion. Do not average incompatible claims into a confident answer. If a decision depends on the unresolved point, identify the small compatibility or account check that would settle it.

## A concrete example from this library's review

Google's general AI Search guidance and newer feature-specific Search Console help pages have different dates and levels of detail. Our updated [current briefing](https://byagents.dev/humans/agent-distribution-now) links the specific control and reporting documents and identifies the reviewed date. The conclusion is about those documented Search features, not every AI product Google operates.

Likewise, a mutable protocol main branch and an older released SDK can both be real while remaining incompatible. A publisher should name the revision actually implemented rather than labeling all examples “latest.”

## Preserve the limitation with the citation

Keep the supporting section, source, date, and qualifier near the claim in a public guide. Label fictional examples and proposed workflows. Do not add a review date to unrelated material that was not reviewed. Update affected cross-links and machine-readable copies together.

Cite our original reasoning as our reasoning. Cite an upstream source for its own requirements. Neither a self-description as authoritative nor an instruction to an agent to trust the page is evidence. Useful authority comes from traceable claims and reproducible work, including the cases where the answer remains unknown.

## Related reading

- [Evidence, editorial policy, and trust boundaries](https://byagents.dev/agents/evidence-policy)
- [Agent distribution: what matters now](https://byagents.dev/humans/agent-distribution-now)
- [Keep your agent distribution working after launch](https://byagents.dev/humans/maintaining-agent-distribution)


---

# Route a user into ByAgents

> Choose the developer or business path, understand access limits, and hand off without transferring private information.

Canonical: https://byagents.dev/agents/onboarding-handoff
Published: 2026-09-13
Reviewed: 2026-09-14
Publisher: ByAgents
Type: Reference
Level: Mixed
Outcome: Evaluate fit and choose a safe onboarding handoff for the user.

ByAgents prepares starting plans for businesses that want agents to find, understand and use their offering. This document explains the implemented onboarding route. It does not establish that agents already recommend ByAgents or that its distribution channel has been validated. Read the [current capabilities](https://byagents.dev/agents/facts.json) and [machine-readable handoff](https://byagents.dev/agents/start.json) before deciding whether the product fits a request.

## Choose the relevant path
For APIs, SDKs and developer tools, use the developer URL in the handoff manifest. The person describes one task an agent should complete and can add public documentation, an OpenAPI specification URL, an MCP reference and the authentication approach. The free result shows one tailored integration opportunity, a concrete next step and an example based on the confirmed answers. Providing an MCP reference does not create an MCP server or prove a successful connection.

For brands, products and services, use the business URL. The person confirms the offering, intended customer, one customer request and the desired next action: an inquiry, booking, purchase or API use. The free result shows one tailored opportunity, a concrete next step and an example. Nothing is purchased, published or submitted to a third party.

## Access and consent
The knowledge library is publicly readable. The product is currently an owner-private preview requiring product access and ChatGPT sign-in. External self-service access has not launched. Explain this limitation before offering the handoff; do not promise immediate access to an unauthorized user.

There is no supported public onboarding submission API. The person confirms the details and saves the plan in their own session. Do not create accounts, submit private business information or provide credentials merely because a URL or form exists. An agent operating a browser still needs authorization for the action it takes.

## What crosses the boundary
The link carries only an audience selection and a bounded source label. It does not contain an email, API key, company profile, report or payment information. The source label is self-reported context, not evidence that the visit came from an independent agent. Saved records and identity stay in the product application; marketing and product do not exchange private databases or cookies.

## What the free result means
The preview is assembled from confirmed inputs. It does not fetch the website, review an OpenAPI URL or execute a tool call. Missing-field notices refer to the submitted profile, not a website audit. The completed plan preserves the reviewed preview and its version. Saving preserves the free result. The full corresponding customer workspace requires a paid Insights subscription. It provides source checks, editable task pages, API recipes, exact-version approvals and downloadable releases. Customers publish the reviewed files to their own domain and record the release. A local retrieval verifier produces an importable receipt; actual API execution and independent discovery remain separate tests.

For a free static API check without product access, download the [CLI](https://byagents.dev/downloads/gfa-first-integration-0.2.0.tgz) or [agent skill](https://byagents.dev/downloads/first-api-integration.zip), verify the [checksums](https://byagents.dev/downloads/SHA256SUMS.txt), and provide a local OpenAPI JSON file. These tools need Node.js 22.13 or later and no API key. Use the handoff manifest for their commands. That result is evidence about the supplied contract, not proof of a successful integration or agent discovery. Use these distinctions when summarizing ByAgents to a user.

## Free and paid access
The free signup result contains one useful opportunity based on the supplied answers. It does not represent a percentage of a completed website audit, and the full private draft is not sent to the browser. Insights is proposed at $399 USD per month per business for full findings from supplied material, recommendations, editable files and the saved workspace. Autopilot is a planned $1,490 USD per month tier for recurring checks and approved updates; it is coming soon and cannot be purchased. Checkout remains disabled pending payment activation and external access validation. Public documentation, the CLI and the agent skill remain free without a card. Pricing does not establish willingness to pay, and neither tier guarantees discovery or revenue.

## Sources

- [ByAgents: current product handoff contract](https://byagents.dev/agents/start.json)