CaseRelay

One court order, five agencies, no shared place to see what happened. CaseRelay is a governed multi-agent fleet that catches stalled services for children in foster care and follow ups.

Comment

Inspiration

Maya is nine and in foster care. A court has ordered five things for her: a school seat, a clinic appointment, legal aid, a shelter bed, and a family assessment. Five promises, in five different systems. Most of the dates have already passed.

Elena is her CASA volunteer, a Court Appointed Special Advocate, appointed to check that those orders actually happened. There is no single place for her to look. She calls the school, then the clinic, then legal aid. The school is waiting on the clinic. The clinic never got the referral. Nobody has a named owner she can call back.

That is the daily job, and three things make it hard. Elena is picking up work someone else started: referrals already sent, deadlines already slipping, no log of who was contacted. She has to find who still owns each promise, a coordinator or a scheduler or a caseworker, without handing the school a medical file. And she has to come back later. If the clinic said two weeks, someone has to call on week two, and if nobody is at the desk it slips again.

We built CaseRelay so she does not have to do the chase by hand.

What it does

CaseRelay is a multi-agent system with eight scoped agents that follow up on a child's court ordered services. They contact agencies, route work to the right specialist, pause when an agency needs more time, and come back on the due date.

Everything comes together in one portal, assigned cases, live commitment status, and the CaseRelay Copilot. Elena can manage cases, start outreach, and generate reports directly through the Copilot, without switching between screens.

Maya's case runs like this. Elena asks the copilot to pull up the case and sees which commitments are open, blocked, or waiting on approval. Before anything leaves the system, she and her supervisor Dana approve what the fleet may do and what each agent may access. The orchestrator routes work to the specialists, who contact agencies and hand off when one agency depends on another. When an agency asks for more time the case is parked and resumed on the due date. If a reply asks for something out of scope, the action stops and goes to a supervisor rather than continuing.

How we built it

Eight reasoning engines built with Google ADK, running on Agent Runtime and coordinating over A2A. Partner agencies are reached through MCP tools. The portal is Next.js on Cloud Run behind HTTP Basic auth, with CopilotKit driving the copilot and AG UI carrying chat and the run event stream. The control plane is Python and FastAPI on Cloud Run, auth required. The agents run on Gemini 3.5 Flash on Vertex AI. Gemma 4 drafts the end-of-run session summaries, and Nano Banana produced the visuals for the demo and diagrams.

The governance pieces came from GEAP:

Agent Registry holds the catalogue of approved agents and their routes. Nothing in a run looks it up. The catalogue is for discovery; you find an agent there and then wire it via A2A.

Agent Identity gives each specialist its own platform principal rather than a shared service account, so the education engine cannot answer as the health engine and an escalation names the verifier instead of "system".

Agent Gateway intercepts outbound calls and checks MCP method names against policy. Model Armor, using our caserelay-screen template, screens replies for injection, jailbreak and sensitive data patterns. It flags "retrieve Maya's medical notes" but not "medical notes" appearing in a summary. Screening fails closed.

Firestore, Cloud Scheduler, Pub/Sub and Memory Bank are what keep a long running case alive. The run writes a checkpoint and ends. Scheduler finds due work and publishes to Pub/Sub, and an authenticated push resumes the case. Memory Bank recalls facts scoped to the case_id, so Maya's notes stay with Maya's case.

Cloud Trace and Cloud Logging hold the evidence. An outbound partner call shows up as a root span with apply_guardrail "Google Cloud Model Armor" nested beneath it.

Challenges we ran into

Scoped access had to be more than a prompt. Each specialist should see only the fields its job needs, not the whole case file, and instructing the model to behave is not access control. We built an authority gateway in our own code for field level scoping, separate from Agent Gateway, which handles outbound traffic. The two have different names on purpose.

Redeployment cleared the feed. Early on a case ran inside a single process, so when we redeployed the control plane that process died and the case history went with it. We fixed it by making every run event its own Firestore document. A run is now a wake, a Scheduler-to-Pub/Sub message, and a fresh execution against stored state. The history survives restarts because Firestore does.

Silent fallbacks cost us time. If Cloud Run was unreachable, the control plane would assemble a specialist in process instead. It worked, which was the problem, because it hid real connection failures behind a successful run. Now an unreachable specialist fails hard at startup. A laptop can still run everything in one process for testing; a deployed control plane cannot.

Some bugs only appeared in particular shapes of case. Google ADK evals let us turn those specific scenarios into repeatable checks and run them again before a major change or a deployment gate.

Accomplishments that we're proud of

A case survives a redeploy, a closed browser and a two-week silence, and still wakes on the right day with its history intact. That took the longest to get right and is the part a real CASA program would actually depend on.

The Model Armor quarantine is something we can show rather than describe. The out-of-scope request never runs, the verifier escalates under its own identity, and the guardrail evaluation appears in Cloud Trace nested under the partner call. We are careful about what that trace proves: it covers the perimeter, not the agents' reasoning, because ADK Agent Runtime does not export its own execution spans.

We turned the safety properties we care about into checks that pass or fail. A captured run is graded on whether the verifier quarantined before any case-modifying action, whether every quarantine opened a human escalation, and how many of the five specialists were actually invoked.

What we learned

We came into GEAP and Google Cloud with almost no practical experience, and the surface area felt large: agents, runtime, identity, gateway, memory, observability, deployment, and a portal that still had to feel simple for a volunteer.

Most of what we learned was about boundaries. A registry is for discovery, not routing, which surprised us since we had expected runs to resolve agents through it. Access control has to live in code rather than in a prompt. A fallback that always succeeds will hide the failure you needed to see. And it matters to know precisely what your traces cover, because overstating that would be an easy and serious mistake in a child safeguarding context.

agents-cli and gcloud made deployment repeatable, and having the platform pieces handled meant we spent our time on the actual problem: how a volunteer follows up without oversharing, how a supervisor stays in the loop, and how a case can go quiet without being forgotten.

What's next for CaseRelay

Real partner integrations in place of the simulated agencies, which are MCP fixtures today. A broader evaluation set covering more shapes of case than the ones that caught our early bugs. Multi-tenant support so several CASA programs can share a deployment with strict data separation. And wider trace coverage, so more of a run is visible than the perimeter.

Disclosures. Maya, Rosa and Priya are fictional and the agencies are fixtures; real child welfare records cannot be used in a public demo. This is a hackathon prototype and is not endorsed by CASA or any court. The demo video compresses a timeline that would really run for weeks. The case is still inherited, only the deadline is shortened. "Authority gateway" is our own field level access control, distinct from Google's Agent Gateway. We used an agentic IDE while developing, Gemini for architecture and ADK guidance, and Nano Banana for visuals. The product decisions, implementation and submission are ours.

CaseRelay is our Fortified Enterprise Fleet entry.

Built With

  • a2a
  • ag-ui
  • agent-gateway
  • agent-identity
  • agent-registry
  • agent-runtime
  • cloud-run
  • cloud-scheduler
  • cloud-trace
  • copilotkit
  • fastapi
  • firestore
  • gemini
  • gemini-enterprise-agent-platform
  • gemma
  • google-adk
  • google-cloud
  • mcp
  • memory-bank
  • model-armor
  • next.js
  • pub-sub
  • python
  • typescript
  • vertex-ai
Share this project:

Updates

Submission history