I built a practice room for the commitments that fall between teams

A customer expects an integration on Friday. Sales wants an answer. Engineering says the work cannot ship by then. What should happen next?

The hard part is often not finding the perfect sentence. It is noticing that several different statements are being treated as one promise: a customer expectation, an engineering target, a proposed follow-up, and an agreement that nobody has actually made.

I built Commitment Lab for the Flip the Switch hackathon as a personal practice space for navigating that kind of conversation. The learner works through a fictional stakeholder conflict with an engineering mentor and two AI agents in a shared Switch room. The goal is to leave with a clearer picture of what has been agreed, what is only proposed, and what remains open.

• Watch the demo
• Explore the repository and setup instructions

A conversation with four roles

The exercise begins with a fictional company, Acme, and a Friday launch expectation. There are four roles in the lab:

• Learner: asks questions, surfaces the conflict, and proposes a next step.
• Stakeholder agent: plays Sales, responds to the engineering constraint, and represents what Sales can do next.
• Engineering mentor: provides the feasibility constraint and can confirm or revise the engineering part of a proposal.
• Coach agent: reads the room and produces a debrief and commitment record.

In the recorded exercise, one operator simulated both the learner and the mentor. The stakeholder and coach were Codex-backed agents running in a real Switch and Mattermost setup. The scenario and customer are fictional. A second, independent mentor joining the room has not yet been verified.

That distinction matters. The design aims to make a human mentor part of the loop, but the demo proves a single-operator role-play with two agents, not independent mentor access or a validated training outcome.

Why put the exercise in Switch?

I wanted the constraint and the response to meet in the same conversation. The Sales agent should be able to react after the mentor explains what engineering can deliver. Later, the coach should review the messages that actually occurred, including the uncertainty and any correction, instead of evaluating a polished answer assembled after the fact.

Switch connects the agents to the Mattermost channel and gives the participants shared room context. The project includes an importable template that creates the stakeholder and coach agents and a room. Their instructions define different responsibilities: the stakeholder advances the conversation as Sales, while the coach looks for evidence in the round and separates commitments from open questions.

This implementation depends on the Switch room for its handoffs. That does not mean a single agent with the right integrations or another multi-person system could never support a similar exercise. Switch makes this particular arrangement of people, agents, chat, and shared history practical to build.

What happened in the recorded round

The stakeholder asked whether the full Acme integration was committed for a Friday launch. The simulated learner asked engineering what was feasible. The simulated mentor responded that neither a CSV export nor the full integration could ship before May 22.

After that constraint appeared, the stakeholder acknowledged that Sales could not confirm the earlier launch. The learner proposed that Sales ask Acme whether it could delay, with May 22 presented as engineering's target. Sales accepted the customer follow-up; the simulated mentor confirmed the target while making clear that engineering could not accept a new launch date on Acme's behalf.

That last distinction is the learning point. A target is not a customer-approved commitment. A Sales promise to ask a question is not the customer's answer. The coach was asked to preserve those differences in its debrief.

There was also a brief offline-or-reconnecting notice before the stakeholder replied. I can say that the notice appeared and that a reply followed; the recording does not establish the details of a reconnection. Clearer agent availability feedback would make this kind of handoff easier to understand.

The coach made a mistake worth keeping in the demo

The recorded debrief correctly kept customer acceptance unresolved, but it also listed Engineering as the CSV export owner even though no one had explicitly assigned that owner. It asked who would return the customer answer even though Sales had already said it would bring the response back.

Those are useful reminders that a plausible-looking summary can quietly turn an inference into a fact. The coach's output needs human review against the room. It is feedback for practice, not a reliable source of professional assessment or an authoritative commitment ledger.

After the coach instructions were refined, the workflow was checked in a targeted follow-up using labeled, simulated role messages. In that one check, the coach left the CSV owner unstated, attributed the simulated roles correctly, and kept customer acceptance unresolved. That's an encouraging observation, not proof that the issue is solved: model output varies, and the follow-up was not an independent mentor session. The repository includes the recorded round and targeted follow-up so others can inspect the difference.

Try the workflow

The repository contains the ready-to-import Switch template, editable agent instructions, a scenario, a debrief format, and setup notes. At a high level:

1. Start or connect Switch Console to a Switch server, configure a chat bridge, and have a supported agent provider installed and authenticated.
2. Import commitment-lab.template.yaml under Templates → Import template, then select Use and provide a short prefix, bridge, provider, and working location as needed.
3. Confirm the room and channel settings, bring both agents online, and add a mentor with the access required by your deployment. If one person plays both roles, label the mentor messages as role-play.
4. Start the Friday exercise by addressing the stakeholder agent. Ask the mentor about feasibility, invite the stakeholder to respond, and propose a conditional next step.
5. Address the coach agent for a debrief, then compare its commitment record to the actual messages—especially owners, dates, and customer acceptance.

The README has the full prerequisites and caveats, including remote-server access and how to regenerate and check the template. A private room is not a substitute for reviewing permissions; agent instructions are not a security sandbox. Use fictional information rather than real customer data or credentials.

What I would improve next

The first priority is to test a genuine second-person mentor handoff, including the actual channel and Switch access that person needs. I'd also like to make the coach's evidence trail easier to inspect and make missing owners and unconfirmed customer decisions harder to overlook. Finally, clearer online and reconnecting status would help participants distinguish a delayed agent from a completed handoff.

The exercise is deliberately small. Its value is in making a familiar workplace ambiguity visible, letting someone practice the next conversation, and showing where an AI-generated record still needs a person to check it.

---

Build and media disclosure: I used Codex and other AI assistance while developing the workflow and materials. The agents in the recorded exercise were Codex-backed. The demo uses screenshots from the recorded run, an illustrative animated pointer, and synthetic narration generated through OpenRouter; it is not continuous live footage.