LiteLLM + Microsandbox: A2A Cloud Turns Ideas Into Deployed Agents — Fast

LiteLLM + Microsandbox: A2A Cloud Turns Ideas Into Deployed Agents — Fast

A2A Cloud isn't hosting agents. We're building the runtime loop that turns an idea into a live, callable service — in minutes.

The pitch is dead simple: describe the agent you want. Agent Builder writes the project, tests it, packages it, deploys it, and hands you a public URL. That's the whole experience.

Under the hood, two platform layers do the heavy lifting:

• LiteLLM — the model gateway every agent hits through ctx.llm.
• Microsandbox — the isolated execution layer where generated code actually runs.

Together they let agents reason, write files, run commands, validate themselves, and ship through GitOps — without ever handing raw infrastructure to a builder. This is the platform agents have been waiting for.

The Product Experience

Direct. Fast. No ceremony.

You ask Agent Builder for a new agent. It fires up a DeepAgents build loop, writes source into your workspace, validates it in a sandbox, and ships it through the control plane. Done.

Here's what happens — live, every time:

1. agent-builder.build takes a name and a natural-language prompt.
2. The platform hands over a scoped workspace bucket, LLM credentials, and a user-scoped control-plane JWT.
3. The builder writes a real A2A Pack project under agents/<name>/.
4. It can drop DeepAgents skill bundles into skills/<skill-name>/SKILL.md.
5. It tarballs the project and runs it in microsandbox with a2a card.
6. It uploads the tarball to /v1/agents/from-tarball.
7. The control plane commits to managed Gitea, wires ArgoCD, and kicks off deployment.
8. The builder polls the live /.well-known/agent-card until the new version is actually serving.

That's the story: A2A Cloud is an agent factory, not a blank Kubernetes cluster. You ship products, not yaml.

LiteLLM: One Model Layer To Rule Them All

Agent code never hard-codes provider keys. It never learns five provider APIs. It just reads ctx.llm. That's it.

That one clean interface lets the platform decide *how* model access works for each invocation. The runtime supports every mode that matters:

• Platform-provided model access.
• Caller-provided credentials.
• Platform-or-caller fallback for trusted platform agents.
• Agent BYOK through per-agent runtime env vars.

For builders this is huge. Agent Builder uses caller-selected LLM creds when present, or falls back to a scoped platform LiteLLM grant so it just works out of the box.

For deployed agents, same deal. The agent declares its LLM mode on the card. The platform forwards the right credentials at invoke time. Skill code keeps using ctx.llm. Zero rewrites.

This is what makes a real marketplace possible — hosted agents, user-paid model calls, author-owned keys, all backed by the same runtime.

Scoped Model Access — Loose Keys Need Not Apply

The platform path is built so agents never see raw provider keys.

At handoff, platform-capable agents receive a signed grant as their LiteLLM bearer token. The handoff code forwards it through the invoke body as llm_creds. The runtime exposes it through ctx.llm, and LiteLLM enforces the platform's routing and grant policy.

The controls are already in place for serious usage: platform model list, max budget, request limits, token limits, LiteLLM gateway URL. The whole policy surface lives in one place.

This is the LiteLLM advantage. It's not "call an LLM." It's model access with routing, policy, billing paths, and observability hooks — all evolvable centrally. That's a platform.

Microsandbox: Where Agents Actually Do Work

Real agents need to *do things*. Generate files. Inspect APIs. Run validators. Install deps. Render assets. Test outputs.

Microsandbox is where that work happens — safely, isolated, fast.

The A2A Pack runtime exposes sandbox execution through ctx.sandbox, never through a raw SDK. That matters because the platform owns the policy layer: workspace selection, write boundaries, resource budgets, audit behavior, runtime environment.

The sandbox API covers everything real agents need:

• run_shell for arbitrary shell pipelines.
• run_python for fast Python execution.
• Explicit command execution with args.
• Custom OCI images — Python, Node, Rust, tool-specific images.
• CPU and memory hints per sandbox.
• A workspace mounted at /workspace.

Builders get to test generated code before it ships. Operators get that test happening *outside* the main control-plane process. Everybody wins.

Workspaces That Stay Inside The Grant

A2A Cloud workspaces are durable and scoped. Period.

Agent Builder asks for a read/write overlay grant locked to agents/{name}/**. It writes generated files through the workspace backend. The sandbox gets the same workspace context, so commands that produce files write under /workspace and the outputs persist back to the caller's workspace.

This is one of the most important platform details we ship.

A generated agent isn't writing across the host filesystem. It's working inside a grant, against a known bucket, with explicit write prefixes and a time-bound permission model.

That's how we let agents create real artifacts without turning the platform into a pile of privileged containers. Power *and* safety. Yes, both.

The Agent Builder Loop — Product-Grade, Today

The real Agent Builder loop is already production muscle.

It starts from the installed A2A Pack template, so new agents inherit current runtime conventions. It writes agent.py, a2a.yaml, requirements.txt, optional packed frontend files, and optional DeepAgents skill bundles. It reads back what it wrote, reviews the file tree, patches as it goes.

Before deployment, it runs test_agent_in_sandbox. That test bundles the workspace project, starts a sandbox, installs the current a2a-pack wheel, installs project requirements, and runs a2a card to verify the agent exposes a valid card. Packed frontend declared? It checks frontend metadata too. Nothing ships unverified.

Then cp_deploy_tarball uploads the source to the control plane as the user. The control plane creates or updates the managed source repo, wires the Argo application, records deployment events, and lets the GitOps build-and-rollout path take over.

And the builder doesn't just say "done" after upload. It polls the live agent card until the deployed version and skills are actually visible and callable.

That's the gap between code generation and agent delivery. We deliver.

Why This Sells

This architecture lets A2A Cloud promise something way stronger than "bring us a container."

We give users the full build-to-runtime path:

• Describe an agent in plain language.
• Generate a real A2A Pack project.
• Use the platform model gateway through ctx.llm.
• Write files into a scoped, durable workspace.
• Test generated code in microsandbox.
• Deploy through managed Gitea and Argo.
• Serve through the live A2A runtime.
• Expose skills through the agent card.
• Prove the deployed version is actually callable.

That's a marketplace-grade workflow. It crushes the builder's burden while raising the operational bar. Both at once.

Better For Builders. Better For Buyers.

Builders don't want to wire LLM providers, object storage, sandboxes, Git repos, CI, Argo, Knative, and public URLs before they can ship a useful agent. Nobody wants that.

A2A Cloud packages all of it into one platform loop.

Buyers win too. They inspect an agent card, see declared skills, run proofs, and trust the agent came through a controlled deployment path — not some opaque script someone ran from a laptop.

LiteLLM makes model access portable and governable. Microsandbox makes execution powerful without being reckless. Workspaces make outputs durable. GitOps makes deployments repeatable.

That stack is what turns agents into products.

The Platform Direction

A2A Cloud is becoming the fastest way to create, test, deploy, and operate production-grade agents. Full stop.

LiteLLM gives every agent a clean model gateway. Microsandbox gives every agent a safe execution surface. A2A Pack gives every agent a standard contract. Argo and Knative give every agent a real deployment path.

The result: a platform where agents do more than answer questions. They build. They validate. They produce artifacts. They call other agents. They ship as real services.

That's the bigger story. A2A Cloud is turning agent development into an operating platform — with the model layer and execution layer built in from day one. The future of agents ships here.