DirectRFQ A2A Business Card Specification v0.1. A universal business identity, qualification and RFQ-readiness framework for human and AI-mediated B2B commerce

The DirectRFQ A2A Business Card Specification v0.1 defines a structured, verifiable and machine-readable method for describing a business that wants to be discovered, understood, evaluated and contacted by human buyers, answer engines, procurement platforms and AI agents.

An A2A Business Card connects conventional company information with commercial capabilities, supplier qualification data, evidence, contact routes and Direct RFQ actions.

Its purpose is not merely to describe a business. Its purpose is to help a buyer or an authorised AI agent determine:

• which legal entity it is dealing with;
• what the business supplies or can perform;
• in which commercial role the business operates;
• which customers, industries and territories it serves;
• what evidence supports its claims;
• whether it is suitable for a particular procurement need;
• what information is required to request a quotation;
• which actions can be performed digitally;
• when human consultation or verification is required.

The specification is intended primarily for complex B2B markets where products and services cannot be purchased reliably through a conventional consumer checkout process.

---

Specification status

Field	Value
Specification name	DirectRFQ A2A Business Card Specification
Version	0.1
Status	Public draft
Specification owner	DirectRFQ.com
Primary domain	B2B commerce and procurement
Primary purpose	Business discovery, qualification and Direct RFQ readiness
Intended users	Businesses, buyers, procurement teams, platforms and AI agents
Format	Human-readable page plus structured machine-readable data
Protocol dependency	Protocol-neutral
Publication date	2026
Review status	Experimental and subject to revision

Version 0.1 is an early public specification intended for implementation, testing and market feedback. Fields and conformance requirements may change in subsequent versions.

---

Important distinction: A2A Business Card vs. A2A Agent Card

The DirectRFQ A2A Business Card is not the same as the technical Agent Card defined by the Agent2Agent Protocol.

The official A2A Agent Card is a JSON metadata document published by an operational A2A server. It describes an AI agent’s identity, capabilities, skills, supported interfaces, service endpoints and authentication requirements. Agent2Agent Protocol specification

The DirectRFQ A2A Business Card describes a business organisation.

A company does not need to operate an AI agent to publish an A2A Business Card.

DirectRFQ A2A Business Card	Technical A2A Agent Card
Describes a company or business entity	Describes an operational AI agent
Contains legal and commercial identity	Contains agent identity and provider details
Lists business products and capabilities	Lists executable agent skills
Defines supplier qualification rules	Defines supported interfaces and input/output modes
Provides Direct RFQ routes	Provides an A2A service endpoint
Can exist without an AI agent	Requires an operational A2A server
Developed by DirectRFQ.com	Defined by the Agent2Agent Protocol

A company that operates an A2A-compatible agent may link its A2A Business Card to the agent’s technical Agent Card.

DirectRFQ A2A Business Card is a proprietary, publicly documented business data framework developed by DirectRFQ.com. It is designed to complement existing and emerging agentic-web standards, not to represent itself as an official component of the Agent2Agent Protocol.

---

Why the A2A Business Card is needed

Traditional company profiles are written primarily for people. They commonly contain marketing statements, general service descriptions and contact information, but often omit the data required for systematic supplier qualification.

A conventional company page may not allow an AI agent to determine:

• the exact legal entity behind a brand;
• whether the company is a manufacturer, distributor, integrator or intermediary;
• which products are currently supplied;
• which capabilities are performed internally or through partners;
• which countries are covered by sales, delivery, installation and service;
• which claims have been verified;
• what documentation is available;
• what conditions exclude the supplier from consideration;
• what data is required before a quotation can be prepared;
• how quickly the company responds;
• whether an endpoint, form or agent-supported action is available.

The A2A Business Card addresses this information gap by creating a canonical business record that can be used across websites, answer engines, procurement systems, agent registries and Direct RFQ workflows.

---

Core objectives

The specification has seven principal objectives.

1. Findability

Help humans, search engines and AI agents find the correct business entity, its capabilities, products, documents and contact routes.

2. Identity resolution

Distinguish the legal entity from its brands, websites, operating locations, partners, publishers and commercial intermediaries.

3. Business understanding

Describe what the organisation does using clear categories, roles, identifiers and capability statements.

4. Supplier qualification

Allow a buyer or agent to determine whether the business may be suitable for a specific requirement.

5. Evidence and trust

Associate important claims with sources, verification status, dates and responsible data owners.

6. Direct RFQ readiness

Define the information, actions and escalation paths required to initiate a qualified request for quotation.

7. Agent actionability

Provide a route from passive information retrieval to structured actions such as submitting an RFQ, requesting technical qualification or checking an enquiry status.

---

What the specification does not do

An A2A Business Card does not automatically:

• certify the quality of a supplier;
• confirm that every statement remains permanently valid;
• guarantee product availability;
• guarantee a price or delivery date;
• constitute a binding quotation;
• replace contractual due diligence;
• replace an official company registry;
• replace a Digital Product Passport;
• replace product-level technical documentation;
• authorise an AI agent to enter into a contract;
• prove compliance with every legal or industry requirement;
• make a business technically A2A-enabled.

Binding commercial terms must be provided through a formal quotation, order confirmation, contract or another authorised transactional document.

---

A2A Business Card architecture

An A2A Business Card should act as the canonical root of a connected business information graph.

It may link to:

• A2A Product Cards;
• A2A Capability Cards;
• Direct RFQ Cards;
• technical A2A Agent Cards;
• product catalogues;
• service catalogues;
• compliance documents;
• case studies;
• operating locations;
• verified contact points;
• OpenAPI descriptions;
• MCP servers;
• WebMCP tools;
• procurement onboarding resources;
• Digital Product Passports.

The Business Card should identify the organisation. Product and Capability Cards should provide the detailed commercial qualification data. Direct RFQ Cards should collect the information required for a particular purchasing intent.

---

Normative language

The terms MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY and OPTIONAL are used to indicate the importance of individual requirements.

• MUST means that the requirement is mandatory for the relevant conformance profile.
• SHOULD means that the requirement is recommended unless a documented reason prevents its use.
• MAY means that the field or feature is optional.
• CONDITIONAL means that the requirement applies only when a particular service, status or functionality is claimed.

---

Conformance profiles

The specification defines progressive conformance profiles. A business can begin with a basic record and add more advanced capabilities over time.

Level 1 — Business Listed

The business has a canonical public record containing:

• legal name;
• trading name;
• country;
• primary domain;
• business description;
• basic categories;
• contact point;
• data date.

This level supports basic discovery but does not indicate independent verification.

Level 2 — Entity Verified

The legal identity, identifiers, domain relationship and selected business claims have been checked against declared sources.

Additional requirements include:

• source attribution;
• verification date;
• data owner;
• publisher;
• next review date;
• claim statuses;
• canonical identifiers.

Level 3 — Agent Qualifiable

The card contains enough structured information for an AI agent to determine whether the business is a potential match for a defined procurement need.

Additional requirements include:

• commercial roles;
• markets served;
• capability statements;
• eligibility conditions;
• exclusions;
• escalation rules;
• links to products or capabilities.

Level 4 — Direct RFQ Ready

The business provides structured routes for initiating qualified requests for quotation.

Additional requirements include:

• supported RFQ types;
• required RFQ inputs;
• RFQ contact or form;
• acknowledgement policy;
• response targets;
• human-review conditions;
• status model;
• binding-offer policy.

Level 5 — Agent Actionable

An AI agent can perform at least one structured action through a form, WebMCP tool, API or equivalent interface.

Examples include:

• submitting an RFQ;
• requesting technical qualification;
• requesting a rental quotation;
• requesting service;
• uploading product information;
• checking an RFQ status.

WebMCP is an emerging web standard designed to expose structured website tools to AI agents through annotated forms or JavaScript interfaces. Chrome WebMCP documentation

Level 6 — A2A Enabled

The business operates or formally appoints an operational AI agent that:

• has a valid technical A2A Agent Card;
• exposes an A2A-compatible interface;
• declares its skills and limitations;
• uses appropriate authentication;
• links back to the business entity;
• includes human escalation where required.

A technical Agent Card is typically published at:

https://example.com/.well-known/agent-card.json

Level 7 — Agent Transactable

An authorised agent can proceed beyond enquiry submission and complete defined commercial actions within a documented mandate.

This level requires additional safeguards concerning:

• agent identity;
• delegated authority;
• approval limits;
• authentication;
• transaction logging;
• payment or purchase authorisation;
• human confirmation;
• dispute and cancellation procedures.

Level 7 does not imply unlimited autonomous purchasing.

---

Required information groups

1. Card metadata

Every card MUST contain:

• card identifier;
• card type;
• specification name;
• specification version;
• card version;
• canonical URL;
• publication status;
• visibility level;
• issue date;
• last update date;
• last verification date;
• next review date;
• publisher;
• data owner;
• supported languages.

2. Legal identity

Every card MUST contain:

• full legal name;
• legal form;
• country of registration;
• registered address;
• principal company identifier;
• tax identifier, where applicable;
• official registry source or verification route.

It SHOULD also contain, where relevant:

• registration date;
• registered capital;
• EORI;
• LEI;
• GLN;
• licences;
• regulated status.

Sensitive financial information such as bank account numbers SHOULD NOT be included in the public layer.

3. Commercial identity

The card MUST distinguish:

• legal entity;
• trading name;
• brands;
• primary website;
• additional domains;
• operating locations;
• contracting entity;
• seller of record;
• publisher of the card;
• RFQ recipient.

4. Business roles

The card SHOULD declare the roles in which the business may act, for example:

• manufacturer;
• contract manufacturer;
• brand owner;
• importer;
• distributor;
• reseller;
• systems integrator;
• service provider;
• rental provider;
• installer;
• maintenance provider;
• commercial intermediary;
• procurement representative.

Roles SHOULD be assigned to specific product or capability categories rather than declared only at company level.

5. Products, services and capabilities

The card MUST contain either structured capability statements or links to separate Product and Capability Cards.

Each capability SHOULD specify:

• capability identifier;
• name;
• description;
• category;
• delivery model;
• internal or partner delivery;
• geographic scope;
• industries served;
• constraints;
• current status;
• evidence;
• related RFQ route.

6. Geographic coverage

Coverage SHOULD be stated separately for:

• sales;
• shipping;
• installation;
• commissioning;
• training;
• warranty service;
• post-warranty service;
• spare parts;
• remote support.

A statement such as “operates internationally” is not sufficiently precise without additional qualification.

7. Commercial profile

The card MAY include:

• accepted currencies;
• typical order model;
• minimum order value;
• indicative project-value bands;
• public or RFQ-based pricing;
• standard payment model;
• leasing or financing availability;
• typical lead-time ranges;
• stock or made-to-order model;
• delivery terms;
• supported Incoterms.

All time-sensitive commercial data MUST include an update date or validity period.

8. Buyer and supplier qualification

The card SHOULD define:

• suitable buyer profiles;
• supported industries;
• minimum technical inputs;
• mandatory commercial information;
• accepted project types;
• unsupported use cases;
• automatic exclusion conditions;
• conditions requiring human review.

9. Direct RFQ routes

A Direct RFQ Ready card MUST specify:

• supported RFQ types;
• channel status;
• submission route;
• required and optional fields;
• permitted attachments;
• acknowledgement method;
• initial response target;
• technical review target;
• human-review rules;
• binding-offer channel;
• privacy notice;
• RFQ status model.

10. Trust, evidence and provenance

Important claims SHOULD be associated with:

• claim identifier;
• claim text;
• claim status;
• evidence type;
• evidence URL or document reference;
• verification method;
• verification date;
• verifier;
• validity date;
• confidence or assurance level.

11. Technical interfaces

The card MAY expose:

• human-readable page;
• JSON-LD;
• downloadable JSON;
• JSON Schema;
• OpenAPI description;
• WebMCP tools;
• MCP server;
• technical A2A Agent Card;
• ai-catalog.json;
• webhook or status endpoint.

Agentic Resource Discovery allows providers to publish an ai-catalog.json file describing available agents, MCP servers, OpenAPI tools and other resources. Google: Agentic Resource Discovery

12. Governance and lifecycle

The card MUST identify:

• data owner;
• publisher;
• maintenance responsibility;
• last update;
• last verification;
• next review date;
• correction contact;
• archived-card policy.

A card that has passed its next review date SHOULD be marked as potentially outdated.

---

Claim status vocabulary

The following standard statuses are recommended.

Status	Meaning
confirmed	Currently offered or verified
conditional	Available when stated conditions are met
partner_delivered	Delivered partly or entirely by a disclosed partner
on_request	Availability requires individual confirmation
temporarily_unavailable	Normally offered but currently unavailable
not_offered	Explicitly outside the current scope
unknown	Insufficient verified information
historical	Previously valid but no longer current

The use of explicit statuses is preferred to repeated expressions such as “may be available” or “subject to confirmation”.

---

Verification levels

A claim or data field may carry one of the following verification levels.

Self-declared

Provided by the business but not independently checked by the card publisher.

Source-supported

Supported by a cited official or first-party source.

Publisher-verified

Checked by the card publisher using a documented verification process.

Third-party verified

Confirmed by an independent authority, registry, certification body or other qualified third party.

Transaction-verified

Supported by evidence of an actual delivery, transaction, implementation or completed service.

Verification applies to a defined claim and date. It does not permanently certify the entire company.

---

Visibility layers

Not every field should be publicly available.

Public layer

Suitable for open web publication:

• legal identity;
• public capabilities;
• markets;
• contact routes;
• public evidence;
• RFQ requirements;
• structured discovery data.

Verified-buyer layer

Available after buyer identification or authentication:

• detailed certificates;
• insurance information;
• selected financial or onboarding data;
• restricted technical documentation;
• partner authorisations;
• detailed service coverage.

Transactional layer

Available only within a specific RFQ, commercial relationship or contract:

• negotiated pricing;
• credit limits;
• confidential drawings;
• customer-specific terms;
• private stock allocations;
• personal contact details;
• banking details.

---

Recommended machine-readable template

The following YAML template illustrates the universal structure of an A2A Business Card. Production implementations SHOULD also provide valid JSON and a published JSON Schema.

specification:
  name: "DirectRFQ A2A Business Card Specification"
  version: "0.1"
  profile: "direct_rfq_ready"

card:
  card_id: "urn:directrfq:business:PL:VAT_ID"
  card_type: "a2a_business_card"
  card_version: "1.0.0"
  canonical_url: "https://example.com/a2a-business-card/"
  status: "active"
  visibility: "public"
  issued_at: "2026-07-20"
  updated_at: "2026-07-20"
  last_verified_at: "2026-07-20"
  next_review_at: "2026-10-20"
  languages:
    - "en"
  correction_contact: "data@example.com"

subject:
  legal_name: "Example Company Limited"
  trading_name: "Example Company"
  legal_form: "limited_company"
  country_of_registration: "PL"
  registered_address:
    street: "Example Street 1"
    postal_code: "00-000"
    city: "Warsaw"
    region: "Mazowieckie"
    country: "PL"
  registration_date: "2024-01-01"
  identifiers:
    - scheme: "VAT"
      value: "PL0000000000"
      verification_url: "https://official-registry.example/"
    - scheme: "KRS"
      value: "0000000000"
      verification_url: "https://official-registry.example/"
  primary_domain: "https://example.com"
  same_as: []
  brands: []
  operating_locations: []

responsibilities:
  data_owner:
    name: "Example Company Limited"
    role: "subject_business"
  card_publisher:
    name: "Card Publisher"
    role: "publisher"
  specification_owner:
    name: "DirectRFQ.com"
    role: "specification_owner"
  rfq_operator:
    name: "Example Company Limited"
    role: "rfq_recipient"
  contracting_entity:
    name: "Example Company Limited"
    status: "confirmed_in_formal_offer"

business_profile:
  business_type: "B2B"
  primary_industry: "industrial_equipment"
  description: "Short factual description of the business."
  roles:
    - role: "distributor"
      status: "confirmed"
      categories:
        - "example_category"
    - role: "service_provider"
      status: "conditional"
      categories:
        - "technical_service"
  classifications:
    nace: []
    unspsc: []
    eclass: []
    gs1_gpc: []

markets:
  customer_types:
    - "manufacturer"
    - "warehouse"
    - "distributor"
  industries_served: []
  sales_countries:
    - "PL"
  shipping_countries:
    - "PL"
  installation_countries:
    - "PL"
  service_countries:
    - "PL"
  excluded_markets: []

commercial_profile:
  pricing_model:
    - "request_for_quote"
  currencies:
    - "PLN"
    - "EUR"
  order_models:
    - "purchase"
    - "rental"
    - "service"
  minimum_order_value:
    value: null
    currency: null
    visibility: "on_request"
  typical_project_value:
    minimum: null
    maximum: null
    currency: "EUR"
    visibility: "restricted"
  payment_models:
    - "prepayment"
    - "individually_agreed"
  delivery_model:
    - "stock"
    - "made_to_order"
  supported_incoterms: []
  commercial_data_updated_at: "2026-07-20"

capabilities:
  - capability_id: "cap:example:001"
    name: "Example capability"
    description: "Clear and bounded description."
    category: "example_category"
    delivery_responsibility: "internal"
    status: "confirmed"
    geographic_scope:
      - "PL"
    industries: []
    constraints: []
    evidence_refs:
      - "evidence:001"
    capability_card_url: null
    direct_rfq_card_url: null

products:
  product_catalogue_url: "https://example.com/products/"
  product_card_urls: []

services:
  service_catalogue_url: "https://example.com/services/"
  capability_card_urls: []

qualification:
  suitable_for:
    - "Defined buyer or project profile"
  required_buyer_information:
    - "company_name"
    - "country"
    - "contact_email"
  required_technical_information:
    - "application"
    - "dimensions"
    - "capacity"
  automatic_exclusions: []
  human_review_triggers:
    - "custom_engineering"
    - "regulated_environment"
    - "unusual_operating_conditions"
  qualification_result_values:
    - "potential_match"
    - "needs_information"
    - "human_review"
    - "not_suitable"

rfq:
  supported: true
  channel_status: "active"
  accepted_rfq_types:
    - "product_quote"
    - "solution_selection"
    - "rental"
    - "service"
  submission_channels:
    - type: "web_form"
      url: "https://example.com/direct-rfq/"
    - type: "email"
      address: "rfq@example.com"
  required_fields:
    - "buyer_company"
    - "contact_person"
    - "requirement_description"
    - "delivery_country"
  optional_fields:
    - "budget"
    - "required_date"
    - "attachments"
  attachment_policy:
    accepted_formats:
      - "application/pdf"
      - "image/jpeg"
      - "image/png"
    confidential_information_warning: true
  response_policy:
    automatic_acknowledgement: true
    acknowledgement_target: "PT1H"
    initial_review_target: "P1D"
    technical_review_target: "P3D"
    business_days_only: true
  human_review_required: true
  binding_offer_channel: "formal_written_offer"
  privacy_notice_url: "https://example.com/privacy/"
  terms_url: "https://example.com/terms/"
  status_values:
    - "received"
    - "validation_required"
    - "missing_information"
    - "technically_qualified"
    - "not_qualified"
    - "human_review"
    - "offer_in_preparation"
    - "offer_issued"
    - "accepted"
    - "declined"
    - "expired"
    - "closed"

actions:
  - action_id: "submit_rfq"
    name: "Submit Direct RFQ"
    status: "active"
    human_confirmation_required: true
    interface_type: "web_form"
    interface_url: "https://example.com/direct-rfq/"
  - action_id: "request_consultation"
    name: "Request human consultation"
    status: "active"
    human_confirmation_required: true
    interface_type: "web_form"
    interface_url: "https://example.com/contact/"

contacts:
  - contact_id: "contact:rfq"
    purpose: "request_for_quote"
    email: "rfq@example.com"
    telephone: "+48000000000"
    languages:
      - "en"
    service_hours:
      timezone: "Europe/Warsaw"
      days:
        - "monday"
        - "tuesday"
        - "wednesday"
        - "thursday"
        - "friday"
      start_time: "08:00"
      end_time: "16:00"

evidence:
  - evidence_id: "evidence:001"
    claim: "Example Company provides the stated capability."
    claim_status: "confirmed"
    verification_level: "source_supported"
    evidence_type: "official_company_page"
    evidence_url: "https://example.com/capability/"
    verified_at: "2026-07-20"
    valid_until: "2026-10-20"
    verified_by: "Card Publisher"

documents:
  public_documents: []
  restricted_documents:
    access_policy: "verified_buyer"
    categories: []

technical_interfaces:
  human_readable_url: "https://example.com/a2a-business-card/"
  json_ld_url: "https://example.com/a2a-business-card/#structured-data"
  json_url: "https://example.com/.well-known/business-card.json"
  json_schema_url: "https://directrfq.com/schemas/a2a-business-card/0.1/"
  ai_catalog_url: "https://example.com/.well-known/ai-catalog.json"
  openapi_url: null
  webmcp_enabled: false
  mcp_server_url: null
  a2a_agent_card_url: null

agent_relationship:
  operational_agent_available: false
  agent_name: null
  agent_provider: null
  agent_card_url: null
  agent_authority_scope: []
  human_escalation_available: true

privacy_and_security:
  privacy_notice_url: "https://example.com/privacy/"
  data_controller: "Example Company Limited"
  automated_processing_disclosed: true
  confidential_data_policy_url: null
  authentication_required_for_restricted_data: true

governance:
  maintenance_owner: "Example Company Limited"
  review_frequency: "quarterly"
  changelog_url: "https://example.com/a2a-business-card/changelog/"
  archive_policy: "retain_previous_public_versions"
  complaints_and_corrections_email: "data@example.com"

---

Minimum Core profile

A minimal conforming A2A Business Card MUST contain:

card:
  card_id:
  card_version:
  canonical_url:
  status:
  updated_at:
  last_verified_at:
  next_review_at:

subject:
  legal_name:
  legal_form:
  country_of_registration:
  registered_address:
  identifiers:
  primary_domain:

responsibilities:
  data_owner:
  card_publisher:
  rfq_operator:
  contracting_entity:

business_profile:
  description:
  roles:

markets:
  customer_types:
  sales_countries:

qualification:
  suitable_for:
  human_review_triggers:

contacts:
  purpose:
  email:
  languages:

governance:
  maintenance_owner:
  correction_contact:

A card without these fields may still be published as an informational company profile, but it SHOULD NOT be described as conforming to the DirectRFQ A2A Business Card Core profile.

---

Direct RFQ action model

The A2A Business Card should support a progression from information to action.

Discovery

The buyer or agent discovers the business.

Identity verification

The legal entity, brand, domain and commercial role are resolved.

Initial qualification

The buyer’s need is compared with declared products, capabilities, geographies and constraints.

Information-gap detection

Missing technical or commercial data is identified.

RFQ construction

The appropriate Direct RFQ Card or category-specific questionnaire is selected.

Submission

The buyer or authorised agent submits the RFQ through a declared channel.

Validation

The receiving business checks identity, completeness, technical feasibility and commercial fit.

Human escalation

A human specialist reviews complex, high-risk or non-standard requirements.

Formal quotation

The business issues a binding or non-binding commercial offer through an authorised channel.

The A2A Business Card does not itself create a contract.

---

Relationship with other standards and formats

A2A Agent Card

Used when the business operates an A2A-compatible agent. It describes the agent rather than the company.

Model Context Protocol

MCP may expose business data, product information, tools or RFQ functions to compatible AI systems.

WebMCP

WebMCP may expose website forms and actions as structured tools that browser-based agents can use more reliably.

Agentic Resource Discovery

An ai-catalog.json file may advertise the company’s available Agent Cards, MCP servers, OpenAPI tools and other agentic resources.

ACP and UCP

Agentic Commerce Protocol and Universal Commerce Protocol address important parts of AI-mediated product discovery and commerce. Direct RFQ is designed to complement such systems in complex B2B transactions requiring qualification, configuration, negotiation or human approval.

Digital Product Passport

A Digital Product Passport describes regulated or sustainability-related product data. An A2A Business Card identifies and qualifies the business. Product Cards may link to relevant DPP records.

Schema.org

Schema.org types such as Organization, LocalBusiness, Product, Service, Offer, ContactPoint and DefinedTerm may be used in the JSON-LD presentation layer.

---

Data quality principles

A conforming implementation SHOULD follow these principles.

Canonicality

Each business should have one canonical A2A Business Card per legal entity and scope.

Specificity

Statements should be precise enough to support qualification.

Evidence

Material claims should link to appropriate evidence.

Freshness

Time-sensitive data should include dates and validity periods.

Separation of roles

The subject, publisher, data owner, RFQ operator and contracting entity should be clearly distinguished.

Controlled vocabulary

Stable identifiers and enumerated statuses should be preferred to ambiguous free text.

Progressive disclosure

Sensitive information should be disclosed only to appropriately verified recipients.

Human accountability

The responsible human or organisation should remain identifiable at each significant decision point.

Protocol neutrality

The core business record should remain useful even if individual agentic-commerce protocols change.

Interoperability

The card should link to recognised technical standards whenever an actual implementation exists.

---

Benefits for suppliers

An A2A Business Card can help a supplier:

• establish an unambiguous digital business identity;
• appear in more relevant supplier searches;
• reduce incorrect enquiries;
• communicate capabilities and limitations;
• shorten technical qualification;
• standardise RFQ intake;
• provide evidence to procurement teams;
• improve visibility in answer engines;
• prepare for agentic commerce;
• connect websites with future agent interfaces;
• maintain a reusable supplier data record.

---

Benefits for buyers and procurement teams

An A2A Business Card can help buyers:

• identify the correct contracting entity;
• distinguish manufacturers from distributors and intermediaries;
• verify selected supplier claims;
• compare capabilities;
• detect missing information;
• prepare better RFQs;
• reduce repetitive clarification;
• route enquiries to the correct contact;
• understand response expectations;
• maintain human control over high-risk decisions.

---

Benefits for AI agents

A structured A2A Business Card allows an AI agent to:

• resolve the correct business entity;
• identify products and capabilities;
• evaluate basic supplier fit;
• distinguish confirmed data from unverified claims;
• determine when information is outdated;
• select the appropriate RFQ route;
• collect the required inputs;
• avoid unsupported assumptions;
• identify actions requiring human approval;
• connect to available technical interfaces.

---

Governance of the specification

DirectRFQ.com maintains the DirectRFQ A2A Business Card Specification.

Future versions may introduce:

• a formal JSON Schema;
• controlled vocabularies;
• sector-specific extension modules;
• a public validator;
• domain-verification mechanisms;
• signed card manifests;
• registry interoperability;
• conformance test suites;
• verified-card profiles;
• change-notification feeds;
• RFQ status APIs;
• agent identity and authority extensions.

Implementers should declare the exact specification and profile used by each card.

---

Frequently asked questions

Is the DirectRFQ A2A Business Card an official part of the Agent2Agent Protocol?

No. It is an independent business data framework developed by DirectRFQ.com. It complements the technical A2A Agent Card but does not replace it.

Does a company need an AI agent to create an A2A Business Card?

No. A company can publish a Business Card before it deploys any AI agent.

What is the difference between an A2A Business Card and a company profile?

A conventional company profile mainly describes the organisation. An A2A Business Card also defines legal identity, commercial roles, capabilities, evidence, qualification rules, RFQ requirements, lifecycle data and machine-readable interfaces.

Is an A2A Business Card a supplier certificate?

No. It may contain verified claims, but it does not automatically certify the entire supplier.

Does the card constitute a commercial offer?

No. A binding quotation or contract must be issued through an authorised commercial channel.

Can pricing and availability be included?

Yes. Time-sensitive information must include an update date, validity period and relevant conditions.

Can some information remain private?

Yes. The specification supports public, verified-buyer and transactional information layers.

Is an A2A Business Card the same as a Digital Product Passport?

No. A Business Card describes and qualifies an organisation. A DPP relates to a particular product and its regulated or lifecycle data. The records may be linked.

What does Agent Qualifiable mean?

It means that an AI agent can use the available information to determine whether the business is a potential supplier for a defined requirement, without assuming that the supplier has been finally approved.

What does A2A Enabled mean?

Within this specification, A2A Enabled means that the business operates or formally appoints an operational agent with a valid technical A2A Agent Card and compatible endpoint.

How often should a card be reviewed?

The frequency depends on the business. Quarterly review is recommended for active commercial cards, while prices, stock, documents and contact details may require more frequent updates.

Does an A2A Business Card guarantee selection by AI systems?

No. It improves clarity, discoverability and qualification readiness, but no external platform or agent is required to select the business.

---

Start with an A2A Business Card

DirectRFQ.com helps B2B companies transform fragmented company information, product data, capabilities, documents and RFQ processes into structured business resources for human and AI-mediated commerce.

A typical implementation may include:

• business identity mapping;
• capability modelling;
• source and evidence review;
• A2A Business Card creation;
• Product and Capability Cards;
• Direct RFQ templates;
• JSON-LD and machine-readable data;
• Agentic Commerce Readiness assessment;
• WebMCP, API, MCP or A2A integration planning;
• data maintenance and periodic verification.

To discuss an implementation, contact DirectRFQ.com.

---

Suggested meta title

A2A Business Card Specification v0.1 | DirectRFQ

Suggested meta description

Explore the DirectRFQ A2A Business Card Specification v0.1: a structured framework for business identity, supplier qualification and agent-ready B2B RFQ.

Suggested URL

/standards/a2a-business-card-specification-v0-1/

Primary keyword

A2A Business Card Specification

Supporting keywords

• A2A Business Card
• agent-ready business profile
• AI supplier qualification
• Direct RFQ Standard
• agentic commerce readiness
• machine-readable business data
• B2B Agent Card
• AI procurement data
• Agent Qualifiable supplier
• A2A Enabled business

---

contact@directrfq.com

---