Your Agent Card Is the New Business Card

The business card compressed a professional identity into a small, portable object. The personal website expanded that identity into a story. The link-in-bio page made the story easier to route: one memorable URL could point to every important destination. The next useful layer is an agent card, a profile designed not only to be read, but to help another person or agent understand what kind of opportunity it may bring and how to bring it safely.

“Agent card” can describe two related things. For a human visitor, it is a clear public page: who you are, what you are open to, what you are not open to, and what happens after someone submits a proposal. For software, it can be a structured description of capabilities, supported request types, input requirements, and an authenticated endpoint. The two views should express the same policy even if their formats differ.

This is more than a digital calling card. A conventional card says, “Here is how to contact me.” An opportunity agent card says, “Here is when to contact me, what information I need, and what I have authorized my representative to do.”

From contact details to an opportunity contract

Most professional profiles optimize for discovery and impression. A visitor can learn where someone worked, what they published, and which links matter. The visitor still has to invent the next step. Should they email? Send a direct message? Book a call? Contact an assistant? Include a budget? Mention a mutual connection?

The ambiguity creates work for both sides. Serious requesters worry about choosing the wrong channel. Low-effort requesters benefit because there is no required structure. The recipient receives a pile of messages that cannot be compared without follow-up.

An agent card turns the profile into a lightweight opportunity contract. It can publish:

Categories the person will consider, such as roles, consulting, speaking, investing, research, advisory work, or introductions.
A short statement of fit for each category.
Required fields, including organization, purpose, timeline, compensation, and decision maker.
Response expectations and whether a review is free or paid.
Boundaries, such as industries, conflicts, travel limits, minimum scope, or unavailable dates.
Actions the agent may take automatically and actions that always require owner approval.
A stable submission path for humans and a structured intake path for authorized agents.

This contract is not a promise to accept. It is a promise about process. That is a more credible and useful promise.

What Linktree taught the internet

Linktree proved the value of a single public link that a person can update without changing every profile where it appears. Its official product materials describe a customizable homebase for links, content, audience collection, bookings, and commerce. That model solved a real distribution problem: profiles often allow one prominent link, while a creator or professional has many destinations.

The agent card inherits that portability and adds selection. Instead of treating every destination as equally available to every visitor, it can respond to intent. A potential client should see the consulting route. A recruiter should see the role criteria. An event organizer should see speaking requirements. A software agent should receive a structured schema rather than guessing from decorative copy.

This is not an argument that link pages disappear. Links remain useful evidence and navigation. The change is that the page gains judgment. It helps the visitor move from browsing to making a complete, appropriate proposal.

One policy, two readers

A human-readable card and a machine-readable card should share a source of truth. If the page says the person is unavailable for unpaid speaking, the structured capability should not advertise generic speaking without that constraint. If the owner pauses advisory work, both surfaces should update together.

The human page can lead with nuance:

I am open to advising early-stage teams on marketplace trust and product strategy. I prefer one clearly scoped question or a short session. I do not review confidential materials before agreeing to the engagement.

The machine representation can express the same policy as fields: category identifier, summary, required inputs, prohibited content, fee type, response window, and whether owner approval is required. A calling agent can then determine whether its client’s request fits before sending anything.

The structured card should not contain secrets. It is a public discovery document. Private email addresses, phone numbers, identity documents, private availability, customer lists, internal pricing rules, and agent credentials belong behind authorization and purpose-specific checks.

How A2A uses the term Agent Card

The Agent2Agent protocol, often shortened to A2A, uses an “Agent Card” for capability discovery. Google’s official explanation describes a JSON document through which an agent advertises information such as its name, skills, endpoint, and supported interaction details. A client agent can inspect that card before attempting to communicate with a remote agent.

That emerging convention is useful inspiration for personal opportunity agents. A person’s public opportunity card could eventually be discoverable in a similar way, allowing a recruiter’s agent or a conference agent to learn which requests are supported and which fields are required.

The important caveat is that inspiration is not compliance. Publishing a JSON file does not make a product A2A-compliant, secure, or interoperable. Protocol implementation requires careful attention to the current specification, authentication, transport, task semantics, error handling, and tests. A consumer-facing product should not claim certification it has not received or compatibility it has not verified.

The near-term goal can be simpler: make the profile easy for agents to parse, give it stable structured fields, and provide a documented intake endpoint. Standards support can be added deliberately as requirements mature.

What belongs on a useful personal agent card

The best card is concise enough to scan and specific enough to route a real request. It can be organized into six layers.

1. Identity and context

Start with the person’s chosen public name, photo or mark, headline, short biography, location or time-zone information they have approved, and a few verification signals. Verification should be precise. “Work email verified” is different from “identity verified,” and neither proves that a proposal will be fulfilled.

2. Opportunity categories

Categories should be verbs or decisions, not vague interests. “Invite me to speak” is easier to act on than “public speaking.” “Propose a paid product review” is clearer than “collaborations.” Each category can have its own required information and boundaries.

3. Decision rules

Publish enough criteria for a requester to self-qualify. A consultant might state project size, domain fit, and start window. A candidate might list role families and work arrangements without announcing an active job search. A creator might specify formats, usage rights, audience fit, and a budget floor.

4. Offers and prices

Some actions can have a price: reviewing a proposal, giving a bounded answer, or holding a short advisory session. The card should say exactly what the payment covers. It should not imply that payment buys approval, endorsement, private contact data, or a continuing relationship.

5. Agent authority

The page should explain the representative’s role in plain language. It may collect details, ask follow-up questions, decline requests outside published rules, and prepare a summary. Scheduling, data disclosure, contracts, and payments may require separate authorization. Visitors should never have to guess whether they are talking to the person or to software acting under limited authority.

6. Submission and status

The final layer is an intake flow that returns a receipt and status. A requester should know whether a proposal was received, needs more information, is being reviewed, was declined, or was accepted for a next step. Status updates should reveal no more than necessary and should resist enumeration by unrelated parties.

Design the card for confidence, not novelty

The visual page still matters. It carries the person’s taste and signals whether the experience is trustworthy. A profile can support different themes while preserving common usability requirements: readable contrast, visible focus states, responsive layout, clear labels, and consistent placement of safety information.

The most important action should remain obvious. Decorative motion should not delay submission or make the page feel like a game. If a theme uses bright colors or expressive borders, the form still needs calm spacing and a predictable hierarchy. If it uses a dark palette, fields and errors still need strong contrast.

The social share image should reflect the selected design enough to feel continuous. When someone shares the card in a message, the preview can carry the person’s name, headline, opportunity categories, and chosen palette. It should not expose private rules or generate a miniature screenshot of a long form. A simple, themed summary is more legible and safer.

Make the card legible to search and agents

Machine discovery begins with ordinary web fundamentals. Use a stable canonical URL, descriptive page title, accurate description, open graph metadata, and structured data appropriate to the page. Render essential public information in the initial HTML when possible. Do not hide the only meaningful copy behind a client-only chat interface.

Then add a documented structured representation. Fields need stable names, enumerated values where practical, versioning, and clear semantics. A calling agent should not infer that “open to opportunities” means “actively looking for a job.” The card can explicitly distinguish passive availability from active search.

Rate limits and abuse controls belong on the intake endpoint, not on the public profile document. The submission contract can require an idempotency key, requester identity, client-agent identifier, callback policy, and accepted content types. Error messages should be useful without revealing whether a private account or hidden capability exists.

Search optimization for agents is less about keyword stuffing than about reducing ambiguity. Say what the person can consider, what evidence is required, what the next state will be, and which action is permitted.

Ownership must survive the agent

A business card remains useful even if the printer closes. A personal agent card should also be portable. The owner should be able to export public profile fields, offer definitions, policies, request history, and consent records in usable formats. They should be able to revoke an agent credential without losing the public URL or the underlying data.

The platform should separate the person’s identity from any one automated persona. “The Concierge” or “The Scout” can shape tone, but it should not become the owner of the relationship. The human remains the principal. The agent acts within authority that can be inspected and revoked.

That ownership model also discourages a dangerous pattern: agents quietly accumulating private dossiers because more context might improve future responses. Context should be purpose-bound. The card should advertise what can be requested, while sensitive information stays in a private store and is released only under an explicit policy.

A practical rollout

The first version does not need a universal protocol. It needs a coherent page and a reliable intake path.

Publish the human-readable opportunity card with three to five categories.
Add explicit required fields and boundaries for each category.
Keep all consequential actions in owner-approved mode.
Expose a read-only structured capability document containing only public data.
Offer a authenticated, rate-limited submission endpoint with receipts.
Observe where requesters and agents misinterpret the policy.
Version the schema before adding more automation or protocol support.

This sequencing treats interoperability as an engineering commitment rather than a marketing label.

Frequently asked questions

Is an agent card just another link-in-bio page?

It can contain links, but its primary job is qualification. It describes what opportunities a person will consider, gathers the information needed to evaluate them, and explains what an authorized agent may do.

Does publishing an Agent Card mean my site supports A2A?

No. A2A defines more than a public description. Do not claim protocol compliance or certification unless the implementation follows the applicable specification and has been tested for the relevant interactions.

Does the card tell people I am actively job hunting?

It should not unless you choose to say that. A core benefit is passive availability: an agent can consider a strong proposal without making a broad social announcement that you are looking.

Should my email and phone number appear in the structured data?

Usually not. Public discovery and private contact are separate. The card can offer a safe intake endpoint, then release contact details only when you approve the next step.

Can another agent submit without a human involved?

Yes, if the endpoint supports authenticated agent submissions and the request fits the published contract. Human-free submission does not require human-free acceptance. The owner can still approve disclosure, scheduling, payment, or commitments.

Give your professional identity an active front door

The business card told people where to reach you. The agent card can tell them how to approach you well. It preserves the portability of a single public link while adding the criteria, boundaries, and structure that serious opportunities deserve.

Claim your Oportuna page and turn your public profile into an opportunity card that works for people and their agents.