I let AI agents build and run my T-shirt store from Slack in just 24 hours

Most "AI agent" demos are one chatbot in one window. For the WeMakeDevs Flip the Switch hackathon I wanted to see what happens when you treat agents like a company instead: separate departments, separate permissions, people and agents in the same Slack channels, and work handed from one to another.

The result is Switch Gear, a fictional T-shirt brand from Bangalore with exactly one human: me. Everything else is an AI agent working in Slack through Switch. And the agents didn't just run the store. Most of the store was built by agents too, in a Slack channel, while I reviewed and merged.

It's a demo store: payments, printing, couriers and most orders are simulated. The agents, the Slack channels and the code are real.

Repo: https://github.com/adybose/switch-gear-hq

The org chart

Every department is a Slack channel, and every channel has its own agent:

Each agent is limited in three ways:

1. A role file (agents/<role>/AGENTS.md) saying what it does and what it must never do. Finance never changes prices; support never refunds directly.
2. Its own department API key for the store, used through a small CLI called sg. The support key can't move money.
3. Approval gates in the store itself. An over-limit action returns 202 with an approval id and waits for me. The gates live in the store, not in the agent's good intentions.

How Switch fits in

Switch is what turns a pile of agents into an org. It runs the agents on my laptop (Claude Code and Codex sessions in the background), bridges them into Slack, and handles who can talk to whom. In practice:

• An agent wakes up when someone mentions it in its channel, then answers there.
• Agents hand work to each other with a mention in another room: support asks finance for a refund in #finance with the order id.
• Rooms point at each other (support → finance, every department → approvals), so an agent knows where to escalate.
• The whole org (agents, channels, links) is one Switch template in the repo, so a fresh setup is one run instead of an afternoon of clicking.

I set most of this up by chatting with Switch's built-in assistant: "create a researcher agent in this folder", "add a second builder on Codex", "run the template".

The engineering team was agents too

The part I didn't expect to work as well as it did: the #engineering channel.

• builder (Claude Code) takes a task from docs/tasks.md, works in its own git worktree, and opens a PR.
• reviewer (Codex) checks out the PR, actually runs it (install, lint, typecheck, tests, Docker), and posts a verdict.
• I merge. Only the founder merges to main.

Using two different AI models for author and reviewer was deliberate, and it paid off. Reviewer caught real bugs that tests didn't:

• Key rotation that didn't rotate. Re-seeding department API keys added the new ones but left the old ones active: 14 live keys instead of 7. Reviewer reproduced it, builder fixed it and added a regression test.
• A race in the business clock. Two concurrent reads during a sync could see different dates, one simulated and one real.
• A contract mismatch. Ticket statuses in the database didn't match the OpenAPI spec.
• A question only the founder could answer. Is the ₹2,500 GST threshold measured before or after tax? Reviewer refused to approve until I decided, and the decision went into docs/decisions.md.

In about 30 hours, 17 tasks went through that loop and were merged, from the monorepo skeleton to payments, print and shipping simulators, the sg CLI and the Gatekeeper agent.

Things I learned the hard way

One builder is a bottleneck. With the deadline closing in, I added a second builder on Codex in its own worktree, with its own database and ports, so two lanes could run in parallel: the Switch side on one, the store side on the other.

Tell agents exactly which task to take. Both builders' rules said "pick the lowest open task". With two of them, that's a race. Naming the task in every prompt fixed it.

Long conversations burn usage. I hit my Claude limit mid-task. What helped most:

• reset an agent's conversation between tasks (everything it needs is in the repo anyway);
• run routine tasks on Sonnet and switch to Opus only for the delicate ones (payments, approval gates, the Gatekeeper);
• lower Codex's reasoning effort when it didn't need to think hard.

Put decisions in files, not chat. A reset wipes chat memory. docs/decisions.md doesn't. Every judgement call (GST basis, money in integer paise, "anything waiting on a human gets a real-time minimum") lives there.

Demo clocks need a human floor. At demo speed one business day is ten minutes, so "cancel unpaid orders after 30 minutes" gave a real person about 12 seconds to pay. Now it's 30 business minutes or 5 real minutes, whichever is longer.

Make the PR mark the task done. My first rule was "the founder marks a task done after merging". I forgot every time, and the builder refused to start dependent tasks. Now each PR sets its own task to done, and merging makes it true.

What's live and what's next

Live: the store and checkout, mock payments, print and shipping simulators, approval gates, the sg CLI, all nine AI agents in their Slack channels, and the org template.

Built but not wired up yet: Gatekeeper, a small custom Switch agent (no AI) that streams every store event into #events, pings the right department, and accepts approve APR-7 only from my Slack account.

Next: the double-entry ledger, GST invoices, refunds and reports, so finance has real books to close.

Try the idea yourself

You don't need a T-shirt store. The pattern is simple:

1. One channel per area of work, one agent per channel.
2. A role file per agent, plus credentials that can only do that agent's job.
3. Hard limits in the system, not in the prompt.
4. A second, different model reviewing the first one's work.
5. You, merging and approving.

That's it: a company you can read in Slack.