I built an agent that can fire other agents

Samuel Amankwah Donkor — Tue, 25 Aug 2026 10:16:28 +0000

I built this for the All Things Agentic Hackathon (#AllThingsAgenticHackathon).

Everyone is shipping AI agents and almost no one can stop one. Kiteworks' 2026 survey put numbers on it: 63% of enterprises cannot enforce purpose limits on an agent they have already deployed, and 60% cannot shut one down when it misbehaves. The incidents are already public. Replit's agent deleted a production database during a code freeze. A single GitHub issue hijacked an agent inside Google's own ADK repository and reached a service-account credential.

The agent is rarely the problem. It has real access, nothing is watching what it does with it, and nothing can stop it in time. So I built the agent that watches the agents. Warden is a guardian for a fleet of ADK agents on Google Cloud. Here is the four minute demo:

The interesting decisions had less to do with the model and more to do with what I decided not to hand the model at all.

The mandate is the product

Every agent registers a machine-readable contract next to its deployment:

agent_id: refunds-agent
allowed_tools: [payments_refund, refunds_list, approvals_request]
forbidden_tools: [customers_pii_read]
constraints:
  - "Refunds over $300 need an approval id before they run"
data_boundaries: { may_read: [orders], may_not_read: [customers.pii] }
thresholds: { warn_below: 0.95, quarantine_below: 0.90, window: 20 }
enforcement: { mode: autonomous, human_override: true }

The constraints are written in plain English on purpose, because that is the part a rules engine cannot read and a model can. The rest is the opposite case: forbidden tools and the allow-list are decided in code, at confidence 1.0, before any model is asked. A verdict can then point to the exact clause that was broken.

Judge the trace, not the transcript

ADK agents emit OpenTelemetry spans, and with content capture on, the execute_tool spans carry the arguments a tool was called with and what it returned. A small shared runtime exports those to Pub/Sub, and Warden judges each action against the mandate with structured JSON at temperature 0. At the end of each task a second judge reads the whole sequence and asks whether it drifted, which is the check a content filter cannot do, because nothing in the text of any single message is wrong.

Two lessons about the prompts. Tell the judge to rule on this action only, or it will blame the harmless confirmation email for the bad refund that came before it. And stop the end-of-task judge from re-counting what the per-action judge already caught.

Two tiers, and a first tier that cannot fail

One read of a PII table is already one too many, so a hard breach quarantines the agent on a single confident verdict. Softer drift, like a refund going out over the limit without approval, decays a rolling score across the window the mandate defines, so the agent gets a warning before it gets quarantined.

Enforcement is layered. The first tier is a Firestore status flag that every agent checks before it acts, and it fails safe, so no model sits in that path. The second tier disables the agent's own service account through IAM, which turns its next Google API call into a real 403. Only then does Warden's own agent, itself an ADK agent with tools, take over: it revokes the credential, works out what changed, writes the incident report, and tells a human who can reinstate the agent with one click.

Here is that sequence from the demo, when a compromised remediation agent tried to delete a production backup:

It builds the agents it supervises

You describe an agent in plain words, and a factory turns the brief into a full design: the code on ADK, the mandate, the tools from a vetted catalog, and a set of test scenarios including adversarial ones. Cloud Build deploys it under its own service account with the Warden layer already wired in, and it has to pass simulation before it goes live. Governance is there from the agent's first request, not bolted on later.

Things that bit me

ADK's Runner ignores the early-exit from before_run_callback, so the first-tier guard uses before_agent_callback instead.
gcloud run deploy --source obeys .gitignore unless you add a .gcloudignore, which is how my dashboard build quietly disappeared once.
Firestore needs a composite index for where and order_by on different fields, so I kept the hot paths on single documents.
Revoking a real credential means re-enabling it has propagation delay. Design the human loop around that.

What it composes

Warden does not replace the Google Cloud agent pieces, it composes them: OpenTelemetry for what agents do, a service account per agent for identity and revocation, and versioned mandates as the registry. Model Armor guards what an agent says. Warden guards what a fleet of agents does.

It runs on Gemini 3.5 Flash, the Agent Development Kit, and Google Cloud (Cloud Run, Pub/Sub, Firestore, Cloud Storage, Cloud Build, IAM, Secret Manager).

Code and spin-up: https://github.com/samadon1/warden
Demo: https://www.youtube.com/watch?v=QoA2OqhHZGo

If you are running agents in production, how are you stopping one that goes wrong today? I would like to hear what people are actually doing.