Multi-agent systems, simulated
Watch agents triage a service desk, and see where they're not trusted.
Requests come into the fictional Northwind Health Data Platform's service desk. A router agent picks a specialist, the specialist calls tools, and guardrails, a policy gate and a human reviewer decide what's actually allowed to happen. Pick a scenario and watch the trace, or type your own request.
This is a simulation of the architecture, not a live LLM. Routing and agent "reasoning" are rule-based, and latencies and failures come from a seeded generator, so a scenario plays the same way every time. All people, datasets and tickets are made up. Nothing leaves your browser.
Simulator
Architecture
The highlighted box is working on the current event. Dashed tools write; every write passes the write gate first.
Edit the text or the requester to make it your own request. Typed requests also get the occasional random tool failure (seeded by the text, so still repeatable).
Human review
Nothing waiting. Low-confidence routes, high-risk writes and restricted data stop here for you to decide.
Reply to requester
Appears when the run finishes.
Trace
Timestamps are simulated time since intake. Open a row for the reason or the JSON.
How this maps to a real build
The pattern is the one I'd build with Google's Agent Development Kit (ADK) in Python. Here's what each piece on the page would be in that setup.
-
Agents
The router is a coordinator
LlmAgentwith the three specialists assub_agents. It hands off by transferring control, and each specialist has its own short instructions and only its own tools. -
Tools
Plain Python functions with type hints and docstrings; ADK turns them into function tools. Reads and writes are kept apart, and write tools take an idempotency key so a retry can't open a second ticket.
-
Guardrails as callbacks
Redaction and injection screening run in a
before_model_callback, so the model only ever sees cleaned text. The write gate is abefore_tool_callback: it can refuse a call outright, and it re-checks policy in code instead of trusting what the model concluded. -
Sessions and human approval
A session service stores the conversation and its state, so a run can stop for an approval and pick up later. The approval step is a long-running tool that waits on the reviewer's answer, then the run resumes from the session.
-
Cloud Run and the ITSM
The agent runs as a Cloud Run service. The ITSM (ServiceNow or similar) calls it from a webhook when a request is filed; the agent writes back through the ITSM's REST API. A queue in between handles bursts and retries.
-
What production adds
Eval sets that check routing and tool sequences on every change. OpenTelemetry traces (this page's trace panel, for real). An append-only audit log of every decision and approval. One least-privilege service account per tool, with secrets in Secret Manager.
What's simulated, and what a real system needs
| Piece | In this demo | In a real system |
|---|---|---|
| Router | Weighted phrase matching; confidence from how much signal there is and how one-sided it is | An LLM classifier with examples, measured against a labelled eval set, with the threshold tuned on real traffic |
| Agent reasoning | Scripted plans with a written rationale per step | Model-planned tool calls, constrained by instructions, the tool list and the callbacks |
| Tools | In-memory catalog, directory and ticketing, with seeded latency, timeouts and malformed replies | Real APIs behind service accounts, with timeouts, retries and circuit breakers |
| Guardrails | Regex PII redaction and pattern-based injection screening | A DLP service for PII, a classifier for injection, plus the same deterministic write gate |
| Policy | Eight ordered attribute rules in JavaScript | A policy engine (for example OPA) fed by the identity provider and the data catalog's tags |
| Tokens and latency | Estimated from text length; a simulated clock | Measured per call, with budgets and alerts |
| Time to completion | Agent latency plus a flat 3 days for each human step (an approval or a handoff to a person) | Measured from ticket open to close in the ITSM, so you can see where requests actually wait |
The engine is separate from the page and has its own tests. Read it in js/engine/.