The agentic backend
Every agent demo you have seen is a front end — this is the three layers underneath it
A build guide for the part nobody records: the workspace agents run in, the files that tell them what the business is, and the access that lets them act without letting them send. Four layers, four paste-able prompts, and a build order that deliberately leaves the infrastructure until month two.
Every flashy agent demo has the same shape — a screen recording, a voiceover, one chat window doing one job while someone narrates over it. That is a front end. It works because exactly one thing is happening and a human is driving. A system is what is left when nobody is narrating: five agents running while you are on a call, each one knowing what the business is before it touches anything.
Three things, and you need all three
Get these right and you can walk away from the machine. Miss one and what you have is a demo.
Somewhere the agents actually run
Side by side, without stepping on each other. Two agents in two tabs editing the same folder will overwrite each other and leave it in a state neither of them can explain.
Files that describe the business
What you sell, who buys, how each job gets done — read before the agent touches anything. An agent with no context is a stranger on day one, every day.
Hands, and the gate on them
Tool calls, APIs, the CRM, the inbox — plus the rule that means nothing ships until you have looked at it. Most people build the hands and forget the gate, then wonder why they cannot leave the room.
The stack, and the order it gets built in
Two rules that decide whether any of it survives
The workspace
Why a chat window fails: one agent, one tab, one job at a time. While it works, you wait. While you review, it waits. Neither of you is busy. Open a second tab and the two agents edit the same files and overwrite each other.
The fix is boring — every agent gets its own copy of the project and its own branch. In git that is a worktree. You can set them up by hand, but then you spend more time managing worktrees than running agents, which is how this dies quietly.
What a workspace runner has to do
Superset is the free desktop app built around exactly this — source-available, bring your own subscriptions and keys. The requirements matter more than the brand; anything meeting them works.
Install
macOS is the primary target. Linux is experimental, Windows is not supported yet — on Windows use WSL with plain git worktrees and terminal tabs. You need git. That is the whole dependency list.
Your first workspace
Point it at the project folder
The folder your brain files live in. It detects the git repository automatically — if the folder is not a repo yet, run git init inside it first.
New workspace, one specific sentence
“Rewrite the client onboarding process file from the notes in inbox/onboarding-call.md” beats “improve onboarding”. The specificity is what makes the diff reviewable later.
Pick the agent
Claude Code for anything touching many files or needing judgement. Codex for tight, well-specified jobs. A cheaper model when the task is low-stakes.
Watch it, or do not
This is the point. Open a second workspace. Then a third. The whole value is in not waiting.
Read the diff, not the file
If it only touched what you asked for, merge. If it touched something you did not expect, that is the thing to look at.
Setup scripts
Dependency installs and environment copying go in setup.sh, so every new workspace comes up identical instead of half working.
Claude Code reads CLAUDE.md when it starts. Codex and most others read AGENTS.md. Keep one as the real file and make the other a copy, so every agent you launch reads the same brain. This is the part the demos never show, and it is the difference between swapping models being a dropdown and being a rebuild.
The brain
The workspace is the easy part. The brain is what separates a system that runs from five random chatbots.
Plain text, in a folder, on your machine. Four brain files, one folder per department, one file per job — that is the whole thing. A mature version runs to seven departments and 137 job files, but it starts with one department and six files.
The file structure
What goes in the entry file
CLAUDE.md is not a config file, it is a briefing — the first thing every agent reads. Prompt 1 below writes yours from an interview.
The job file — seven sections, every time
The sections are fixed so any agent can pick up any job without being told the format.
Memory, and where to start
The brain is not static. Give the agents a memory/ folder and a rule in the entry file: when you learn something durable — a client preference, a correction I gave you, a thing that broke — write it down as one file with one fact. Claude Code does this natively; for other agents the rule in the entry file does the same job. Six weeks in, the agents know things about the business you have forgotten you told them.
Do not encode the whole company. Pick the department where the hours actually go — for most businesses that is outreach or delivery — write its four brain files and its six most repeated jobs, and run that. The second department takes a third of the time, because the brain files already exist.
Access — hands, and the gate
MCP is the standard way to give an agent a tool. A server wraps something you already use — Gmail, the calendar, the CRM, Notion, Slack, Postgres, GitHub — and exposes it as actions the agent can call: read the inbox, create a draft, search the CRM, insert a row.
Most SaaS tools now ship an official server or a hosted connector. Search “[tool] MCP server” and take the official one over a community fork every time.
Wire them once, inherit everywhere
At the root of the project, so every workspace picks them up without per-agent setup.
Every key lives in a .env that is in .gitignore. Never in a file the agent reads as context, never in a job file, never in a prompt — the agent gets the key at runtime through the tool config, not by reading it. If a key ever shows up in a diff, rotate it that day.
Three layers, all of them cheap
This is the half that lets you leave the room.
Agents create drafts, humans press send
One sentence in the entry file. Emails become drafts. Posts go to the calendar as “Drafted”. Proposals are files, not attachments already on their way. Nothing external leaves the machine without a human click.
Every file change is reviewed before it merges
This is the review step for everything that is not an email. Read the diff, not the file — the diff is short and the file is not, which is the only reason this scales.
A script that runs before any tool call
Block anything that looks like a send. Exit code 2 stops the call and shows the agent why, so it does the sensible thing and saves a draft instead. Extend the matcher to anything else irreversible: payments, deletes, publishing.
The hook that means nothing sends without you
Read, then draft, then almost never act
The permission ladder
Infrastructure — and why it waits
Everything above runs on a laptop with files, and that is enough for weeks. You need infrastructure the day one of three things becomes true: two people need the same data, something has to run while the laptop is closed, or you want a URL.
Supabase — Postgres with auth and an API — is where anything exact lives: deals, tasks, contacts, invoices, what was sent to whom and when. Files are for context: qualitative and slow-changing. The database is for state: exact and changing hourly. Agents read it through the Supabase tool server and write through the same server or your app’s API. Turn on row-level security from day one even solo, because the habit costs nothing and it means an agent with the wrong key still cannot see everything. Keep the schema in a file the agents can read (db/schema.sql), so they write correct queries instead of guessing column names.
Vercel deploys anything with a URL — the dashboard, the client portal, the internal tool that shows what the agents did today. The agents write to Supabase, Vercel renders what is in Supabase, you look at it on your phone. The agents never touch Vercel directly: it is the window, not the engine.
The things that run without you
When you need what
Nobody needs all of this on day one. The people who build it all first never get to the part where agents do work.
Your first parallel run
Most people find the ceiling at five to seven agents before reviewing becomes the bottleneck. That is not a limit on the tool — it is a sign the job files need to be clearer.
Split the week
Pull out three to five jobs that do not touch the same files. Jobs that would fight over one file run in sequence, not in parallel.
One workspace each
One specific sentence per workspace, pick the agent, and every one of them reads the same brain.
Dispatch and detach
Start all of them, then go do something else. Check back when the sidebar chimes, not every minute.
Review each diff on its own
Merge the good ones. Send the others back with one line of feedback in the same workspace, still isolated from everything else.
Write the lesson down
Anything you corrected twice goes into memory/ or the job file, so next week’s run does not make it again.
Write my entry file
Run it in Claude Code inside the project folder. It interviews you, then writes CLAUDE.md and copies it to AGENTS.md.
Split this week into agent tasks
Wire a tool and set the gate
Design the database from my job files
The front end comes last
The map, the tree, the dashboards — all of it sits on top of this. The map is a picture of the files in departments/. The dashboard is a view of what is in the database. Neither of them does any work.
Build the front end when there is something worth looking at. Then shape it however you want, because the backend does not care what is on top of it.
What this actually costs
The brain takes longer than you think
Writing the four brain files properly is an afternoon. Writing six good job files is a week of noticing what you actually do. It is the whole value and there is no shortcut.
Review is the real cost
Five agents produce five diffs. If the job files are vague, every diff needs work. The fix is upstream — tighter files, not faster reading.
The tooling is macOS-first
Linux is experimental and Windows is not there yet. The workflow still works with git worktrees and terminal tabs, it is just more manual.
Models will change under you
That is the entire point of the any-agent rule. What you own is the files, and the files outlive whichever model is best this month.
Do not build the infrastructure first
The database and the deploy host are month-two problems. Most people never reach month two, because they spent month one on infrastructure.