Flip the Switch Hackathon 2026
A build log on three agents, one human veto, and what happened when our agent quota ran out.
Introduction
Most agent demos follow the same script. You type something, the agent does it, and everyone in the room is impressed for about ten seconds.
We wanted to build the opposite. We wanted an agent that stops and asks before it changes anything in your life.
That idea became LifePilot, a personal life organizer that runs inside a chat room. It has three agents that share one room with one human. The rule they all follow is simple: propose first, save later.
This post explains what we built, how Switch fits into it, and the moment our build hit a wall we did not plan for. It is written for someone who has never used Switch before and wants to know what it feels like to build on it.
The problem we started with
Most people keep their life in too many places. A notes app for ideas. Two group chats for plans. A photo of a handwritten list. The rest stays in memory, which is the least reliable place of all.
The bill that was due last Tuesday was never written down anywhere. Nobody forgot on purpose. It just never had a home.
Most productivity tools solve this by taking over. They ask for an account, sync everything to a server, and quietly decide what matters on your behalf. For something as personal as your day, that trade is wrong.
LifePilot takes the other position. It keeps your data on your own machine, it shows you exactly what it understood, and it refuses to change a single record until you say yes.
Why we built it as a chat room
We could have built a web app. We chose not to, for three reasons.
The room already exists. If you have Telegram or Discord on your phone, you already have LifePilot. There is no app to install on the user's side, no login screen, and no URL to remember.
The room remembers. Tomorrow's morning briefing lands in the same place where you set today's task. Your context never resets because a page reloaded.
Saying yes is visible. Approval happens in plain text, in front of you. It is not hidden inside a settings menu or a pop up you click without reading.
The last point became the center of the whole design.
How Switch fits in
Switch is an open source tool that connects an AI agent you already use to a team chat app such as Slack, Teams, Discord or Telegram. You install Switch Console, create a room, and connect agents to it.
For us, Switch is not a small part of this project. It is the reason the project makes sense.
-
One room holds the whole product.
#lifepilotcontains the human and the three agents. There is no separate admin panel, dashboard or backend UI. - Three agents, three jobs. Capture, Planner and Reminder each have their own instructions. One general purpose chatbot trying to do all three would be a worse product and a worse demo.
- The conversation is the history. You can scroll up and see what was proposed, what you rejected, and what you approved.
- The approval is public. Other people in the room can see that the agent asked before it acted. That changes how much you trust it.
Take Switch out of LifePilot and what remains is a task parser with an API. Nothing you would want to open every morning.
The three agents
LifePilot runs three agents with narrow responsibilities.
| Agent | What it does | What it never does |
|---|---|---|
| Capture | Turns a sentence into a structured task or bill | Does not save anything until you approve |
| Planner | Builds a short daily plan | Does not create tasks on its own |
| Reminder | Warns about tasks due today and bills coming up | Does not repeat itself or nag |
The daily plan has a hard limit of three items. It is ranked by deadline first, then priority, then estimated effort. A list of twelve things is not a plan, it is a wish.
The design rule that shaped everything
Every Switch agent in LifePilot is a thin shell. That means the agent itself does very little thinking.
It does not guess dates. It does not rank priorities. It does not invent categories. It sends one command to the backend and posts the reply it gets back.
curl -s -X POST http://localhost:8000/chat \
-H "Content-Type: application/json" \
-d '{"message": "finish biology notes by Friday", "sender": "capture-room"}'
The backend sends back JSON. The reply field already contains the understanding and the question, and the agent posts it to the room word for word:
Capture: I understood "Finish biology notes" as study, priority 3,
due 2026-11-13, about 45 min.
Nothing is saved yet. Reply "yes" to save it or "no" to discard.
If you say no, nothing is written. Not marked as deleted, not saved with a flag. Nothing enters the database at all.
This leads to the one sentence that describes the whole project:
The model decides what the words mean. The code decides what is allowed to be stored.
Those are two separate jobs, and we kept them in two separate places.
Why the approval rule has two layers
We enforce the "ask first" rule twice, on purpose.
Layer one is the instruction. Each agent is told, in its Switch instructions, to show what it understood and wait for a yes.
Layer two is the database. The backend will not write a task unless the request carries an approved flag. If the flag is missing, the write does not happen, no matter how convincing the message was.
A prompt is not a guarantee. An agent can be confused, and an instruction can be talked around. A database constraint cannot be argued with.
If you only trust the prompt, your safety disappears the moment the model behaves unexpectedly. If you only trust the code, the user never sees the question. We wanted both the visible question and the enforced answer.
This is also the part of LifePilot that is easiest to test. There is a test that sends a proposal, never sends a yes, and then checks that the task table is still empty. That test does not care which model is running.
What actually happened during the build
Getting the room running
We installed Switch Console and used Switch Buddy, the admin agent that comes with Console, to get the workspace and the room set up. Switch Buddy is part of Switch itself, not something we made.
Then we created two agents of our own and connected both to the room: Agenty and Agentex.
It worked. Watching an agent answer inside a real chat channel for the first time is a genuinely good moment, and it took far less time than we expected.
Then the quota ran out
Before we finished the project, our AI agent subscriptions hit their usage limit. The agents stopped replying.
It was not Switch that ran out. Switch is free and open source and you run it yourself. What ran out was the subscription behind each agent, the Claude Code, Codex or OpenCode account that gives the agent its ability to reason. Those plans are metered by session, by time window, or by week. When the allowance is gone, the agent has nothing to think with.
Every team building with agents pays this cost. Few plan for it.
What still worked when the agents stopped
Because every agent was a thin shell, most of LifePilot was not affected by the agents going quiet.
python -m backend.main --demo
That one command runs the whole product. Capture reads messages. Planner builds the day. Reminder produces warnings. A full working day of behavior prints to the terminal with no agent, no network connection, and no quota.
The test suite still passed. The rules still ran. The database still behaved.
If we had put the reasoning inside the agent instructions instead, by writing date parsing into a prompt or asking the model to rank tasks in natural language, the quota running out would have deleted the project. We would have had nothing to run and nothing to show. All our work would have been a set of prompts we could no longer execute.
Put your logic where quota cannot reach it.
An agent is a delivery channel. It should not be the place where your product lives.
What we would do differently
Three changes we would make:
Budget the agent usage before building, not after. Decide which agent does what, and estimate how many sessions that takes. We connected our agents and spent the allowance while we were still finding out what they could do.
Build the offline demo on the first day. Ours is a single flag, --demo, and it saved us. Write yours before you need it, because demos get recorded at the end of a hackathon, when your quota is at its lowest.
Keep the agent as a shell. Every extra piece of reasoning you move into the prompt costs money, is harder to test, and makes the product depend on a service that can stop answering.
A short checklist if you are starting now
- Check your plan limits first. Find out what one agent session costs you before you connect anything.
- Get one agent answering in a channel before you design anything else. Switch's quickstart is short, and seeing it work changes how you plan the rest.
- Decide what the agent may do without asking. For LifePilot the answer was "nothing". Decide yours before you connect it, not after.
- Write the demonstration you can run offline. Even a simple one. It is insurance against the worst possible timing.
- Keep the agent instructions short. Thin instructions plus a real backend are easier to debug than a long prompt that tries to be the backend.
What we would build next
The backend is finished. The room template defines all three agents with their instructions, their addressing rules and their approval behavior. The test suite passes and the demo runs without a network connection.
The next step is the one we did not get to before the quota ran out. That step is bringing LifePilot's own three agents, not placeholder ones, into a live Switch room, and watching a real person say no to a real proposal and see that nothing was saved.
Everything we built points at that moment. It is the reason the two layer approval exists.
Running it yourself
If you want to see the parts that work without an agent:
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt
python -m backend.main --demo
python -m backend.main --check
--demo runs a full day of behavior in the terminal and needs no network connection. --check reports your setup, hides your API key so it is never printed, and can send one live test request to the model you chose.
The backend works with any provider that offers an OpenAI compatible endpoint, including free ones. If no key is configured it falls back to deterministic rules, so it never stops working. The test suite covers 105 cases and runs without any network access.
Closing
LifePilot started as an argument about trust. We did not want an assistant that quietly rearranges your life. We wanted one that shows you its understanding, waits for a yes, and cannot save anything without one.
Switch made that argument real, because the conversation is the interface. The approval happens where you can see it.
We ran out of agent quota before we finished. In the end that turned out to be useful. It showed us that we had put the important parts in the right place.
Built for the Flip the Switch hackathon by WeMakeDevs, DevTools Academy and Switch. Switch is open source and free to self host.
Top comments (0)