Building ShipRoom AI with Switch: Bringing AI Agents Together for Safer Software Releases

Software releases are rarely just about writing code and running tests. Before a change is ready to ship, engineering teams need to investigate defects, review code, validate test results, coordinate fixes, and understand the risks involved.

These activities often happen across different tools, conversations, and workflows. Important findings can get lost, responsibilities can overlap, and release decisions can become difficult to track.

I wanted to explore a different approach: What if specialized AI agents could collaborate on release readiness, share evidence, and coordinate their work while keeping engineers in control of the final decision?

That idea became ShipRoom AI, my project for the WeMakeDevs Flip the Switch Hackathon 2026.

The idea: An AI-powered release coordination room

ShipRoom AI is an evidence-first, multi-agent release coordination workflow built using Switch.

Instead of relying on one general-purpose AI assistant to do everything, I designed a workflow around specialized responsibilities:

• Release Auditor: Inspects source code, identifies defects, investigates root causes, highlights edge cases, and independently reviews proposed fixes.
• Release Preparer: Coordinates the investigation, consolidates findings, tracks blockers, and prepares release-readiness assessments.
• Coding Agent: Implements explicitly authorized code changes within the approved file scope.
• Human Engineer: Defines the scope, authorizes changes, runs tests, verifies results, and retains the final release decision.

The key design principle is simple: AI agents can investigate, coordinate, and recommend, but they should not silently take ownership of a production release decision.

How I used Switch

Switch became the central collaboration layer for the project.

I configured the Codex agent provider and registered two specialized agents: release-auditor and release-preparer.

I also created a private Mattermost channel called shiproom-ai, where I could interact with the agents and coordinate their work.

This setup allowed me to experiment with a structured agent workflow:

1. Share a software scenario and investigation request in the channel.
2. Ask the Release Auditor to inspect the source and report findings with file paths, line references, and supporting evidence.
3. Have the Release Preparer consolidate findings, identify blockers, and coordinate the next steps.
4. Define the permitted remediation scope and obtain explicit human authorization.
5. Route implementation to the coding agent.
6. Run the test suite locally and share the actual execution results.
7. Request an independent, read-only audit of the changes.
8. Prepare a final readiness report for human review.

One important lesson was that clear agent responsibilities matter just as much as the agents themselves. For example, the Release Preparer correctly maintained its coordination role instead of modifying application source code. The coding agent handled the explicitly authorized implementation work.

Putting the workflow to the test

I wanted to go beyond a simple chatbot demonstration, so I created a local Python demo repository with intentionally defective APIs.

Scenario 1: Checkout API

The first scenario involved a checkout calculation function.

I introduced defects involving negative quantities, negative prices, and invalid discount percentages. The initial test run produced:

• 7 tests executed
• 3 passed
• 4 failed

The agents helped investigate the defects, identify the relevant validation gaps, and coordinate remediation.

After authorizing changes to the specific source file, the coding agent implemented input validation. I then tested an additional edge case involving extremely large integer values, which exposed an overflow-related issue in the validation path.

After that correction, I ran the full test suite again:

7 out of 7 tests passed.

The independent source review also highlighted residual considerations, including floating-point currency precision and malformed input structures. This was useful because passing tests should not automatically be interpreted as proof that every possible risk has disappeared.

Scenario 2: Inventory Reservation API

For the second scenario, I created an inventory reservation function with defects involving:

• Negative reservation quantities.
• Reservations exceeding available stock.
• Boolean values being accepted as integers.
• Unknown SKUs producing raw KeyError exceptions.

The initial full test run produced:

• 13 tests executed
• 9 passed
• 3 failed
• 1 error

The Release Auditor identified the validation gaps and suggested additional edge cases. The Release Preparer coordinated the findings and maintained the remediation requirements.

I explicitly authorized changes to the inventory implementation and its regression tests. The coding agent then implemented the source-level fixes.

The final owner-executed test results were:

• Inventory tests: 9/9 passed
• Checkout tests: 7/7 passed
• Full test suite: 16/16 passed

The inventory tests covered zero-quantity reservations, exact-stock reservations, insufficient stock, invalid quantities, invalid existing stock values, unknown SKUs, and ensuring rejected operations do not mutate the inventory mapping.

These results were particularly meaningful because the workflow preserved a distinction between agent analysis, implementation, and test evidence supplied by the human operator.

What I learned from building with Switch

This project taught me several important lessons about multi-agent engineering workflows.

1. Specialization improves accountability.

A single agent handling every responsibility can make it difficult to understand who investigated a defect, who implemented a change, and who verified it. Separating auditing, coordination, and implementation creates clearer ownership.

2. Evidence matters more than confident answers.

A useful engineering agent should identify the exact file, explain the issue, distinguish observed facts from assumptions, and state what evidence supports its conclusion.

3. Independent review is valuable.

The agent responsible for reviewing a change should not simply repeat the implementation agent's claims. A read-only review creates an additional verification step.

4. Human approval should be part of the architecture.

I deliberately kept source modification behind explicit authorization. Test execution and release decisions also remained under human control. No commit, push, merge, or deployment was authorized as part of these demonstrations.

5. Switch is useful as a collaboration layer, not just a place to chat with AI.

The most interesting part of this experiment was coordinating multiple agents around a shared engineering task, with distinct responsibilities and a traceable sequence of decisions.

What's next?

ShipRoom AI currently demonstrates release investigation, remediation coordination, regression testing, and readiness reporting using controlled local scenarios.

There is room to extend it with repository integrations, CI/CD evidence ingestion, persistent incident and release history, richer audit trails, and integrations with engineering observability tools.

My longer-term vision is to make release coordination more transparent and less fragmented, while ensuring that engineers retain control over important decisions.

Final thoughts

Building ShipRoom AI with Switch changed how I think about AI agents in software engineering.

The goal is not to replace an engineering team with autonomous agents. It is to give engineers specialized collaborators that can investigate faster, communicate findings clearly, challenge assumptions, and make complex workflows easier to manage.

For me, the most important outcome was not simply getting all 16 tests to pass. It was demonstrating a workflow in which investigation, implementation, verification, and approval remained distinct and evidence-driven.

ShipRoom AI is my experiment in making AI collaboration more accountable, practical, and safe for real engineering workflows.

Built with Switch for the WeMakeDevs Flip the Switch Hackathon 2026.