Building SwitchOps AI: Six Agents, One Workflow, and a Human in Control

A customer asks for a proposal. Someone needs to find their history, research the requirements, write a draft, review it, send it, and remember to follow up.

That handoff between people, tools, and documents is where work often stalls.

I built SwitchOps AI for the Flip the Switch Hackathon to connect those steps in one workspace—with six specialist agents collaborating through Switch and a human controlling the send.

Explore the project on GitHub

From a customer request to a reviewed proposal

SwitchOps combines customer records, internal knowledge, proposals, approvals, tasks, and workflow tracking.

Its six agents have distinct responsibilities:

Google Gemini provides reasoning and structured outputs. The official Switch server carries addressed messages between agents, with Mattermost providing the collaboration space.

The application uses Next.js and FastAPI. PostgreSQL stores durable business state, Redis supports background jobs, MinIO stores uploaded knowledge files, and Mailpit captures sandbox emails.

Making collaboration observable

One of my main requirements was that specialist handoffs genuinely travel through Switch.

When an agent finishes its work, it posts an addressed handoff. The receiving agent starts when the expected event arrives through Switch. The application persists the receipt, workflow transition, and resulting output.

The main path is:

1. Customer request in Mattermost → Switch → Coordinator
2. Switch handoff → Customer Intelligence
3. Switch handoff → Research Specialist
4. Switch handoff → Communications Specialist
5. Switch handoff → Quality Reviewer
6. Exact-version human approval → Mailpit sandbox capture
7. Switch handoff → Scheduling Specialist
8. Switch handoff → Coordinator finalization

That makes it possible to inspect how a request moved between specialists instead of seeing only a final answer. PostgreSQL remains the business source of truth; Switch carries collaboration events.

The integration bugs that mattered

Connecting the real services exposed issues that deterministic tests had not revealed.

Real cursors needed bigger integers

The live Switch cursors and connection generations exceeded PostgreSQL’s 32-bit integer range. I migrated those fields to bigint so the application could persist the actual protocol values.

Registration needed to survive a partial failure

An agent could register successfully, then encounter a permission error during subsequent configuration. Its one-time credential needed to survive that second operation failing.

I changed the flow to save the identity and encrypted key before attempting follow-up configuration. Supported addressing policies were then configured through the official Gateway owner API.

Revisions needed durable context

A proposal sent back for changes had to retain its feedback across an interrupted connection and an explicit retry. Losing that context would mean repeating the original mistake.

These were useful reminders that reliable agent workflows depend on careful state management as much as prompting.

The first proposal taught me the most

For the live test, I used a fictional customer, Acme Solutions, and a deliberately limited internal knowledge source.

The request was to prepare a nonbinding discovery proposal covering intake, customer context, ownership, human review, and follow-up. Pricing, delivery dates, and ROI were unknown and had to remain open questions.

The first proposal included unsupported claims about automated provisioning. The AI quality reviewer did not catch them.

That was the most important finding of the run.

The integration review requested changes, and the communications agent produced version two without those claims. A fresh quality review followed.

It demonstrated why an AI reviewer should support human judgment rather than replace it.

Approving an exact version

Approval in SwitchOps is tied to a specific proposal version and outbound payload.

For the live demo, I explicitly approved proposal version two for the fictional recipient [email protected], using the local Mailpit sandbox.

The application then sent that approved content. Verification compared the captured email body with the reviewed proposal, normalizing only SMTP line endings.

Mailpit contained exactly one message.

That proves sandbox capture—not delivery to a real customer. The follow-up was internal; no external calendar invitation was sent.

What the live run verified

The completed Acme workflow recorded:

• Six participating agents
• 10 real Gemini model calls
• 8 Switch handoffs
• A revised and explicitly approved proposal
• One captured sandbox email
• One follow-up task and one internal calendar event
• A completed workflow reflected in the dashboard

Research used authorized internal records and the uploaded knowledge source, not public-web browsing.

I also stopped the official Switch server and submitted a separate dependency test. The new request became visibly blocked, with zero model calls and zero handoffs. Existing completed records remained readable.

After restoring Switch, I resumed the verified connections through the authenticated application endpoint, preserving their identities and durable cursors. All six agents reconnected, and Mailpit still contained one message.

The final checks included 24 passing Python tests, a passing browser journey covering persisted records and mobile navigation, and a successful production build.

Read the detailed live verification report

What comes next

The local sandbox workflow works, but production use needs further work: narrower agent ownership permissions, real email-provider configuration, operational hardening, and continued evaluation of generated content.

My biggest takeaway from building with Switch is that an agent workflow needs visible boundaries: who sent a message, which source supported a claim, what version a person approved, and what actually happened afterward.

SwitchOps AI is my attempt to make those boundaries part of everyday business work.

Code, setup instructions, screenshots, and verification: github.com/saifmodan2006/switch_hackathon

This article was prepared with AI assistance from the project’s implementation and recorded verification results.