Frequently Asked Questions

The fastest way is to run our completely free check – we inspect your site against the published A2A spec and tell you exactly what passes and what doesn't. A2A is a technical specification with strict requirements for data structures, endpoints, and behavior, so it's genuinely hard to self-assess manually. For ongoing assurance – knowing you're still compliant after the next spec release – CorgiMaps continuously generates and maintains a compliant A2A surface for you.

You have two paths. The DIY route is to build and host A2A-compliant endpoints yourself, mapping your product, pricing, and inventory data from all your source systems and files into the exact schema the spec requires and then keep that build current as the spec evolves. The more straightforward path is using CorgiMaps, which connects to your existing data sources and generates compliant A2A endpoints for you, with no custom build necessary.

Shopping behavior is moving into AI assistants. Already, 73% of consumers are using AI in their shopping journey, and Accenture estimates that by 2030 more than 30% of online commerce – close to $3.1 trillion – will run through AI agents. If an AI can't see your products, it will recommend a competitor who is visible. Showing up isn't optional marketing. This is where the next purchase decision happens.

No. Each agentic-commerce protocol defines its own data structures, endpoints, tools, and transport. So supporting one does not make you compliant with another. They overlap in spirit but differ in the details, so each requires its own compliant surface. CorgiMaps covers the major protocols at once from a single connection to your data, instead of building and maintaining a separate integration for each.

Yes, protocols like A2A are how you do it. By publishing a compliant A2A surface, you control the product data, pricing, availability, and purchase behavior an AI uses, instead of letting it infer those from scraped pages. Passive scraping gives you no control in the agentic era; a brand-published protocol surface puts you back in charge of how you're represented.

Different AI assistants and shopping platforms back different protocols, and no single one covers every surface. Supporting only one means you're invisible everywhere it isn't used. To reach as many shopping surfaces as possible, you generally need to support several protocols at once, which is why CorgiMaps maintains compliant surfaces across the major protocols from one place rather than one at a time.

Keeping up is continuous work, not a one-time task. Specs ship new releases, requirements change, and entirely new protocols keep emerging. Doing this by hand means tracking 6–12 evolving specifications and re-validating after every release. This is exactly what CorgiMaps maintains for you. It tracks the spec changes and keeps your endpoints compliant as they land, so your team doesn't have to monitor the protocols at all.

Frequently. Major releases tend to land on roughly a quarterly cadence, with smaller changes and activity happening as often as weekly across the protocols and their governing bodies. Because the space is young and moving fast, a surface that's compliant today can fall behind within a few weeks if no one is watching.

Yes. As new versions of A2A are published and AI platforms deprecate support for older ones, a surface that was compliant can quietly stop working, and you may not notice until you've dropped out of AI results. Staying compliant means tracking every release and updating accordingly. CorgiMaps handles this version drift for you, keeping your A2A surface current as the spec moves.

Building A2A support yourself typically means months of custom engineering – mapping your data into the schema, standing up and hosting endpoints, and testing against the spec – followed by constant monitoring of 6–12 evolving protocols to stay compliant. CorgiMaps removes nearly all of that: it generates compliant endpoints in minutes from your existing data and keeps them current as the specs change, so there's no build and no ongoing maintenance burden on your team.

It fetches your Agent Card, detects whether it is an A2A 1.0 or 0.3 card, and validates it against that version's schema. It checks your declared interfaces and skills, then sends side-effect-free requests to the JSON-RPC and HTTP+JSON interfaces to confirm the agent answers with the errors A2A defines. It also checks basic hygiene and reports whether the card declares commerce extensions. It never sends a message or creates a task.

MCP connects an agent to tools and data; A2A connects an agent to other agents. They are complementary rather than competing: an agent might use MCP to reach your catalog tools and A2A to hand a task to another vendor's agent. They are checked separately, so a clean result on one says nothing about the other.

No. A2A is how agents discover and call each other; UCP and ACP define what a commerce conversation looks like once they are talking. An A2A agent can declare a commerce protocol as an extension in its Agent Card, and the check reports whether it does. Being A2A-compliant does not make you compliant with either commerce protocol.

It validates A2A 1.0 and 0.3 cards. If your card is 0.3-only, you get a warning to upgrade to 1.0, since that is the current published specification. Version 0.2.x is out of range.

At /.well-known/agent-card.json on your domain root. The older /.well-known/agent.json is still read as a fallback, but the check flags it with a warning. If you submit your agent's endpoint URL, the check resolves it to the domain root for you.

Your Agent Card should be public, and the check reads it without credentials. If the interfaces behind it answer with an authentication challenge, they are reported as auth-gated, which is a warning rather than a failure. You can supply an optional bearer token to probe further; it is sent only to your agent's own origin.