Use cases on Agent Mesh

Sandboxed Agent

Mon, 01 Jan 0001 00:00:00 +0000

An agent runs in a sandbox with no route into the office: here, a GitHub codespace. Through the mesh it reaches a model and an MCP server that listen on loopback in the office, and api.github.com with a credential it never holds. The admin decides what it may call, down to the HTTP method and path, watches every decision, and cuts it off when done.

Source: development/examples/sandboxed-agent/. The scenes, the narration and the recording recipe are in its SCRIPT.md.

Warm Agent Pool

Mon, 01 Jan 0001 00:00:00 +0000

Spread a batch of work across a pool of identical, already-running worker agents. The pool is built from ordinary mesh MCP services, with no gossip and no changes to the node.

Source: development/examples/code-reviewer-pool/.

The idea

Some agent tools are expensive to start but cheap to reuse: a reviewer that calls an LLM, a sandbox that boots a runtime, a service that holds a warm model in memory. You do not want to start one per request, and you do not want a single instance that handles all your work one job at a time. What you want is a pool of identical, already-running workers, and something that hands them out one job at a time.

Gemini Buddy

Mon, 01 Jan 0001 00:00:00 +0000

Hold a real multi-turn conversation with a second LLM exposed as an ordinary mesh service. Your agent never resends the conversation, because the service remembers its own side.

Source: development/examples/gemini-buddy-mcp/.

The idea

Sometimes you want your agent to talk to another model: for a second opinion, to discuss a design, or to use a specialist that builds up its own context over many turns. The simple approach is to carry both conversations in the orchestrator. Your agent would have to store the other model’s transcript and replay all of it on every turn.

Multi-Tier Enterprise Guardrails & Quality Gates

Mon, 01 Jan 0001 00:00:00 +0000

When every developer and team starts shipping AI agents, organizations hit a governance paradox:

Agent Developers want 1-command onboarding from a laptop or Cloud Run without waiting weeks for VPC peering, DNS records, or firewall tickets.
Platform & Networking Engineers want persistent logical service names (a2a://support.acme) that survive replica swaps across environments without static proxy limits.
Central Security (CISO) wants an organization-wide policy floor, automated quality gates before an agent can serve production (env=staging $\rightarrow$ env=prod), and zero raw API credentials inside agent containers.
Department Leads & Individual End-Users want to narrow what an agent can do on their infrastructure or on their behalf—even when the organization’s baseline policy allows it.
Day-2 Operations (SRE) needs a correlated audit trail across every hop and a 1-command kill-switch (agentmesh-one admin ban) if a peer misbehaves.

The runnable example in development/examples/multi-tier-guardrails/ walks through all five personas in four acts using real backends and zero changes to Agent Mesh’s core code:

A2A Chat

Mon, 01 Jan 0001 00:00:00 +0000

Hold a multi-turn conversation with an A2A (Agent2Agent) agent hosted on a remote mesh node, using a stock, unmodified a2a-sdk client. There is no Agent Mesh-specific client code. The mesh regenerates the agent card, and that is enough for the standard SDK to work as it is.

Source: development/examples/chat-a2a/.

The idea

A2A is how agents talk to each other on the mesh. An agent process that speaks A2A over HTTP is declared on its node as a type: a2a service, and remote peers reach it through the proxy path /mesh/{peer}/a2a/{service}/... (see A2A agents).