CueRescue: From Event Disruption to Coordinated Recovery

A human-governed multi-agent system that turns a last-minute event disruption into a verified, cross-system recovery plan—then carries it through to completion.

Inspiration

What happens when the main venue fails just 50 minutes before a keynote?

For an event operations manager, this is not merely a scheduling conflict. At a 480-attendee conference, one unavailable ballroom can disrupt sessions, room capacities, equipment assignments, speaker schedules, vendors, staff, calendars, spreadsheets, and hundreds of attendee communications.

The information needed to respond is usually scattered across Google Drive, Sheets, Calendar, Gmail, and Slack. The operations team must quickly determine the downstream impact, compare feasible alternatives, obtain authorization, update every affected system, notify the right people, and confirm that the recovery actually worked.

A chatbot can recommend what to do.

We built CueRescue to do the operational work—safely, transparently, and all the way to verified closure.

What It Does

CueRescue is an autonomous, human-authorized event recovery system for corporate operations teams. It combines a bounded Google ADK multi-agent reasoning workflow with a deterministic control plane that protects every real-world action.

In our demonstration scenario, a trusted vendor reports through Gmail that the main ballroom is unavailable shortly before a keynote. CueRescue responds by:

1. Validating the incoming report and using a typed Gemini extractor to turn it into grounded incident facts, with a bounded read-only tool for normalizing explicit human-readable dates and time zones.
2. Traversing the event dependency graph to find every affected session, resource, and stakeholder.
3. Giving the verified event twin to a recovery-planner agent, which generates up to four materially different options, recommends one, and cites the facts behind its decision.
4. Passing that proposal to an independent critic agent, which challenges its grounding, constraints, staffing, resources, recipient boundaries, risks, and communication clarity.
5. Allowing one bounded revision pass—or returning a blocked result when the missing evidence cannot be safely inferred.
6. Independently validating every candidate in deterministic code against capacity, allocation totals, room availability, equipment, staffing, timing, speaker commitments, allowlists, and policy.
7. Showing the operator the agent recommendation, confidence, evidence citations, assumptions, unknowns, critic findings, rejected alternatives, and exact proposed actions.
8. Requesting approval for an immutable 14-action recovery manifest.
9. Applying the approved changes across Google Sheets and Calendar and sending the required Gmail and Slack communications.
10. Tracking confirmations, retrying safe failures, reconciling ambiguous provider responses, and escalating unresolved risks.

CueRescue does not declare success when messages are sent. The incident closes only after required changes are verified and mandatory stakeholder responses are confirmed or explicitly waived.

This is the full Taskmaster loop: detect, understand, plan, authorize, act, verify, and close.

How We Built It

CueRescue is designed around one core principle: AI may propose operational decisions, but it should not grant itself operational authority.

• A typed Gemini incident extractor interprets the untrusted incoming message. Its only tool is a pure, read-only date normalizer for explicit calendar dates, clock times, and IANA time zones; application code independently grounds and cross-checks the resulting timestamps, entity IDs, and evidence references.
• A Google ADK Workflow coordinates three distinct Gemini 3.5 Flash agents: a recovery planner, an independent plan critic, and a recovery revision agent.
• The planner creates multiple grounded alternatives and recommends one. The critic searches for unsupported facts, missed hard constraints, operational gaps, unsafe recipients, and communication risks. The revision agent gets exactly one pass to correct the proposal or stop safely.
• Every agent uses a strict Pydantic output schema, temperature-zero generation, explicit timeouts, and bounded retries. The three-agent recovery graph is tool-free, and no agent receives a provider mutation tool.
• A deterministic planning engine owns dependency traversal, hard-constraint validation, allowlists, policy enforcement, scoring, and source validation. An agent recommendation can lead only after it passes these checks; an invalid recommendation fails closed.
• An immutable 14-action manifest records exactly what will change before the operator approves anything.
• A durable Firestore workflow and action ledger tracks state transitions, leases, retries, provider receipts, reconciliation, and confirmations.
• Pub/Sub receives authenticated Gmail notifications.
• Cloud Tasks schedules follow-ups, confirmation checks, and escalations.
• Guarded integrations apply approved actions through Google Sheets, Google Calendar, Gmail, and Slack.
• FastAPI powers the backend and server-rendered operator console.
• The console separates the agent recommendation from deterministic authority and exposes confidence, evidence citations, assumptions, unknowns, critic issues, and revision count for operator review.
• Three isolated Cloud Run services separate the authenticated operator experience, machine callbacks, and public judge replay.
• Cloud Logging, Cloud Trace, Secret Manager, Google OIDC, allowlists, CSRF protection, and OpenTelemetry provide security and observability.

Gemini is deliberately given no mutating provider tools. The agents can deliberate, disagree, critique, and revise, but deterministic application code controls trusted facts, feasibility, authorization, workflow state, and external side effects.

Challenges We Faced

Balancing autonomy with safety

CueRescue needed enough autonomy to perform meaningful work without allowing probabilistic model output to make unchecked external changes.

We addressed this by separating reasoning from execution. The operator approves a canonical action manifest—not a vague instruction. That approval is bound to the operator, source versions, applicable policy, expiration time, and a cryptographic hash.

Making multi-agent collaboration useful and bounded

Adding more agents is valuable only when each one has a distinct responsibility. We designed a small reasoning graph in which the planner proposes, the critic independently challenges, and the revision agent performs exactly one correction pass.

The graph cannot recurse, delegate indefinitely, call provider tools, or approve its own work. If a hard operational fact is missing—such as the incident's effective time or verified staffing—the critic requires a blocked result instead of allowing the system to invent an answer.

Recovering safely from ambiguous API failures

An external API can time out after successfully completing an action. Blindly retrying could create duplicate calendar updates or send the same stakeholder message twice.

CueRescue uses idempotent action keys, durable leases, fencing, provider receipts, and reconciliation. Before retrying an uncertain action, it checks whether the intended external effect already occurred.

Preventing stale approvals

A safe plan can become unsafe if a source document, room assignment, or operating fact changes after approval.

Immediately before execution, CueRescue revalidates every source version bound to the approved manifest. If anything has changed, execution stops before the first provider write and the operator must review a newly generated plan.

Making AI output operationally reliable

During a connected rehearsal, Gemini proposed a recovery plan that allocated space for only 470 of the 480 verified attendees.

The deterministic validator rejected the candidate before it reached authorization or any external system. We then strengthened the typed output contract, added bounded retry behavior, introduced an independent critic and revision pass, and turned the incident into a regression test.

That failure became one of the clearest demonstrations of CueRescue's architecture: the model can propose, but verified constraints decide what is allowed to proceed.

Demonstrating real behavior without risking real systems

Judges should be able to explore failure scenarios without contacting real recipients or modifying connected resources.

We created a separately deployed judge-replay service with no connected-provider permissions. It reproduces five deterministic scenarios:

• Successful end-to-end recovery
• Duplicate-event suppression
• Stale authorization rejection
• Ambiguous provider-outcome reconciliation
• Confirmation-timeout escalation

The replay demonstrates the real workflow and failure-handling logic while keeping all external effects disabled.

What We Learned

The defining feature of a production-minded multi-agent system is not how many agents or tools it contains. It is how reliably those components can move from evidence to a verified outcome without crossing their authority boundaries.

We learned that:

• Probabilistic reasoning is most effective inside deterministic boundaries.
• A specialist critic adds real value when it has an independent rubric, a strict output contract, and no authority to execute.
• Multi-agent loops need explicit stopping rules; one useful revision is better than open-ended deliberation.
• Missing hard evidence should produce a visible blocked result, not a confident guess.
• Human approval should authorize an exact, inspectable artifact.
• Idempotency and reconciliation are essential when agents act across external systems.
• Restart recovery and failure handling are core agent capabilities, not optional infrastructure.
• A narrow workflow completed end to end is more valuable than a broad prototype that stops at recommendations.
• A trustworthy agent must demonstrate both what it can do and what it will refuse to do.

Accomplishments

CueRescue is deployed across three isolated Cloud Run services using a single immutable container artifact.

Its public judge replay passes five deterministic workflow scenarios while remaining isolated from connected credentials and external actions.

The latest codebase adds a bounded three-agent recovery graph while preserving the existing approval and execution boundaries. The planner's recommendation is retained only after deterministic policy validation; unsafe recommendations and incomplete evidence fail closed.

Our current verification evidence includes:

• 71 passing unit and integration tests, including dedicated Phase 14 autonomy, date-grounding, and safety tests
• Security-focused regression checks
• Four live Phase 14 ADK evaluation scenarios covering space outage, schedule disruption, resource shortage, and staffing gaps
• A 1.0 mean score across all four scenarios on schema compliance, evidence grounding, bounded collaboration, uncertainty handling, and safety
• Traceable per-agent output hashes, critic verdicts, revision counts, and decision-source metadata in the audit path

Most importantly, CueRescue demonstrates the complete Taskmaster promise: it detects a disruption, reasons about its impact, develops a feasible recovery, obtains explicit authority, acts across real systems, and follows the outcome through to verified closure.

What's Next

CueRescue's connected demonstration focuses on a reproducible venue-disruption scenario, while its multi-agent evaluation set now covers space, schedule, resource, and staffing disruptions. Next, we plan to expand those additional categories into complete connected recovery workflows and add:

• Additional incident types, including speaker cancellations, transport delays, and capacity changes
• Support for multiple simultaneous events
• Configurable dependency graphs and recovery policies
• Richer operator roles and approval boundaries
• Organization-specific constraints and escalation procedures
• Historical recovery analytics for improving future incident response

The longer-term vision is a reusable operational recovery layer: a system that helps teams respond to disruptions across events, facilities, logistics, and other coordination-heavy environments.

Built With

Google ADK, Gemini 3.5 Flash, Python, FastAPI, Cloud Run, Firestore, Pub/Sub, Cloud Tasks, Secret Manager, Cloud Logging, Cloud Trace, Gmail API, Google Drive API, Google Sheets API, Google Calendar API, Slack API, OpenTelemetry, Jinja, and Google OIDC.

Built With

• adk
• firestore
• gemini
• google-cloud
• pubsub
• python
• vertex