Agent Card Optimization is the practice of writing and structuring your Agent Card so that, when an AI orchestrator holds three candidate businesses and has to pick one, it picks yours. The card itself (explained in full here) is the JSON file at /.well-known/agent.json declaring what your business's agent can answer and do. Optimizing it is a writing-and-completeness job wearing a technical costume, and the evidence about what matters is already specific enough to act on.
A word on the name before the work. I'm spelling out "Agent Card Optimization" and skipping the acronym, because ACO already circulates as Agentic Commerce Optimization, a sibling practice about getting products surfaced as rich cards in AI shopping answers. The industry mints acronyms faster than it mints results; we don't need to fight over three letters. What we need is the checklist.
The evidence: two fields carry the selection
The load-bearing research finding, from security firm Trustwave's analysis as reported by Stan Ventures: when a host agent's LLM decides which candidate agent to use, the card's name and description fields carry the most weight. Dileep Thekkethil's framing at Stan Ventures has the right shape: these are the meta title and meta description of the agentic web, and his prediction that SEO audits will soon open with "Where's your Agent Card?" is the one this discipline exists to answer.
Worth knowing where that finding comes from, because it changes both how much to trust it and where the line sits. Trustwave's SpiderLabs team weren't writing an optimization guide. They were demonstrating an attack: a rogue agent publishing an inflated card whose description is written to talk the host model into handing it every task. The mechanism is well evidenced precisely because somebody proved it by abusing it.
That also draws the boundary this discipline has to respect. Writing a description specific enough for a model to route against is optimization. Writing one engineered to win selection you haven't earned is the attack. It's the same clean-hands rule that governs reviews and links, arriving on a new surface, and the checklist below optimizes for accuracy and completeness rather than persuasion.
But notice what's different from the meta-tag era. A human scans ten snippets and clicks one, forgivingly. A model matches a task against a description and delegates, unforgivingly. "Your trusted partner for home comfort solutions" gave a human nothing and a model less than nothing: there's no capability in it to match a task against. The selection layer rewards the same thing good service pages reward, with the tolerance turned down.
The four optimization surfaces
The name. Identity plus function, compressed: "Bluejay Plumbing Booking Agent," not "Bluejay Assistant." A model routing a plumbing booking should be able to select you on the name alone.
The description. The elevator pitch a machine can parse: what you do, for whom, where, and the task types you handle. Every word should survive the question "could a model match a task against this?" Geography belongs here (service areas are selection criteria), and so does specificity ("quotes standard jobs, books service calls, checks availability").
The capability list. Completeness is the ranking factor nobody can game: a skill your card omits is a query your business silently sits out. Inventory what your business can answer and do (hours, pricing, availability, booking, service-area checks, order status), then write one skill entry per item with a description specific enough to match against. The discipline here is the same as the source-of-truth inventory: the card can only expose data you keep clean.
The plumbing. The standard location (/.well-known/agent.json, fetchable, valid JSON), and authentication that works on the first attempt, because an agent that can't authenticate doesn't retry your business, it selects the next one. Per the agent-ready checklist, this is phase-three work sitting on phase-two foundations.
A rewrite, to make it concrete
The fastest way to see the discipline is one description, twice.
Before, the way most first drafts read:
"Acme Home Services is your trusted local partner for all your home comfort needs, committed to quality and customer satisfaction since 2009."
Sixteen years of pride, zero routable capability. A model holding the task "book a furnace repair in Mandarin, Jacksonville for tomorrow morning" finds nothing in that sentence to match against: no services, no geography, no task types.
After:
"Books and quotes HVAC repair, furnace and AC replacement, and maintenance plans for homes in Jacksonville, FL and surrounding beaches; answers availability, pricing-range, and service-area questions; escalates emergencies to a live dispatcher."
Every clause is a matchable claim: three task families, a named geography, a defined escalation path. Nothing about trust, because on this surface trust isn't asserted, it's inferred from auth that works and answers that hold. The rewrite pattern is the whole optimization: replace self-description with capability description, then make sure the capabilities are all there.
The v1 checklist, dated
Versioned deliberately: this is v1, September 2026, and it will be revised.
AGENT CARD OPTIMIZATION CHECKLIST v1 (2026-09)
Selection layer
[ ] Name states identity + function (selectable on its own)
[ ] Description: what, for whom, where, which task types
[ ] No slogan language; every phrase matchable against a task
Completeness layer
[ ] One skill entry per real capability; none missing
[ ] Each skill description specific enough to route against
[ ] Facts behind the card (hours, prices, availability) current
Plumbing layer
[ ] Card at /.well-known/agent.json, fetchable, valid JSON
[ ] Auth declared and working (OAuth 2.0-family)
[ ] Endpoints answer fast (agents route around slow responders)
Governance
[ ] Card reviewed on a schedule, like your Business Profile
[ ] Revision date noted; spec changes tracked against a2a-protocol.org
The candor clause
This discipline is under two years old, sitting on a spec that still moves under Linux Foundation governance. Some of the checklist above will be wrong by its v2, and anything anyone tells you about Agent Cards (including us, including this piece) should carry a revision date; treat undated agent-layer advice the way you'd treat an undated SEO guide, which is to say as a museum piece. That's also the working answer to "should I buy Agent Card services this quarter": for almost everyone, not yet. The businesses that will win this layer are currently doing something duller: keeping their data clean and their structure parseable, so that when the selection layer arrives at their industry, the card is a week of writing instead of a quarter of remediation.
We maintain this checklist as part of the Reforge Method's frontier research, revision-dated, and the update goes to whoever holds the A2A Frontier Brief when the spec shifts.