Connect through A2A

Discover Middleman’s live public agent and prepare for future authenticated company-data handoffs.

An A2A connection lets a company’s agent communicate with a remote agent through a declared protocol. It does not require the two companies to use the same model, framework or programming language. Agent Cards describe interfaces, skills, capabilities and authentication requirements. A2A specification.

Available now

Verified 7 September 2026: Middleman’s live Agent Card advertises A2A 1.0 over HTTP+JSON at https://middlemantechnologies.com/a2a.

Skill	Purpose
middleman-overview	Read Middleman’s public product overview
middleman-insights-list	List published Insights
middleman-insight-get	Retrieve one published Insight by exact slug

This service is synchronous, anonymous and read-only. Its card declares no streaming, push notifications or extended authenticated card. It does not accept supplier data, buyer requirements, attachments, account signup or recurring jobs. Do not send it a supplier API key or private company information.

This public request reads the product overview:

curl --fail-with-body --max-time 15 \
  'https://middlemantechnologies.com/a2a/message:send' \
  -H 'Content-Type: application/a2a+json' \
  -H 'A2A-Version: 1.0' \
  --data '{"message":{"messageId":"public-overview-example","role":"ROLE_USER","parts":[{"text":"What does Middleman do?"}]},"metadata":{"skillId":"middleman-overview"}}'

Fetch the current card before choosing a binding or skill. Use only the operations it advertises; a working public research request does not establish authenticated integration access.

Planned company-data handoff

Authenticated supplier/buyer data exchange over A2A is a planned route. It must advertise an explicit role-specific data skill, input contract, credential scope, size limits and processing receipt before an agent can select it for onboarding.

Prepare your side to:

1. Verify the Middleman destination and the current card, then negotiate a supported protocol and skill.
2. Authenticate as the approved company and role using the published scheme. Do not reuse a supplier key on A2A unless that exact interface declares support for it.
3. Read and map the source in your own environment. Share the approved structured fields, not credentials or a complete agent conversation.
4. Use the agreed record schema, source timestamps and batch identity. A2A handles the exchange; it does not define Middleman’s product/pricing schema or recurring-delivery semantics.
5. If asynchronous tasks are supported, retain their IDs and inspect terminal outcomes and processing artifacts. A submitted or completed task alone does not prove a feed was admitted. Follow advertised polling/notification support, with bounded retries and authenticated callbacks where supported.
6. Run future scheduled reads from an authorized durable runner and inspect each processing receipt. Revoke company access and stop the job when requested.

The application contract must define duplicate-delivery handling and reconciliation. An A2A message identifier is not a substitute for that contract. No task endpoint, callback or authentication scheme for this company-data flow is published yet.

A skill file, MCP and A2A have different jobs

Interface	Job
Buyer/supplier SKILL.md	Instructions your agent reads to prepare onboarding and source integration
Documentation MCP	Search the documentation
Product MCP	Call the currently exposed product tools
A2A	Communicate with the remote agent’s advertised skills
Supplier HTTPS API	Access checks and sample validation when the preview is released

A source-side MCP connector can help an agent read an approved spreadsheet or system. That does not imply the Middleman documentation MCP can receive private records. Read current interface details and release status.