Business Context Protocol
BCP is the directory layer for the agentic web. A single, canonically-located, cryptographically-signed manifest at /.well-known/business.json that binds a company's legal identity to its agent endpoints, commerce primitives, and policy. It does not replace MCP, A2A, or AP2. It composes them.
What BCP is
- Layer
- Directory + identity over the agent-protocol stack
- Canonical URL
https://<domain>/.well-known/business.json- Format
- JSON-LD subclassing schema:Organization
- Signature
- Detached JWS over the manifest body, signed by a vLEI role credential
- Composes
- MCP, A2A, AP2, UCP, NLWeb, Schema.org, LEI / vLEI
- Status
- Working draft. Pre-v1. Subject to change.
- Governance target
- Linux Foundation / Agentic AI Foundation
The agentic web is being built right now. Anthropic shipped MCP, Google shipped A2A and AP2, Microsoft shipped NLWeb, OpenAI and Stripe shipped ACP, Shopify and Google shipped UCP. Each protocol solves one slice - how a model invokes a tool, how two agents delegate, how a checkout flow runs. None of them answer the company-level question: what is this company, who legally owns it, what can its agents do, what is it allowed to do, and how do I verify any of this?
BCP is that company-level layer. Think of it as the homepage plus the signed certificate of an entity on the agentic web - the place an autonomous agent visits first to learn how the company is reachable. MCP servers, A2A agent cards, AP2 payment endpoints, catalogs, calendars, and contact endpoints are all referenced from a single manifest, signed by the legal entity that owns the domain.
The gap it fills
What exists today and what does not.
| Concern | Existing standard | What it covers | What it misses |
|---|---|---|---|
| Tool invocation | MCP | How a model calls a server's tools, resources, prompts. | Who runs the server. Where to find it. What policy applies. |
| Agent-to-agent | A2A Agent Card | One agent's endpoints, skills, auth schemes. | A whole company that hosts many agents. |
| Site-level NL query | NLWeb /ask | Natural-language query over a site's Schema.org data. | Identity binding, signed assertions, commerce primitives. |
| Checkout | AP2 / ACP / UCP | Signed payment mandates and product catalogs. | Discovery. You still need to know which merchant supports them. |
| Crawl / training policy | llms.txt, agents.txt | Markdown / plaintext signals to AI crawlers. | No operational endpoints. No identity. No signature. |
| Site metadata | Schema.org Organization | Descriptive JSON-LD on every page. | No agent endpoints. No policy. No cryptographic identity. |
| Legal identity | LEI / vLEI | 20-char globally unique entity id, optionally signed. | No operational surface. No commercial primitives. |
| Internal models | DTO (Digital Twin of Organization) | Process inventory, dependencies, SLAs. | Internal-only. Not externally exposable. |
Composition, not replacement
BCP points at existing protocols. It does not extend or fork them.
The biggest mistake a new protocol can make in 2026 is trying to replace the working stack. MCP, A2A, AP2, and UCP all have momentum, vendor neutrality, and growing adoption. A protocol that tries to re-invent their primitives loses on day one.
BCP avoids this by being a directory. A BCP manifest never describes a tool. It points at an MCP server URL where tools are described. It never describes an agent. It points at an A2A agent card. It never describes a payment instrument. It points at an AP2 endpoint. The manifest is the directory; the referenced protocols are the doors.
Five primitives
A BCP manifest has exactly five top-level blocks. Everything nests under one of them.
Identity
Who the company legally is. Legal name, registered domain, LEI (ISO 17442), jurisdiction, legal form, incorporation date, registered address, tax identifiers, industry codes, and external references to Wikidata, Crunchbase, LinkedIn. Cryptographically anchored by a vLEI role credential when available.
Capabilities
How an agent reaches the company programmatically. MCP server URLs with their scopes, A2A agent card URLs, NLWeb/ask endpoint, OpenAPI spec URL, CLI install command, supported auth methods. The manifest never declares individual tools - it points at the MCP server that does.
Commerce
How an agent transacts with the company. Catalog endpoint (UCP-compatible), pricing page, supported currencies, terms of sale, return policy, payment-rail endpoints (AP2, ACP), and supported jurisdictions. Optional. A non-commercial entity can omit this block entirely.
Policy
What agents are allowed to do. Allow-training, allow-RAG, allow-actions list with per-scope grants, deny-actions list, rate limits per agent class, cross-references torobots.txt andllms.txt, AI license terms. Anything an agent could be told to do should be in scope of this block.
State
Current operational status. Service status (operational, degraded, retired), incident webhook, SLA targets, support contact, support hours, and the manifest's own last-updated timestamp. Distinct from identity in that state is expected to change often, while identity barely changes.
Where BCP sits in the stack
The agent-protocol layer cake, with BCP highlighted.
Adoption model
Why we believe BCP can reach distribution before the hyperscalers.
Standards win on distribution, not spec quality. MCP succeeded because Anthropic dogfooded it from day one and shipped reference SDKs. NLWeb won partners because Microsoft brought Tripadvisor, Shopify, and Eventbrite. A2A passed 150 organizations in its first year because Google and Linux Foundation co-sponsored.
Ultron has a different distribution mechanic: every customer gets a BCP manifest as a byproduct of being on Ultron. We generate it from data the customer already entered, host it either at ultron.app/c/<slug>/business.json or at the customer's verified domain, and re-sign it on every material change. A customer goes from zero to "machine-readable company on the open agentic web" in the time it takes to complete onboarding.
This is the bi-directional property that makes BCP useful with one publisher and one consumer (both Ultron). Every Ultron agent reads other companies' manifests when researching, negotiating, or transacting. The protocol delivers value inside the Ultron product before any external party adopts it.
Naming
BCP is the working title. The final acronym will probably change.
The user-facing terms in product copy will be the descriptive ones - "your Business Card", "publish your company to the agentic web" - and the protocol acronym is only used in the spec and these docs.
Governance
Open from day one. Vendor-neutral before v1.
BCP ships as an open spec undergithub.com/nexitynetwork/bcp-spec, with reference implementations in TypeScript and Python. Within twelve months of v1, the spec is donated to a neutral foundation. The de-facto venue is the Linux Foundation's Agentic AI Foundation, the same directed fund that now stewards MCP, A2A, ACP, and AGENTS.md.
Coordination with GLEIF (for vLEI binding semantics) and the FIDO Agentic Authentication Working Group (for agent-acting-for- organization credentials) happens in parallel during the pre-v1 phase. If either body ships an overlapping primitive, BCP delegates to it rather than competing.
Versioning and evolution
Semver in the manifest, SEPs in the repo.
Every manifest carries a bcp:versionfield at the top level. Major version bumps imply breaking changes; minor versions add fields; patch versions clarify existing field semantics. Consumers must ignore unknown fields and degrade gracefully when a referenced endpoint uses a newer protocol revision than they support.
Spec changes flow through Standard Enhancement Proposals (BEPs - BCP Enhancement Proposals) inspired by MCP's SEP process. A BEP is a Markdown document in the spec repo, reviewed publicly, accepted or rejected by the editor team with foundation sign-off after v1.
What BCP is NOT
To prevent scope creep and confused positioning, the following are explicitly out of scope:
| BCP is not | Use this instead |
|---|---|
| A tool-invocation protocol | MCP |
| An agent-to-agent transport | A2A |
| A checkout / payment protocol | AP2 or ACP |
| A product-catalog schema | UCP or Schema.org Product |
| A site-level NL query interface | NLWeb |
| A coding-agent instruction file | AGENTS.md |
| A crawl / training policy file | robots.txt, llms.txt |
| A legal entity identifier | LEI / vLEI directly |
| A digital twin of internal processes | DTO platforms (SAP, Celonis, Ardoq) |
| A blockchain settlement layer | AP2 x402 extension |