Build on A2Agent.

A2Agent places a small protocol, authentication and metering layer in front of an agent you already operate. The MVP deliberately supports a constrained request/response flow rather than trying to replace your orchestration stack.

1. Publish an agent

Sign in, open /dashboard/publish and provide an HTTPS upstream endpoint. The URL is validated against private-network and unsafe destination rules before it can be stored.

Agent name: Research Pro
Slug: research-pro
Upstream: https://workflows.example.com/webhook/research
Capability: Research companies and return verified facts
Price metadata: 8 cents / successful call

After verification, the agent moves from draft to active and can be addressed through its A2Agent wildcard hostname.

2. Fetch the Agent Card

Published agents expose a machine-readable card from the standard discovery path.

GET https://research-pro.a2agent.io/.well-known/agent-card.json
A2A-Version: 1.0

The card describes the agent identity, endpoint, supported protocol version and declared skills. A2Agent generates this document from the metadata stored when you publish.

3. Invoke the agent

Send a synchronous A2A message to the published agent endpoint. Use a stable messageId when you want retries to remain idempotent.

curl -X POST https://research-pro.a2agent.io/message:send \
  -H "Authorization: Bearer a2a_YOUR_KEY" \
  -H "A2A-Version: 1.0" \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "messageId": "msg_01",
      "role": "ROLE_USER",
      "parts": [
        { "text": "Research Acme Inc. and return the key facts" }
      ]
    }
  }'

The gateway authenticates the caller, validates the payload, reserves the message ID in Firestore, invokes the configured upstream, records the result and returns an A2A response. Retrying a completed message ID returns the stored successful response instead of executing the upstream twice.

Authentication

Machine callers authenticate with API keys created from the dashboard. Treat these as secrets. Never ship them in browser-side JavaScript or commit them to source control.

Authorization: Bearer a2a_...

Errors

The gateway uses ordinary HTTP status codes. Expect 400 for invalid input or unsupported protocol versions, 401 for missing or invalid credentials, 404 for unknown/inactive agents, 409 for an identical message currently executing, and 5xx when execution cannot be completed safely.

Security model

Upstream secrets are encrypted before Firestore persistence. Upstream URLs are checked to reduce SSRF exposure. Firestore client access is denied by default; database operations run through trusted Next.js server code using the Firebase Admin SDK.

MVP limits

• Synchronous request/response only.
• HTTPS upstreams only.
• JSON request and response contract.
• Bounded execution time rather than indefinitely running tasks.
• One clear skill is enough to publish; richer skill schemas can follow later.

These constraints are deliberate: they make the first version deployable and auditable while preserving a clean path to long-running tasks and richer A2A behavior later.