Orrery Studio Part 1: A Visual Builder for Multi-Agent AI Systems

Status, October 2026: Orrery Studio is a preview in Orrery 0.10.0. It is off by default, open to human admins only, and runs in the Tirraflow lab. It is not open to readers yet. This series explains how it works today and says plainly what isn't built.

Orrery Studio is a visual builder for multi-agent AI systems that uses MCP for tools and the A2A protocol for remote agents. You place LLM agents, MCP servers and remote A2A agents on a canvas, wire them into a pattern such as a pipeline, a router or a critic loop, run it, and watch every step live. This first part shows what it is, how a run works, and where the project stands.

Why Build a Multi-Agent Sandbox?

Orrery is my open-source platform for running AI agents in DevOps, built on Google's Agent Development Kit (ADK). It already had the parts of a multi-agent runtime: specialists, a hardened MCP client, run budgets and a live trace. What it lacked was a way to compose them without writing Python. Three questions kept coming back:

How do MCP and A2A actually behave? Reading the specs is one thing. Watching a remote agent's task come back completed, or stop to ask a question, is another.
Is this third-party agent or MCP server safe to use? You want to try it somewhere it can't change the live system.
Which pattern works better here? Running a pipeline and a critic loop on the same input, side by side, answers that faster than an argument.

The Studio answers all three: a sandbox where an admin builds a composition, runs it apart from the live agents, and sees everything it does.

A Composition Is Just Data

What you draw on the canvas is saved as a small JSON spec: nodes, edges and budgets. Here is the release-notes demo that ships with Orrery (deploy/studio-demo/specs/critic-loop.json), shortened:

{
  "spec_version": 1,
  "name": "release-notes",
  "pattern": "critic_loop",
  "budgets": { "max_tokens": 120000, "max_remote_calls": 4, "timeout_s": 240 },
  "nodes": [
    { "id": "research", "kind": "llm_agent",
      "tools": ["mcp:tirraflow.search_articles", "mcp:tirraflow.get_article"] },
    { "id": "writer", "kind": "llm_agent", "tools": ["a2a:demo-writer.draft"] },
    { "id": "critic", "kind": "llm_agent", "output": { "labels": ["approved", "rejected"] } }
  ],
  "edges": [
    { "from": "research", "to": "writer" },
    { "from": "writer", "to": "critic" },
    { "from": "critic", "to": "writer", "when": "rejected", "max_iterations": 3 }
  ]
}

Notice what is not there: no code, no Python import paths, no URLs. Tools are named by reference: mcp: for an MCP server, a2a: for a remote agent, catalog: for Orrery's own read-only tools. Each reference must point at an entry the operator registered. That is a deliberate choice. Google ADK's own declarative format loads models and tools through Python import paths, so an API that accepted it would accept arbitrary code.

Orrery Studio canvas showing a research, writer and critic pipeline, with the writer node's inspector listing its A2A tool

Screenshots in this series show the real 0.10.0 console, filled with sample data.

How a Studio Run Works

How an Orrery Studio run works: the console posts a JSON spec, Orrery checks the caller and validates and compiles the spec into an ADK workflow, runs it on its own gateway at L2, and streams trace events back

When you press Run:

Who is asking? Only a human admin may run the Studio. A service token that happens to carry the admin role gets a 403.
Validate. At most 30 nodes, every loop capped, budgets within the deployment's ceilings, every tool registered. Errors point at the exact node and field, before any model is called.
Compile. The spec becomes one Google ADK 2.x Workflow. Each agent node is built through Orrery's normal create_agent(), so every guard and plugin applies.
Run on its own. Each run gets its own runner, a fresh set of plugins (the guards around every model and tool call), an in-memory session and autonomy capped at L2, which means reads only. It never changes the live agents, the catalog settings or anyone's chat history. It is separate, not isolated: its catalog: tools read the real systems, which is exactly why runs are read-only.
Stream the trace. Server-sent events report each node entering and leaving, routes taken, loop rounds, MCP calls, A2A messages and token totals.

One ledger, a running count, covers the whole run: tokens, tool calls, remote calls, delegations and a deadline. Whichever runs out first ends the run with a clear budget.hit event.

Where the Project Stands

Orrery Studio roadmap: P0a API, P0b patterns and P1 console are built; P0c human approval, P2 publishing and evals, and P3 opening to readers are still to come

Three phases are built and released in Orrery 0.10.0:

P0a, the API: runs from a spec, MCP and A2A as tools, the run ledger and the live trace.
P0b, patterns: routers, capped loops, parallel branches, supervisors, a model per node, saved compositions and run history.
P1, the console: the canvas, templates, the run panel, A2A and MCP inspectors, and comparing two runs.

Two gaps are worth knowing about, because the 0.10.0 console was built before P0b landed:

Patterns. The server runs eight patterns, but the console still treats only the pipeline as ready. Its other templates are marked "needs P0b" and can't be opened. Import one of the tested specs from deploy/studio-demo/specs/ instead: the console shows warnings, and Run anyway runs it on the server. The gallery's "handoff" template is the exception; the server refuses that pattern.
Saving. Stored compositions and run history exist in the API, with PostgreSQL, but the console doesn't use them yet. A composition lives in the browser tab until you export it as JSON.

P0a, P0b and so on are the phase names from the design document. Still to come: a human approval step and remote agents that are allowed to act (P0c), publishing a composition as its own A2A agent and scoring patterns with eval sets (P2), and finally opening it to readers, each in an isolated runner (P3).

In the Tirraflow lab it runs with one MCP server (Tirraflow's own), one demo A2A agent and Claude Haiku 5.5 for every node. There's no database there, so the server keeps finished runs in memory for an hour and loses them on a restart.

What This Series Covers

This part: what the Studio is and where it stands.
MCP vs A2A: when an agent needs a tool and when it needs a peer.
How the A2A protocol works: agent cards, tasks, and calling a remote agent safely.
MCP server security: connecting servers you don't control.
Multi-agent workflow patterns on the canvas, and the rules that keep them bounded.
Self-hosting it with Docker Compose, and what we fixed on day one.

The code is open source in the Orrery repository, and the design is written up as AEP-031. Next: Part 2, MCP vs A2A.