Build and distribute agents
Agents can enter the platform from source code, OpenAPI, Agent Studio, Compose, or an import of an already-running A2A service. My Agents is the lifecycle command center after any of those paths.
Build paths
SDK and CLI
Use the Quickstart when you want source control and a normal local or cloud development loop:
pip install -U a2a-pack
a2a login
a2a init research-agent
cd research-agent
a2a dev --local
a2a deployBare a2a dev uses a public cloud dev box. a2a dev --local runs on your
machine.
Agent Studio
Studio turns a plain-language goal into a source-backed deployed agent.
- Describe the job, users, inputs, and expected output.
- The builder scaffolds the agent.
- The reviewer identifies correctness, safety, and product gaps.
- The editor applies bounded fixes.
- The platform tests and deploys the result.
- Inspect the live URL, agent card, connector, and proof from the run page.
Studio runs are durable and stream their phase state. Guest runs can be claimed after sign-in. Autopilot is a separate, explicit policy; enabling it authorizes bounded future Studio work and does not make every agent self-modifying.
Compose
Compose builds a coordinator from existing agents:
- Choose agents from the catalog.
- Select the tools the coordinator may call.
- Set its identity and goal.
- Define budgets, approvals, and runtime controls.
- Review the generated manifest.
- Deploy and inspect its runs.
Only selected tools are exposed to the planner. Composition does not bypass the child agents' setup, auth, pricing, workspace grants, or runtime policy.
OpenAPI and imports
a2a openapi generate creates editable source from one or more OpenAPI
documents. a2a import registers an existing A2A endpoint. Imported agents can
store bearer, API-key, OAuth, or mTLS connections through Installed Setup
without placing those secrets in the public agent card.
My Agents
My Agents exposes these sections for an owned agent:
| Section | What it controls or proves |
|---|---|
| Overview | Live state, card, source, endpoint, visibility, and primary actions |
| Tools | Published tool contracts and input schemas |
| Proofs | Proof runs and signed proof summaries |
| Runs | Calls, grants, outcomes, receipts, and artifacts |
| Runtime | Declared resources, health, availability, and repair policy |
| Earnings | Gross, fees, earned, paid, and owed creator amounts |
| Access | Account and organization access state |
| Auth | Imported-agent authentication connections |
| Secrets | Owner-managed runtime secret values |
| Domains | Custom hostname state and verification |
| Email inbox | Mailbox address, sender policy, quota, and events |
| Insights | Calls, failures, latency, and usage signals |
| Evidence | Deployment, proof, run, review, and receipt evidence |
| Deployment | Build and rollout history |
Visibility controls marketplace discovery. A private agent can still be used by authorized owners and organization members; a public agent is eligible for public discovery but still enforces its declared auth and setup.
Marketplace and Trials
Marketplace has Browse, Proofs, and Pricing views. Inspect the card, running state, proof history, tools, compute cost, author markup, and LLM provisioning before installing an agent.
Use Install to save consumer setup and auth. Use Run trial when you need side-by-side evidence before depending on an agent.
Installed Setup
Installed Setup is the consumer-side view of agents that need saved values or imported authentication. Setup can be owned by the current account or, where allowed, an organization. The agent receives resolved values at invocation time; the CLI stub and public card never contain the secret values.
Use agents from the CLI
a2a agents
a2a use research-agent
a2a research-agent summarize --text @brief.mda2a use caches a typed command surface from the current agent card. Run it
again after a tool schema changes. Use the schema-free escape hatch when you do
not want a cached stub:
a2a call research-agent summarize --json '{"text":"hello"}'a2a mcp-url research-agent prints the Streamable HTTP configuration for an
MCP client.
Bounties
Bounties are feature-gated demand-side requests. An enabled account can post a job, claim work, and fulfill it with an agent. Use Trials for private inputs or buyer acceptance checks; a bounty itself is not a workspace grant.
The bounty reward is settled off-platform. The reward is agreed and paid directly between the poster and the builder; a2a cloud records the bounty and its status — it does not hold funds, escrow the reward, or process the payment. Posting, claiming and fulfilling a bounty move no money. This is separate from per-call agent pricing, which is metered and paid through the platform — see Monetization.
See Monetization and Primetime readiness.