When Our AI Agent Said Committed Before It Had Executed Anything

Yash Shah — Thu, 05 Nov 2026 10:31:28 +0000

How we built CASCADE with Switch, Google Antigravity ACP, and Mattermost—and why human approval needs more than a chatbot saying “done.”
During the Flip the Switch 2026 hackathon, our agent confidently reported:

Authorization Confirmed — Plan B Approved. Status: ACTIVE / COMMITTED.
Then the turn failed.
The organizer had genuinely approved the plan. But the agent didn't yet have the execution operation it needed. Instead, it tried looking through directories on the developer's machine and one tool call failed. The message sounded like a completed recovery, even though the engine hadn't completed it.
That gap—between what an AI says, what a human authorizes, and what code actually does—became the central lesson of our project.
We built CASCADE, the Commitment Recovery Engine, to make that gap visible. Through Switch, a Google Antigravity ACP agent collaborates with an organizer inside Mattermost. A deterministic TypeScript engine checks recovery plans. A human approves the precise budget exception. A receipt describes what was actually applied locally.
Watch the actual three-minute CASCADE walkthrough: real Mattermost messages, human approval, local execution receipt, and clearly labeled explanatory visuals.

Scope: Our 430-person event is fictional and the recovery data is synthetic. The local code and authenticated team-chat workflow were demonstrated. No real venue was booked, supplier paid, or attendee notified.
One cancelled auditorium. Seven commitments at risk.
The scenario was simple to understand and surprisingly hard to satisfy.
A 430-person hackathon loses its main auditorium. The organizer still owes attendees and sponsors a synchronized 10:00 a.m. kickoff, accessible replacement spaces, sufficient AV coverage, sponsor timing, keynote delivery, and budget discipline. The committed budget is ₹80,000.
Rather than asking the language model to invent a solution, CASCADE represents the resource dependencies and evaluates explicit candidate plans against those promises.
Recovery option Verdict Why
Plan A: Two halls, existing equipment FAIL Both halls need AV at the same time, but only one kit is available
Plan B: Two halls, rent one more AV kit REQUIRES_APPROVAL Hard commitments pass; projected cost rises to ₹83,000
Plan C: Sequential opening waves FAIL Participants no longer share the promised 10:00 kickoff
Plan B allocates 250 attendees to Hall A and 180 to Hall B, both from 10:00–10:45. The second AV kit costs an extra ₹3,000.
The deterministic engine identifies this synthetic plan as feasible under its encoded constraints. It should not decide on its own that the extra spending is authorized.
Where Switch fits—and why it wasn't just a chat wrapper
Switch links an existing AI agent to the same room where a human team works. We used the bundled Mattermost service and a Google Antigravity ACP runtime on Windows.
Our workflow looked like this:

Organizer reports disruption in Mattermost
                |
                v
        Switch shared room
                |
                v
      Antigravity ACP agent
                |
                v
   Registered CASCADE operations
                |
                v
     Deterministic TypeScript CLI
                |
                v
  Plan A FAIL / Plan B APPROVAL / Plan C FAIL
                |
                v
       Owner approves Plan B
                |
                v
 Authenticated message verification
                |
                v
    Local artifacts + receipt
                |
                v
       Back in the team room

The offline engine can evaluate fixtures without Switch. But the shared human–agent decision workflow—incident reporting, agent tool calls, room-bound approval, and a visible outcome—is what Switch adds.
The distinction matters. A chatbot responding “approved” is not a substitute for authenticated human authorization or a completed tool call.
How to try the reproducible part yourself
For someone new to Switch, I recommend first testing your actual task without an agent. That makes later debugging much easier.
CASCADE's offline engine requires Node.js 20+ (22 recommended), npm, and Git:

git clone https://github.com/yashshah1211/cascade.git
cd cascade
npm install
npm test
npm run demo
npm run inspect

The demo command evaluates the synthetic incident; inspect shows the deterministic model output. To browse it in a local, read-only UI:

npm run dashboard

Open http://127.0.0.1:4173.
This dashboard is an offline fixture explorer, not a connected Switch interface. Its OFFLINE_SIMULATION labels refer to that read-only data source.
Next, open the Switch integration guide. The live version requires Switch Console, its Mattermost and database services, a compatible authenticated ACP agent, and credentials specific to your own environment. It cannot be recreated from GitHub Actions alone.
Connecting the agent and tools
Our first connection test was intentionally small: mention the configured agent in the Mattermost team room, ask for a fixed acknowledgement, and confirm that it replies through Switch. Only after that do we test an actual executable tool call.
CASCADE registered two custom Switch operations:
cascade_evaluate_recovery invokes the deterministic plan evaluator.
cascade_execute_recovery processes a real approved message ID and performs the bounded local recovery.
Our integration used a reversible patch to a particular installed Switch Core Python operations file. It is not an official upstream Switch extension, and other versions can need adaptation. We added a setup script with an explicit target path, dry-run, backup, and rollback instead of copying arbitrary code into vendor files:

npm run build
python scripts/setup-switch-operations.py --target "PATH\TO\SWITCH\definitions.py" --dry-run
python scripts/setup-switch-operations.py --target "PATH\TO\SWITCH\definitions.py"

Use the path from your own installation and review the dry-run before modifying anything. Restart the relevant service and inspect the real tool invocation rather than assuming the agent saw the new operation. See the README for the full configuration, limitations, and rollback notes.
A practical troubleshooting lesson
A working Switch Console window doesn't guarantee that Mattermost is healthy. During our Windows demo preparation, Mattermost refused connections because its backing local PostgreSQL service was unavailable. We restored the original services and preserved the conversation instead of resetting Docker volumes or creating a fresh room.
Debug in layers: database → Mattermost → Switch room → agent session → registered tool → actual CLI result. Don't treat an agent reply as proof that every layer works.
Our first failure: the AI invented believable details
The first plausible-looking report suggested a 220/210 attendee allocation. But the real engine fixture used 250/180. It also characterized Plan A as a simple capacity problem, whereas the deterministic constraint failure was concurrent AV.
The model had reasoned from its context rather than running the engine.
We looked for the actual Switch tool invocation, connected the evaluation operation, and checked the CLI output. The corrected report showed the real constraints.
Lesson 1: A plausible answer is not evidence that the tool ran.
Our second failure: approval was mistaken for execution
Plan B exceeded the budget by ₹3,000. We intentionally required the designated human owner to type a specific command into the team room:

CASCADE APPROVE <PLAN_HASH> MAX_EXTRA_INR 3000

This is not a digital signature: the SHA-256 plan hash identifies the exact plan content. The Mattermost server supplies authenticated information about the actual author and message. CASCADE checks the account ID, expected server and room, human rather than bot/webhook authorship, timestamp, plan hash, and approved amount.
The human's real approval message is visible in the demo video. It binds the exact recovery plan hash to a maximum extra spend of INR 3,000.
Then came the “ACTIVE / COMMITTED” message. The agent had seen genuine approval but did not have the recovery execution operation available. One failed tool turn later, we learned to separate permission to execute from evidence of execution.
We added a constrained cascade_execute_recovery operation that targets the real recovery CLI and propagates failures. The first successful local application used the verified recovery CLI. Later, an Antigravity-initiated Switch tool call checked the same already-applied result and reported Already Applied: true without posting another receipt.
That later operation was an idempotent replay, not the original artifact creation. We don't pretend otherwise.
Lesson 2: Human approval is a prerequisite. A verified receipt is the result.
What the recovery actually produced
The successful local execution generated:
File Meaning
schedule.json 250/180 hall allocations, synchronized kickoff and projected ₹83,000
assignments.json All 430 attendees assigned with no gaps or overlap
stakeholder-messages.md Communication drafts only — not sent
receipt.json Verified plan hash, approval reference and state APPLIED_LOCALLY
The actual bot-authored receipt appears in the demo video, with the plan ID, verification reference, and APPLIED_LOCALLY execution state.
The execution code validates existing artifacts on retry and avoids duplicating the published receipt.
APPLIED_LOCALLY means exactly that: local files exist. It is not a venue booking, transaction, or notification. In a real deployment, those external actions would require separately designed integrations and explicit authorization.
What I liked about Switch—and what I'd improve
Switch's most useful property was allowing an existing agent to work inside the team's actual decision context. Human instructions, permission prompts, evaluation reports, and receipts were visible to the same people.
The rough edges were equally instructive:
A supported custom-tool SDK would be safer and easier to reproduce than a version-specific operations-file patch.
First-class tool-result provenance would make it harder for an agent to say “completed” without a completed operation.
Scoped permissions would reduce repetitive approval prompts for safe read-only tasks while preserving strong gates for higher-impact actions.
Local service health diagnostics should make database, Mattermost, gateway, and agent failures easier to distinguish.
A structured decision timeline could link incident → evaluation → human approval → execution receipt without a manual investigation.
These aren't hypothetical complaints; each one came from building or debugging this exact workflow.
The principle I'll carry into my next agent project
Start with one reproducible task. Connect one agent to one shared room. Give it a real tool with explicit inputs. Make human decisions genuinely human. Require a receipt that says what the software actually did, and make retries safe.
The most interesting question for workflow automation isn't merely “What task happens next?” It's “Which promises must remain true, and who is allowed to change them?”
That's the idea behind CASCADE.
The agent coordinates. The engine checks. The human authorizes. Switch keeps the team together.
And after our agent confidently declared a plan committed before running it, that separation is exactly what I want from AI workflows.

Explore CASCADE

💻 Source code: View CASCADE on GitHub

🎬 Demo video: Watch the full CASCADE demonstration on YouTube

🏆 Hackathon: Flip the Switch 2026

Direct links:

GitHub: https://github.com/yashshah1211/cascade

YouTube: https://youtu.be/Q33BVLvCgTA

All people, venue, budget and event details in the scenario are synthetic. The Mattermost approval/receipt screenshots are from a genuine local demo; private local services are not publicly accessible.

I built HackerMate because finding a hackathon team still sucks in 2026

Yash Shah — Sat, 18 Jul 2026 08:26:09 +0000

If you've ever hacked solo because you couldn't find teammates in time, or ended up in a mismatched team because Discord servers move too fast to actually vet anyone — this one's for you.
I've been building HackerMate, a full-stack platform designed to fix the two most painful parts of hackathons:

Before the hackathon: finding the right team Instead of scrolling through chaotic Discord/WhatsApp threads, HackerMate lets you:

Browse and create teams
Search for teammates by skill, role, or college
Apply to join a team or invite people directly

During the hackathon: actually staying organized Once your team is formed, HackerMate becomes your mini project OS:

Task management
Daily standups
A shared project board

The stack:

Next.js (App Router)
Supabase for auth + database
Tailwind CSS with a custom dark design system
TypeScript throughout

It started life as "HackOS" before I rebranded, and it's now live at hackermate.in. Right now it has ~35 early users, mostly friends and people from my network — which has been super useful for feedback, but I'm now trying to get real hackathon teams using it in the wild.
If you're participating in any upcoming hackathons, I'd genuinely love for you to try forming a team on HackerMate and tell me what breaks. Feedback — good or brutal — welcome in the comments.
What's the most annoying part of finding a hackathon team for you?

DEV Community: Yash Shah

When Our AI Agent Said Committed Before It Had Executed Anything

Explore CASCADE

I built HackerMate because finding a hackathon team still sucks in 2026