DEV Community: C Varun

I was losing interest in building, so I built an AI agency on Switch

C Varun — Sat, 07 Nov 2026 18:19:03 +0000

I was spending so long on the boring parts of building software that I started losing interest in building itself.

So I built Backroom: a one-person software agency that runs from a Discord chat, on Switch. In a real run, two client documents that contradicted each other became an agreed brief in 30 minutes. That used to take me three to four days.

This post is how it works, what broke the first time it went live, and how you can set up the same shape yourself.

The problem was never the code

I run WebbyWasp, a small software agency, on my own. I build apps for startups testing new ideas. Most of them start with under 1,000 users, and they have no reason to pay big cloud bills for something that might not work.

So I keep costs tiny. For an earlier hackathon I built PgFy, because paying for a separate database per project made no sense: 50 databases for $12 a month. My client apps' databases run on it today.

Money wasn't the real cost, though. Time was.

Every new project meant the same work. Set up git. Copy compose IDs. Manage environment variables in Dokploy. Click through deploys. Then sync WhatsApp chats, task boards and every other project, and carry all of it to an AI agent by hand. Agreeing one final document took three to four days, partly because I kept putting off the work around it.

None of that was building. It was just tedious.

What Backroom does

A client talks in Discord. A team of agents does the work behind the scenes, and I only make the decisions that commit the business.

Lead (Claude) reads the client's documents, finds contradictions, and writes the brief and technical plan.
Builder (Codex) builds on a branch.
Reviewer (a fresh Codex) tests the running app without ever seeing the builder's conversation.
Desk (plain code, no AI) holds the approvals.

The rule behind all of it: the agents decide the work, and plain code holds the keys.

One real run

I tested this on real accounts with a demo project called Cedar Studio.

The client pressed Start a project, and the project was ready in 26 seconds. Then they posted two documents. One required a phone number on a quote form. The other said email only.

The lead caught that conflict and asked about it in the chat. It also found a second one nobody planted: the client wanted Polar plans, but the other document said no other integrations.

The client answered in one line: "Email only, please. Don't ask for a phone number. And yes, include the Polar plans section."

The lead worked out the rest, and the client confirmed the final brief 30 minutes after posting the documents. That time includes bugs I was fixing live.

Then GitHub filled itself in. A milestone, an issue with 12 acceptance criteria, a branch, commits signed by a Backroom Builder identity, and a pull request with CI. I never opened GitHub to do any of it.

The builder produced what the client agreed: a quote form with no phone field, and a Polar plans page in the admin dashboard.

Why Switch is the backbone

Backroom doesn't just use Switch. It stops without it.

Rooms are the wall. Clients and agents live in separate Switch rooms. When an agent tries to reach a client room, Switch refuses with HTTP 403. I didn't have to build that isolation myself.

Verified identity is the release gate. Every approval is tied to a verified sender. An agent's message can never count as mine, so an agent can't approve its own work. A prompt injection has nothing to talk to.

Handoffs run through it. Claude passes work to Codex through Switch, so two different vendors work as one team.

You can test this yourself with no accounts. bash demo.sh runs 49 steps on a real Switch stack, using scripted roles. Then it turns Switch off, and five real operations fail.

What replaced the clicking

NixOS replaced Dokploy. The deployer builds one exact commit and runs it in its own sandbox on a server I control. A deploy is one tap, not a build cycle I babysit.

The harness layer makes agents swappable. Each role is one line of config:

lead: {harness: claude, model: sonnet}
builder: {harness: codex, model: gpt-6-luna}
reviewer: {harness: codex, model: gpt-6.1-sol}

Trying a better model is a one line change.

Keys are the one chore left. I couldn't remove environment variables, but I could shrink them. The builder declares a name in .env.required, and I paste the value once into a private page. Saved values are never shown again, and they never reach an agent or the chat.

What broke when it went live

Every test passed before this run. Then the real path found what tests couldn't, because tests use stand-ins and these bugs lived in the joins between real systems.

The desk couldn't verify senders. It deliberately has no Docker access, so its identity lookup failed on every message, silently. A tiny read-only helper fixed it, without giving the desk root-level access.
Agents were locked out of their own folders. The login error blamed an old install. The real cause was folder permissions.
Approval cards lost their buttons. Switch drops them from cards that are too long.
A one-second loop burned GitHub's whole hourly limit. Polling now runs once a minute.
The sandbox protected .git, so the builder couldn't commit until it got that one path.
In-memory tests hid a real Postgres bug that only CI could see.

My favourite: the builder refused to start because a document still said "proposed", even though I had approved it. That refusal was wrong, and it was exactly the caution I want.

The lesson: a green test suite doesn't prove the pieces fit. Send one real message through every hop before you trust anything.

Set this up yourself

If you are new to Switch, this is the shape that worked:

Run Switch and connect your agents through its agent protocol. I used Claude Code and Codex.
Bridge a Discord forum to a client room, and keep agents out of that room. Give them a private work room.
Put one plain-code agent between the two rooms. Make it the only thing allowed to cross the wall.
Use Switch's verified sender identity for every approval.
Turn Switch off and confirm your workflow really stops.

The README has the setup, and bash demo.sh proves the wall in about a minute.

Where it stands

The workflow above ran on real accounts, up to a built app with an open pull request. Independent review and deploy for this project are the next stretch, and the code path that lets small safe changes ship with no taps from me is tested but hasn't run live yet. The reviewer catches I rely on so far came from rehearsal, including an admin page showing "Section not found".

I'm rolling Backroom out to production for a real client next.

The biggest change isn't the 30 minutes. It's that I'm building again, instead of configuring.

One person. A whole team.

Code: github.com/c-varun14/Backroom

Why does the spec say that? Building a company brain on FalkorDB that proves every answer

C Varun — Sun, 18 Oct 2026 18:25:28 +0000

Graph Hacks 2026 · Track 03: Company Brain · Live demo · Code · Demo video

On 1 March 2018, someone on the IETF TLS mailing list wrote a message about draft-ietf-tls-tls13-24 and mentioned Section 4.2.1. Five people, six messages and three days later, the thread went quiet. Eventually the draft became RFC 8446, and Section 4.2.1 became the place where TLS 1.3 announces its version through a supported_versions extension instead of the version field every earlier TLS used.

If you join a team that ships TLS 1.3 today, you will wonder why it works that way. The reason is in that thread. Finding it takes a person with a good memory or an afternoon. Most companies have this problem in private, in a chat history nobody can search by meaning. We wanted to see whether a graph could do it, and we picked the one place where we could prove it: a mailing list that is completely public.

This is the story of how Ratified follows that one email to the RFC, and the mistakes we made on the way.

Rule one: no link, no answer

Before any code, we set one rule. A company brain that can't be checked is just a confident guesser, so every answer has to end in a link a stranger can open. That rule decided most of the design:

Answers come from graph traversals, not from a model's memory.
No model writes the Cypher. A deterministic router picks one hand-written query per question.
If the traversal returns nothing, the card says "the graph does not know".

Step 1: the clue is a message

Everything starts with a Message. We pulled 3,078 messages from the TLS list, 1,324 of them with their full text, plus 633 threads and 403 people. Each message links to its author and its thread.

The first mistake was assuming "Section 4.2.9" in a message means Section 4.2.9 of the RFC. It doesn't. Section numbers moved between drafts. A message about draft -21 that says "4.2.9" means -21's 4.2.9, which became RFC §4.2.10.

So a message can't point at the RFC directly. It points at a draft revision, and the revision points at the section.

Step 2: the trail runs through draft revisions

We loaded 113 drafts and their 839 revisions from the datatracker, chained with SUPERSEDED, and the 66 RFCs they became. Then came the part that took the longest: ALIGNS_SECTION, which maps each section of each revision to the RFC section it turned into. It matches by heading text, because numbers lie and headings mostly don't. It also records whether the text was still changing, meaning less than 98% similar to what shipped.

Now a citation can be resolved: message → named revision → aligned RFC section. A citation that can't be resolved is dropped rather than guessed.

The whole trail is one query, and the last hop is a variable-length walk:

MATCH p=(dr)-[:SUPERSEDED*0..]->(last:DraftRevision)
MATCH (last)-[:BECAME]->(rfc:RFC)-[:HAS_SECTION]->(s)
RETURN [n IN nodes(p) | n.id] AS chain, rfc.id AS rfc, s.number AS number

For §4.2.1 it returns the chain message → thread → draft -24 → -25 → -26 → -27 → -28 → RFC 8446 → §4.2.1. Every node on that path is a link to the mail archive, the datatracker or the RFC Editor.

Step 3: only count people who were there while it was moving

Our first version had a flaw we only saw by reading the output. A name called "RFC Errata System" showed up as someone who "discussed" §4.2.10 before it shipped. Errata reports name draft -28, but years after the fact.

The fix was a rule in the query: a message counts only if it was written while the revision it names was current, before the next revision or before the RFC's publication month. After that, §4.2.1 had a clean answer: 6 messages, 5 people, March 2018, written while the clause still differed from what shipped.

We also stopped saying people "argued against" it. The edges show a message cited a clause while it was changing, and some of those people were the draft's own editors. The card now says discussed while still changing, and, further down, connected, not caused.

Step 4: now find the humans

Once you have the thread, the next question is who to ask. The card lists the five people from the thread, plus the current chairs and area directors, and drafts a question with the sources attached. It never sends it.

There's also a "who knows what" ranking. We built a CO_DISCUSSED projection (two people who wrote in the same thread) with Cypher at ingest, then ran algo.pageRank and algo.betweenness over it. The draft's editor ranks first on both, with one of the chairs second.

The trap here: PageRank follows edge direction, and a pair of people has no direction. With one edge per pair, the ranking came out in alphabetical order. Write the projection edges in both directions.

Nobody types "section 4.2.10"

People ask "why does early data work like this?" A full-text index on section headings turns that into §4.2.10 Early Data Indication, shows which words matched, and offers the runner-ups as one-click alternatives.

Two things we learned only by testing against the server. Space-separated terms are ANDed, so a casual question with one extra word matched nothing until we OR-ed them. And indexing the section text made results worse, because broad overview sections outranked exact headings. We index headings only.

Every answer shows its homework

Each card has a panel listing the Cypher FalkorDB ran, its parameters, row counts and the database's own run_time_ms. For the §4.2.1 question that's 4 queries, under a millisecond in total on a laptop. We'd copy this into any graph product. It turns "trust me" into "here is the query".

Asking what the graph doesn't know

Ask about IESG ballots or meeting minutes, which we never ingested, and you get a grey card that says the graph doesn't know. That is the feature we trust most.

Did it beat plain search?

We wrote 13 questions and derived the answer keys with a separate parser from the primary record. The graph answers 13/13. A BM25 plus bge-small retriever over the same text gets 1/10 exact and 3/10 in its top 10, with three count questions it can't score. That headline flatters us, so here is the fair version: on the three questions whose evidence sits in text a retriever can see, it's graph 3/3, retrieval 1/3. On revision lists and counts the answer isn't in any text, it's structure, which is the case for a graph but not really a retrieval failure.

The router was tuned on those 13, so we had a second model write 40 new questions without seeing it. First pass, untouched: 30/40, with 5 confidently wrong routes. The scorer first said 34. Reading the rows showed four questions that took "TLS 1.3" as section 1.3. We fixed it, so that set is no longer held out.

Other things that went wrong and got caught: every revision link we rendered was a 404 until a click-check script found it, one person appeared twice under two email addresses, and a first bench run credited retrieval with a count because the digits appeared in a chunk.

Where it stops

The graph can show a thread and a changed clause are connected. It can't show one caused the other. Meetings, GitHub issues and IESG ballots are outside the record. 47 of RFC 8446's 84 sections have a traced discussion, and the rest are answered as partial. We proved the idea on one working group, not on a company's private chat.

Try it

Live: http://ratified.webbywasp.com. Click Try an example, then open Show how this was computed.
Code: https://github.com/c-varun14/ratified
Run it yourself: docker compose up --build, then http://127.0.0.1:8000. It rebuilds the graph offline from the committed record, with no keys.

We used AI coding assistants while building this and documented how in AI_USE.md.