deploy
two hosts, two deploys
Agent on one host, frontend on Vercel/Netlify — two repos, two pipelines, two deploys.
a2a cloud
React/Vite app packed with the agent — one deploy ships the whole agent app.
the agent, with a face
Give your AI agent a frontend.
Your agent is an API. The people who use it expect a chat window. Standing that up usually means a second repo, a second deploy, a second host, and a cross-origin auth headache. a2a cloud hosts a React/Vite frontend packed alongside the agent — same domain, same auth gateway, TLS included — so the whole agent app, UI and all, ships in one deploy.
one deploy · same domain · one auth model
0
separate deploys
0%
same domain
idle UI cost
the problem
An agent API isn't something a person can use.
You built an agent and exposed it as an endpoint. Now someone wants to actually use it, and an endpoint isn't a product — it needs a UI. The default path is to spin up a separate frontend on another host, give it its own auth, configure CORS between two origins, and keep a web server running just to serve the chat. Two deploys, two things to secure, two places for the record to drift.
The frontend lives in a second repo and pipeline, deployed to a different host.
Cross-origin between UI and agent means CORS, cookie, and DNS configuration.
The UI needs its own auth, usually an exposed API key bolted onto the agent's.
You keep a web server or static host online just to serve the chat interface.
the a2a way
Pack the UI with the agent and deploy once.
a2a treats the frontend as part of the whole agent app: a React/Vite UI hosted on the same domain, guarded by the same gateway, and served over the same scale-to-zero infrastructure as the agent it talks to.
Packed with the agentHosted on the same domainWired to the auth gatewayTalks to your agent's APITLS and scale-to-zero includedReceipts behind the chat
Packed with the agent
Drop a React or Vite app next to your agent and one deploy ships both. The UI travels with the agent as part of the whole agent app — no second repo, no second pipeline, no second host.
Hosted on the same domain
The frontend is served from the same domain as the agent's API, so there's no cross-origin dance, no separate CDN to configure, and no CORS you have to hand-tune.
Wired to the auth gateway
The UI authenticates through the same Keycloak-backed OpenAPI gateway that guards the agent. Users log in once; the frontend calls the agent under a scoped grant, not an exposed API key.
Talks to your agent's API
The frontend calls the agent through its OpenAPI gateway — the same authenticated endpoint any client uses. Your chat UI is just a first-class consumer of the agent's own API.
TLS and scale-to-zero included
TLS is terminated for you, and the frontend rides the same scale-to-zero infrastructure as the agent. No always-on web server to keep the UI online, no cert to renew.
Receipts behind the chat
Messages sent through the API, MCP, or /invoke entry point create signed evidence. Agent API evidence is persisted; public `/invoke` and standard MCP `tools/call` responses include gateway evidence.
side-by-side
Separate frontend deploy vs. a2a.
domain
two hosts, two deploys
Separate origins mean CORS config, cross-origin cookies, and a second DNS setup.
a2a cloud
Frontend and agent served from the same domain — no cross-origin plumbing.
auth
two hosts, two deploys
The UI holds an API key or its own auth, bolted onto the agent's separately.
a2a cloud
One Keycloak-backed gateway guards both; the UI calls under a scoped grant.
hosting
two hosts, two deploys
You keep a web server or static host running just to serve the chat UI.
a2a cloud
The frontend rides scale-to-zero with the agent — TLS included, idle costs nothing.
record
two hosts, two deploys
The chat sends requests; what the agent did behind each one is a mutable log.
a2a cloud
Covered Agent API, public `/invoke`, and standard MCP `tools/call` executions produce verifiable signed evidence.
dimension
two hosts, two deploys
a2a cloud
deploy
Agent on one host, frontend on Vercel/Netlify — two repos, two pipelines, two deploys.
React/Vite app packed with the agent — one deploy ships the whole agent app.
domain
Separate origins mean CORS config, cross-origin cookies, and a second DNS setup.
Frontend and agent served from the same domain — no cross-origin plumbing.
auth
The UI holds an API key or its own auth, bolted onto the agent's separately.
One Keycloak-backed gateway guards both; the UI calls under a scoped grant.
hosting
You keep a web server or static host running just to serve the chat UI.
The frontend rides scale-to-zero with the agent — TLS included, idle costs nothing.
record
The chat sends requests; what the agent did behind each one is a mutable log.
Covered Agent API, public `/invoke`, and standard MCP `tools/call` executions produce verifiable signed evidence.
questions
Frequently asked.
How do I give my AI agent a frontend?
On a2a cloud, put a React or Vite app alongside your agent and deploy once. The frontend is built and hosted on the same domain as the agent, wired to the same auth gateway, and served over TLS — so your agent ships with a hosted chat UI without a separate frontend deploy.
Can I host a chat UI for my agent without a separate deploy?
Yes. That's the point — the frontend is packed with the agent, so one deploy produces both the agent's API and its UI. There's no second repo, pipeline, or host, and no cross-origin configuration because the UI and API share a domain.
How does the frontend authenticate to the agent?
Through the same Keycloak-backed OpenAPI gateway that guards the agent. Users log in once and the frontend calls the agent under a scoped grant rather than an exposed API key, so the UI and the agent share one identity and authorization model.
What framework does the hosted frontend use?
A standard React/Vite frontend — you build the UI you want and a2a hosts it alongside the agent. The frontend simply calls the agent's OpenAPI gateway, so it's a first-class consumer of the same authenticated API any client would use.
Is there a record of what the agent did per chat message?
When the UI calls the API, MCP, or /invoke entry point, it receives an Ed25519-signed receipt covering caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. The Agent API, public `/invoke`, and standard MCP `tools/call` paths are covered; formal A2A task routes are not skill executions.
keep reading
Related guides.
All guides live in the guides index.
the whole agent app
Ship the agent and its UI together.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — with managed Postgres, MCP and API surfaces, and a frontend. The control plane signs authenticated Agent API calls; trusted ingress signs public /invoke and standard MCP tools/call executions. Connector MCP and formal A2A task routes are outside that coverage.