Repo: github.com/AtharvRaotole/said-switch | Live site: https://said-switch.pages.dev

Watch the demo: Said on Switch, full walkthrough

"Also add dark mode while you're in there"

Riya is a developer. Dana is her client. They share a Telegram group, and Riya has just added an AI coding agent to it so work can happen right where they talk.

Dana types one line:

@builder Also add dark mode while you're in there

It looks harmless. But think about what an obedient agent does next. It starts building. Riya just lost two days of unpaid work, or she spends Monday morning in a "but I thought we agreed" argument with no record of who agreed to what.

If you have ever built something for a client, you have probably seen a version of that message. Scope creep is old. What is new is that the agent in the room will act on it instantly.

The model understands "add dark mode" perfectly. That was never the problem. The problem is that it has no idea who is allowed to ask.

So I built Said.

Said runs on Switch because a normal chat bot cannot enforce any of this: Switch gives every room real participant ids, agent addressing rules, and creator-only room documents, and if you remove Switch, every safety guarantee disappears.

What Said does

Said is a notary agent for a shared chat. It sits next to the coding agent and does four things:

1. Refuses orders from people who aren't authorized to give them, in the open, so everyone in the chat sees it.
2. Logs every request as a numbered draft (DRF-001, DRF-002) with its scope, days and price.
3. Waits for two distinct approvals. The developer and the client must both accept the same version of the same terms. Change the terms and both approvals reset.
4. Settles disputes with the record. When someone says "I thought we agreed", Said quotes a timestamped entry from a signed ledger.

Only after both people say yes does Said hand the work to a coding agent on the developer's machine: Codex (SAID_WORKER=codex in my live setup) or Claude Code (SAID_WORKER=claude). In live mode, a missing or unsigned CLI fails closed; for CI and the offline demo, SAID_WORKER=scripted applies a clearly labeled fixture patch so anyone can reproduce the consent path without a paid login.

Prompting alone cannot enforce any of this: room instructions tell an agent how to behave, not who is allowed to trigger a tool call. Here is how Switch enforces the boundary instead.

How a message moves through the system

Switch is open-source infrastructure that puts AI agents into the chat apps a team already uses. Every channel becomes a room, and the room keeps the history, the rules, the tasks and the decisions.

Said is built on four room primitives. Follow one message through:

Two agents live in the room:

• said, the notary. Its addressing mode is anyone, so both Riya and Dana can talk to it.
• builder, the controller for the coding agent. Its addressing mode is owner and owner agents. Riya owns it. Dana does not.

When Dana tags the builder directly, Switch itself turns her away, and the refusal shows up in the chat. The only path to the builder goes through Said, and Said only opens it when the gate in the middle says yes.

Tech stack

The remove-Switch test

The judges ask one question about Switch: would the project stop working without it? I asked the same question while designing Said, one primitive at a time.

Take Switch away and Said becomes a webhook bot that starts the job. Every safety property comes from a Switch primitive.

The ledger rule isn't just on paper. In a probe room on Switch 0.31.0, I tried to update and delete a Said document as the builder, and Switch rejected both:

PASS: builder update rejected
  Switch API 403: Agent 70dd1521-...
  did not create document 7a361f55-...
PASS: builder delete rejected
  Switch API 403: Agent 70dd1521-...
  did not create document 7a361f55-...
PASS: said update ok

Only the agent that created the room document can change it. That one rule is what makes the ledger worth quoting.

The demo, in seven moves

Every line below is typed by a real person from their own account. These seven beats ran live on Switch 0.31.0 (screenshots below) and are covered by the repo's demo-script tests.

https://youtu.be/1vA87efXzM8

1. Dana asks the builder directly. It refuses.

Dana: @builder Also add dark mode while you're in there

Switch's addressing rules block the message from reaching the builder, and the refusal appears in the chat for both people to see. Said picks up the request, logs it as draft DRF-001, and asks Riya for terms.

2. Riya sets terms.

Riya: Terms DRF-001: +2 days, +$400

Said hashes the terms and writes them to the signed ledger in the room.

3. Riya accepts.

Riya: Accept DRF-001 v1

Her approval is bound to three things: the draft id, the version and the terms hash. One yes isn't enough, so nothing runs.

4. Dana disputes. Said quotes the record.

Dana: Wait, I thought we agreed dark mode was free?

This is the Monday argument, happening in real time. Said answers with a timestamped quote from the ledger: the status (pending), the terms on record, who has accepted, who hasn't, and when the earlier direct request to the builder was made.

No memory contest. Just the record.

5. Dana accepts. The builder runs.

Dana: Accept DRF-001 v1

Now two different enrolled people have accepted the same version of the same terms. The draft locks into AGR-001, and Said sends a signed said-start message to the builder through Switch.

The builder does not trust that message on sight. It reloads the ledger and checks the sender, the signature, both approvals, the terms hash, the lock state, and that the job hasn't already run. Only then does it run the configured worker (SAID_WORKER=codex in my Telegram setup; scripted in the Mattermost capture below) inside a disposable git worktree, restricted to allowlisted paths and gated by typecheck and build. When the job finishes, it posts a signed receipt.

6. Dana proposes a follow-up.

Dana: Propose: add a contrast-safe theme toggle | Terms: +1 day, +$150

Said logs a new numbered draft with its own terms and hash (DRF-002 in a clean seven-beat run; in the Mattermost capture below, an in-flight Amend AGR-001 took DRF-002 while Propose: became DRF-003).

7. Riya accepts. It still waits for Dana.

Riya: Accept DRF-002 v1

Said records Riya's acceptance and waits on Dana. Dana wrote the proposal herself, but a proposal is not an approval. Both people have to say yes, every time.

The rules that make it safe

Under the chat, Said is a small consent engine with strict rules:

• Only the two enrolled Switch participant ids can approve. Display names and quoted text never count.
• An approval binds (draft id, version, terms hash). Any revision clears both approvals.
• A proposal is not an approval, and a conditional yes doesn't count.
• The builder never starts on a chat message alone. It re-verifies everything against the ledger first.
• The coding agent runs in a disposable worktree with path allow-lists, typecheck and build gates.
• Fail closed. If the ledger is missing or tampered with, Said stops. It never quietly starts a fresh, empty record.

The ledger is signed with Ed25519, and the repo ships a verifier, so anyone can check a ledger or an agreement receipt offline:

npm run verify -- path/to/ledger.md --public-key-file .said/public-keys.json

Set it up yourself

If you have never touched Switch, start with the two-minute simulation, then connect a real chat room.

Try it in two minutes, no Switch needed

The repo includes an offline mode. It is a clearly labeled simulation (apps/mock-switch) that does not talk to Switch, so you can see the consent flow first:

git clone https://github.com/AtharvRaotole/said-switch.git
cd said-switch
npm install
npm run demo:offline -- --script

You get a banner saying it isn't Switch, plus local URLs for a chat simulator, Said Console and a sample client site. npm test runs all 289 tests across 32 files on main.

Connect a real Telegram group through Switch

You need Docker, Switch Console, two Telegram accounts with a @username, and a group. Full step-by-step instructions are in the README's Live Telegram room section and TESTING.md (docs/SETUP_LIVE.md covers Mattermost). Three gotchas save an hour of debugging:

• Turn Group Privacy off before adding the bot. Create one bot in @BotFather (/newbot), then open /mybots, your bot, Bot Settings, Group Privacy, Turn off before adding it to any group (Telegram reads that setting on join). Connect the token in Switch Console under Messaging apps (polling, no public URL needed; never put the bot token in .env). A 1:1 DM with the bot never becomes a room.
• Post once before linking. After adding the bot to the group, both people send one message, then the developer links their account in Switch Console (Link my account, This is me) so builder recognizes them as owner.
• Type agent names in full. Telegram does not autocomplete !invite-agent @said or !invite-agent @builder.

With SWITCH_URL, SWITCH_REGISTRATION_KEY, SAID_ROOM_ID, SAID_PLATFORM=telegram, and SAID_WORKER=codex (or claude, or scripted) in .env:

npm install && npm run setup && npm run register
# Invite @said and @builder in the Telegram group, then:
npm run enroll -- --developer "Riya" --client "Dana" --wait
npm run doctor
npm run dev

Each person sends @said enroll <their code> from their own Telegram account, and npm run doctor should be green before you record.

What broke, and what I learned

Identity is the hard part. Getting a model to understand "add dark mode" took no effort. Getting a system to know who said it, and whether they're allowed to, took most of the work. Switch participant ids made that possible.

Every bridge represents a sender differently. On Mattermost, a message's sender arrives as a Matrix-style actor id like @switch-mattermost-{bridge}-{username}:localhost, not the name you see in the chat. Telegram is different again. Over Telegram, my builder at first failed to recognize Said's start messages, because current Switch delivers them as sender @switch-agent-<8 hex>:<server> with sender name said, not the registration UUID. The fix: the builder accepts Said's UUID or that transport id together with the exact name said, and it always rejects human bridge senders (Telegram, Slack, Discord, Teams). Leave SAID_ALLOW_SAID_NAME_FALLBACK unset for Telegram. Set it only for a Switch 0.31 Mattermost bridge. The general lesson: never trust the visible sender. Verify the authenticated handoff and the signature instead.

Telegram's order of operations fails silently. Leave Group Privacy on when the bot joins, and the bot only sees slash commands and direct replies while normal scope messages vanish without an error. Try to link before posting, and Switch cannot match your Telegram user at all.

Setup and doctor used to assume Mattermost. Early npm run setup next-steps and npm run doctor warned about Mattermost even on a Telegram deployment. That is fixed on main: SAID_PLATFORM (or the room's bridge read from Switch) drives setup, register and doctor, so a Telegram room gets Telegram steps and no irrelevant Mattermost warning. Separately, npm run test:coverage used to silently skip two tests (the offline end-to-end story and client-repo prep) on a fresh clone because npm's pretest hook does not run for test:coverage. main now runs pretest:coverage to install the demo client first and fails loudly instead of skipping, running all 289 tests with 0 skipped.

Fail closed beats fail friendly. If the ledger is missing or tampered with, the friendly move would be to start a fresh one, erasing the record the whole product depends on. Said halts loudly instead. I hit my own trap while testing: overwriting a live ledger from a probe script with placeholder text strips the signed said-ledger block and stops the notary immediately, which is why the repo's write probe (scripts/live-doc-auth-probe.ts) only attempts writes as the builder, where Switch rejects non-creator writes.

Where this goes next

Said talks to Switch, not to Telegram, so the same design carries over to the other chat apps Switch connects, such as Slack, Teams, Discord and Mattermost. It's meant for freelancers, agencies and small dev teams who already work with clients in shared channels and are starting to bring coding agents into them.

The coding agent will get faster and smarter every month. The question of who is allowed to tell it what to do won't go away. Switch gives that question an answer: real identities, real boundaries, a record only one agent can write, and a handoff you can verify.

An agent in a shared chat is only as safe as its idea of who is talking. Said makes sure nothing starts until both people say yes.

Links

• Repo: github.com/AtharvRaotole/said-switch
• Demo video: https://youtu.be/1vA87efXzM8
• Live site: https://said-switch.pages.dev
• Switch: https://github.com/sandbox-quantum/switch | Docs: https://docs.switchagents.ai
• Hackathon: https://www.wemakedevs.org/hackathons/switch

I'm Atharv Raotole, and I built Said for Flip the Switch. If you put an agent in a shared chat, I'd love to hear how you decide who it listens to. #HowISwitch