How to Create a Public AI Agent Card

To create a public AI agent card, publish one plain page per agent that answers four questions: what the agent does, what data it can see, what it won’t do, and how a person can step in. Put it in normal HTML on your own site, link to it from wherever the agent appears, and keep it short enough to read in two minutes. If other software will call your agent, you can add a machine-readable JSON card later. Write the human one first.

Here’s the situation it solves. You’ve put an AI intake assistant on your agency’s contact page. A prospect is halfway through a conversation and stops: “Wait, can this thing see my inbox? Who reads what I type?”

Your agent card is where that answer already lives, in writing, before anyone has to ask.

What is a public AI agent card?

An AI agent card is a short public page that describes one specific AI agent your business runs: its job, its access, its limits, and who’s accountable for it. Think of it as a spec sheet your clients can actually read.

The idea borrows from model cards, a 2018 proposal by Margaret Mitchell and colleagues for documenting a model’s intended use and how it was evaluated. A model card describes a model. An agent card describes a deployed worker inside your business, which is what your clients actually meet.

The phrase also has a technical meaning. In the A2A protocol specification, an Agent Card is a JSON document published at /.well-known/agent-card.json. It lists fields like name, description, version, capabilities, skills, supportedInterfaces and securitySchemes, so other software agents can find and call yours.

That’s useful if you expose an agent to other systems. Most service businesses aren’t there yet.

	Public agent card (page)	A2A Agent Card (JSON)
Reader	Clients, prospects, your team	Other software agents
Format	HTML page on your site	JSON at /.well-known/agent-card.json
Answers	What it does, sees, won’t do, who to contact	Endpoints, skills, auth schemes
Who needs it	Anyone with a client-facing agent	Teams exposing agents to other systems
Start here?	Yes	Only when a real integration needs it

Why would a small business publish one?

Three reasons, in order of how often they matter.

Trust. Clients already ask what your AI touches. A written answer beats a nervous one on a sales call. Writing it also forces you to decide the answer, which is often the bigger win.

Disclosure rules. Under Article 50 of the EU AI Act, AI systems that interact directly with people must be designed so those people know they’re dealing with AI, unless it’s obvious from context. The Act’s general application date was 2 August 2026, and law firm briefings such as McCann FitzGerald’s confirm the Article 50(1) disclosure duty kept that date. Only the separate duty to mark AI-generated content got a short deferral, to 2 December 2026, for systems already on the market.

A card doesn’t meet that duty by itself, because the disclosure has to happen inside the interaction. It’s a natural place to explain the details, though. This isn’t legal advice. If you serve EU users or work in a regulated field like law or accounting, check your obligations with a qualified lawyer.

Clear facts on a crawlable page. Google says there are “no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary”, and you don’t need special AI text files. So don’t treat the card as a ranking trick. It’s a plain page stating facts about your business, the same foundation covered in what answer engine optimization means for B2B.

What goes on an AI agent card?

We recommend a structure we call the Four-Lane Agent Card. It’s built from the questions a human-in-the-loop setup has to settle before any agent gets credentials: what’s its job, what can it reach, what’s off-limits, and who catches the handoff. The public card is that internal scope, rewritten for a client.

Here’s how the four lanes sit under one agent.

Above the lanes, add a short header:

• Agent name and where it appears (chat widget, email, client portal)
• Owner: a named role, ideally a named person
• Last reviewed date and a version number
• Underlying provider, if you’re comfortable naming it (see the FAQ)

How do you write each lane?

Does: what jobs does it perform?

List tasks as verbs with objects. “Answers questions about our services using our published pages” is useful. “Helps you with anything” isn’t.

Three to six items is plenty. If you need more, you probably have two agents.

Sees: what data can it access?

This is the lane clients care about most, so be specific. Name the sources it reads, the systems it writes to, and how long conversations are kept.

Separate read access from write access. “Can read our public pricing page” and “can create a record in our CRM” are very different permissions, and readers can tell.

Won’t: where are the boundaries?

Write limits as plain refusals. “It won’t quote a final price.” “It won’t give legal or tax advice.” “It won’t send anything on our behalf without a person approving it.”

Only list limits that are actually enforced. If the agent could do something and you’re hoping it won’t, fix the permission before you publish the sentence.

Human: how does a person step in?

Say who the human is, how a client reaches them, and how fast they’ll respond. Then name what triggers a handoff automatically, like a complaint, a refund request or a sensitive topic.

This is where most cards go vague. “Contact support” leaves a worried client guessing. Compare it with “Type ‘person’ and our operations lead replies within one business day,” which names a channel, a role and a deadline.

What does a finished card look like?

Here’s a fill-in template. Copy it, replace the brackets, and delete any line you can’t answer honestly yet.

[Agent name] | Version [1.0] | Last reviewed [date]
Appears in: [chat widget on /contact]
Owner: [role, name]
Provider: [model vendor, or "a commercial LLM provider, named on request"]

DOES
- [verb + object]
- [verb + object]

SEES
- Reads: [sources]
- Writes: [systems + what it creates]
- Keeps conversations for: [period], then [deleted / archived]

WON'T
- [enforced limit]
- [enforced limit]

HUMAN
- Reach a person: [how]
- Response time: [commitment]
- Automatic handoff when: [triggers]

Worked example: an intake assistant for a 14-person agency

This is a hypothetical example built to show the decisions. It isn’t a Magic Teams client, and the numbers are illustrative.

A 14-person B2B marketing agency adds an AI assistant to its contact page. The founder is the bottleneck on every new inquiry. The goal is to qualify leads and book fit calls without the founder reading every message first.

The first draft said “Answers any question about our agency.” Writing the lanes forced four real decisions:

1. Can it quote prices? No. It can share the published starting ranges from the pricing page, nothing else. Custom quotes stay with a person.
2. Can it book calls directly? Yes, but only into open slots on the founder’s calendar marked for intake. It can’t move or cancel existing meetings.
3. What does it keep? Transcripts go into the CRM as a lead note. The team picked 90-day retention for unqualified leads, then deletion.
4. When does a human take over? Any mention of an existing contract, a complaint or a budget above the top published tier routes to the operations lead.

Here’s the before and after, compressed into lanes.

First draft

• Answers any question about our agency
• Uses our systems to help you
• Escalates when needed
• Your data is safe with us

→

Published card

• Does: answers service questions, qualifies fit, books intake calls
• Sees: public site pages, intake calendar slots; writes a lead note to CRM
• Won't: quote custom prices, change existing meetings, give legal advice
• Human: ops lead replies within one business day; type 'person' anytime

Every line in the published version can be checked. A client can test it. So can your team.

The bigger payoff was internal. Decision two exposed that the agent’s calendar connection could edit any event, not just intake slots. The “won’t change existing meetings” line was only true after they narrowed that permission.

Do you also need a machine-readable agent card?

Probably not yet. Use this rule.

If you add the JSON file, keep the facts identical to the page. Two descriptions that disagree are worse than one.

The A2A specification also covers authentication schemes and optional signed cards using JSON Web Signatures. Bring in whoever manages your security before you expose an endpoint.

Where should the card live, and how do you keep it current?

Give each agent its own URL, such as /agents/intake-assistant. Then link to it from:

• the agent’s first message or the chat widget itself
• your privacy policy
• your site footer, if you run several agents

An out-of-date card is a trust problem. Tie reviews to change, not only the calendar. Update it whenever the agent gets new data access, a new tool, a new model provider, or after any incident, and bump the version and date each time.

Before you publish, run through this list.

Before you publish an agent card

• A named owner is listed and has agreed to it
• Every data source is named, with read and write separated
• Every limit in the Won't lane is enforced by permissions
• The escalation path names a role, a channel and a response time
• Version number and last-reviewed date are visible
• The page is plain HTML and linked from where the agent appears
• Legal, finance or security-sensitive firms have had it reviewed

If you’re building several pages like this, they belong inside an AI search content system rather than living as one-offs.

What mistakes make agent cards useless?

• Marketing copy instead of facts. “Powered by cutting-edge AI” tells a reader nothing.
• Listing limits you don’t enforce. That’s a promise you can break by accident.
• No named human. A card without an owner tells clients nobody’s accountable.
• One card for every agent. Different access means different cards.
• Hiding it. If the only link is in your sitemap, it isn’t doing its job.

FAQ

Is an AI agent card legally required?

Not as a named document, as far as we know. Article 50 of the EU AI Act requires people to know they’re talking to AI, and privacy laws may require you to explain data use. A card helps with both, but it doesn’t replace advice from a qualified lawyer in your jurisdiction.

Should I name the AI model or vendor?

It’s a judgment call. Naming the provider helps clients with their own vendor policies, and some will ask anyway. If you switch providers often, say “a commercial large language model provider” and name it on request.

How long should an agent card be?

Short. A header plus four lanes usually fits in 200 to 400 words. Much longer, and you’re probably describing more than one agent.

Who should own it?

Whoever owns the agent’s outcomes, usually an operations lead or the founder. Not the vendor, and not whoever happened to set it up.

Where to start this week

Pick the one agent clients actually touch. Fill in the template, check each limit against real permissions, and publish it.

Then watch whether it changes anything you care about, like fewer “is this safe?” questions on calls, using the approach in how to measure ROI on AI automation.

If writing the card shows that nobody’s quite sure what your agents can touch, that’s an operating problem more than a content one. Mapping who owns each agent and where people step in is the kind of human-in-the-loop work we do at Magic Teams, and a fit call is the easiest way to see whether it’s worth doing for your business.