How to make your AI employees work for you, not the other way around (copy-paste prompt included)

Should you build a control panel? If two or three of these are true, yes

One rule: two or more yeses and it is worth your weekend. One is worth reading on. None, and you do not need a control panel, and nothing below will change that.

The cheat sheet: build the control panel yourself

This is the prompt I would hand a founder. Paste it into Claude Code, Codex, or whatever coding agent you already pay for. It is written to make the agent interview you first, because the sources it needs to read are specific to you.

I want to build a "control panel" — a single locally-served page I open each
morning that shows only the decisions that need ME, and whose buttons actually
execute. Help me design and build it.

## The objective (read this first — everything else serves it)

The problem is NOT that I lack dashboards. It's that I've become the router:
work happens in background jobs and AI agents, but every result waits on me to
find it, judge it, and click something. The control panel exists to collapse
that. Success looks like: I open one URL, see 5-15 items, clear them in ten
minutes, and close it. Not a metrics dashboard. Not a to-do list I maintain
by hand. A decision queue that builds itself from the real state of my work
and executes when I click.

Two consequences of that objective:
- If an item doesn't need my judgment, it should never appear. Automate it or
  hide it.
- If an item appears, clicking must DO the thing — send the email, log the
  outcome, queue the follow-up. A page that just tells me what to go do
  elsewhere has moved the work, not removed it.

## The tech logic (the four rules that make it work)

1. SPLIT JUDGMENT FROM RENDERING. Two phases, hard boundary.
   Phase A (judgment): a headless AI call inspects the real sources —
   email drafts, project status files, trackers, CRM — and writes a plain
   JSON file of candidate decisions.
   Phase B (rendering): deterministic code takes that JSON and injects it into
   a fixed, pre-approved HTML template. No AI touches layout.
   Why: AI drifts on layout and re-designs the page every run. Code doesn't.
   The template is locked; the renderer swaps only the dynamic regions and
   raises loudly if it can't find its anchor points, so a silently-wrong page
   never ships.

2. VERIFY BEFORE DISPLAY. Every item the AI proposes gets independently
   re-checked by plain code at build time against the live source — the draft
   ID must still exist in Drafts, the lead must still have dated evidence of
   being alive. Unverifiable items are DROPPED, never guessed. This is the
   single most important rule: one hallucinated item and I stop trusting the
   whole page, and an untrusted panel is worse than no panel.

3. THE CLICK IS THE APPROVAL. Buttons POST to a small local server that runs a
   fixed set of action types and returns a real confirmation string. Keep the
   set small and explicit — mine is roughly: send-this-draft, log-an-outcome
   (done / snoozed / parked, with a return date), open-a-link, save-a-preference,
   and queue-free-text-for-the-AI. Every action is appended to an audit log.
   Anything destructive re-verifies the target still exists before acting.

4. FREE TEXT IS AN INPUT, NOT A NOTE. There's a text box on the page. What I
   type gets queued to a file, and a small supervisor process drains that queue
   by handing each item to a headless AI call — one at a time, with a lock file,
   a timeout, and a cap per run. Results get written back as files I can read.
   So the panel is bidirectional: it tells me what needs deciding, and I can
   push new direction back without opening a terminal.

## The stack (keep it boring — this is a personal tool, not a product)

- A plain standard-library HTTP server, one file. No framework, no build step,
  no database. Serves the rendered HTML, a health JSON, and accepts POSTs.
- Flat files for all state: JSON for current snapshots, append-only JSONL for
  event logs (every action, every queued item, every outcome). Grep-able,
  diff-able, no migrations.
- The OS scheduler (launchd on macOS, systemd timers or cron on Linux) for
  three jobs: the server (always on, auto-restart), a rebuild (once or a few
  times daily), and the queue drainer (every few minutes).
- Headless AI calls shelled out from Python for the judgment phase only.
- Pick a port nothing else wants, and make sure the scheduled jobs inherit the
  env vars and PATH they need — a scheduled job runs in a much emptier
  environment than your shell, and this is where most of the debugging time
  goes.

## The access layer — Tailscale (build this EARLY, not last)

This is the part that decides whether the panel gets used. A page that only
works at my desk gets checked when I happen to be at my desk. A page that works
on my phone gets cleared over coffee. Same code, completely different tool.

- Install Tailscale on the machine running the server and on the phone, same
  account. Bind the server to 0.0.0.0 (not 127.0.0.1) and reach it at the
  machine's tailnet IP plus the port.
- What that buys: phone access from anywhere, with no port forwarding, no
  reverse proxy, no domain, no TLS certificate, no cloud host, no third party
  holding my data. The tailnet is private and encrypted, and nothing is exposed
  to the public internet.
- Do NOT use Tailscale Funnel or any public tunnel for this. Tailnet-only.
- Add a PIN gate anyway. A short PIN, compared in constant time, sets a
  long-lived HttpOnly cookie derived from a per-install random key. Tailscale
  keeps out the internet; the PIN keeps a borrowed or unlocked phone from
  showing my whole pipeline. If no PIN is configured, run ungated but log that.
- Two design rules that follow from "this is read on a phone over Tailscale":
  1. Never inline heavy assets as base64. Serve images and video as separate
     files so the browser fetches only what it displays — a self-contained page
     balloons to tens of megabytes over a mobile link.
  2. Design at ~390px width first. Never truncate text server-side; it's
     unreadable on a phone. Use collapsible rows — a one-line summary that
     expands to the full text — so the short view and the full view are the
     same element.

## The agents layer

Alongside the panel I run a set of persistent AI agents, each with a defined
job — one per client relationship, one for the sales pipeline, one for the
system's own maintenance, plus single-purpose writers. Design notes that
mattered:

- Each agent gets a standing GOAL and a list of what it OWNS (which files and
  which surfaces it's responsible for), not just a task description. The task
  list is fluid; the goal doesn't move.
- Agents are DRAFT-FIRST. They prepare, they never send. What they produce
  becomes an item on the control panel for me to approve. That's the whole
  loop: agents generate candidate decisions, the panel is where I clear them.
- Health monitoring is deterministic, no AI. Enumerate the scheduled jobs, read
  each one's last exit code, and grade log freshness against THAT job's own
  cadence — a fortnightly job idle 13 days is fine, a 15-minute job idle a day
  is not. Also scan the log tail for failure markers, because a run that failed
  still wrote a recent file. Show this as a small status strip on the panel.
- Track "when did I last work with this agent" separately from "when did its
  cron last fire" — they're different questions and merging them hides both.

## How to build it (order matters)

1. Design and approve the static HTML page FIRST, with fake data. Get the
   layout right while nothing is moving. This becomes the locked template.
2. Build the deterministic renderer: fake JSON in, real page out.
3. Build the server and the action executor. Wire the buttons. Prove a click
   sends a real email.
4. Put it on Tailscale and open it on your phone NOW, while the data is still
   fake. Every layout problem you'll ever have shows up here, and finding them
   before the AI phase exists means you fix a template, not a pipeline.
5. Only now add the AI judgment phase that produces the real JSON — plus its
   verification pass.
6. Add the free-text queue and the drainer.
7. Add health monitoring last.

## What I want from you

Ask me what my actual sources are (where does pending work live for me?) and
what my top three recurring decision types are. Then propose the page sections
and the action set before writing any code. Start with step 1.

The rest of this article explains what each part of that prompt is defending against, so you can adapt it instead of running it blind.

Your AI employees are working. You are still the bottleneck

Adding AI to a small company solves the production problem quickly and creates a supervision problem slowly.

Mine looked like this. An agent researches a prospect and writes the follow-up email. It sits in Drafts. A monitoring job checks whether a client's pages are still cited by AI engines. It writes a file. A writing agent produces a draft. It lands in a folder. Every one of those is finished work, and every one of them is finished work that has not happened yet, because the last step belongs to me.

Three specific costs, and they compound:

You re-draft what has already been drafted. The agent wrote a perfectly good follow-up. You never opened the folder, so on Thursday you write the email yourself from scratch. You have now paid for the work twice.

You reconstruct context that already exists in writing. Before replying to a lead you go and remember: what did we send, when, what did they say, what were we waiting on? The transcript, the tracker, and the last thread all contain the answer. Reassembling it in your head is a tax you pay per conversation, several times a week.

You audit your AI staff by hand. This is the one people underestimate. A human employee who stops doing their job tells you, or someone notices. An agent that stops doing its job produces silence, and silence looks exactly like everything being fine.

The uncomfortable version: the more capable your agents get, the more of your week goes to being their inbox. Production scales. Approval does not, because approval is one person.

The hidden cost of cognitive overload that never reaches your P&L

You are halfway through a client email when Slack pulls you away. You answer it, check whether last night's job actually ran, take a call, then come back forty minutes later and have to read your own half-written email from the top before you can finish the sentence. Call it context switching, or just too many tabs open. The research name is attention residue: Sophie Leroy, who studies organisational behaviour at the University of Washington, found in 2009 that part of your mind stays behind on the task you left, worst of all when you left it unfinished. David Meyer, whose task-switching experiments underpin much of this research, estimates the resulting mental blocks can cost up to 40 percent of productive time. Even a third of that dwarfs what you spend on software.

For anyone running a company on AI, this compounds: every agent you add is another place to check. A folder here, a log there, drafts somewhere else. Each is a real gain on its own; together they hand you more output and ten more places to look. A control panel collapses the ten into one, and the places were the expensive part.

The panel is the smaller half: self-running local agents are the real system

If you build only the page, you have built a nicer to-do list, and you will stop opening it inside a fortnight.

What makes it yours is that these are local agents, not cloud agents, and the difference is not cosmetic. A local agent is a command-line tool on your own machine: Claude Code, or OpenAI's Codex CLI. Your scheduler starts it, it reads your files, and it runs on the flat-rate plan you already pay for. A cloud agent runs on the vendor's servers and bills per token through an API, whether that is Anthropic's Managed Agents or something you wire up yourself.

The model doing the thinking is the same either way. The economics are not. There is even a direct counterpart to what I have built: Anthropic's Managed Agents, currently in beta, can fire on a cron schedule too, hosted, with no machine of your own. It also meters every run. On a flat-rate plan you can let an agent check something hourly and not think about it. Per token, "check this hourly" becomes a line item, and line items are things founders start rationing. Cadence is the whole premise here, so the billing model quietly decides whether the design works at all.

What makes it work is underneath: a set of agents that run on their own schedule and update the state the panel reads. Nobody starts them. The BD agent fires daily and reconciles the pipeline. The account agents wake around each client meeting and prepare. The writers run when new input arrives. The upkeep agent runs weekly and checks that the wiring between everything still holds. By the time you open the page, the work is already done and waiting.

That distinction is the whole thing. An agent you have to invoke is a tool, and a tool still requires you to remember it exists. An agent that fires on its own is staff.

Four properties make an agent self-running rather than merely available:

• A standing goal, not a task. Write down what the agent is permanently responsible for, not what you want today. The task list changes weekly; the goal should not move. "Keep the pipeline list true and the next move current" survives contact with reality. "Draft three follow-ups" expires on Tuesday.
• An explicit list of what it owns. Which files, which folders, which surfaces are this agent's responsibility. Two agents writing to one file will quietly corrupt each other, and you will find out late.
• A cadence. Daily, weekly, on-trigger, around a calendar event. This is the property people skip, and skipping it is what turns an agent back into a tool you have to remember.
• Draft-first, always. It prepares, it never sends. Its output becomes a card on the panel with a button. This is what makes running them unattended safe enough to be worth doing.

The two halves need each other. Agents with no panel produce work that rots in folders you never open, and a panel with no agents has nothing to show you. Build one without the other and you have spent a weekend on half a system.

The four rules that make a control panel trustworthy

Split judgment from rendering. Two phases with a hard boundary between them. An AI call reads your actual sources and writes a plain JSON file of candidate decisions. Then deterministic code takes that JSON and fills a fixed, pre-approved template. Let a model near your layout and it will redesign the page every morning, helpfully, forever. The renderer should fail loudly if it cannot find its anchor points, so a subtly-wrong page never gets served.

Verify before display. This is the rule the entire system rests on. Everything the AI proposes gets independently re-checked by ordinary code against the live source at build time. The draft ID must still be in Drafts. The lead must still have dated evidence of being alive. Anything that cannot be confirmed is dropped rather than guessed. The reasoning is behavioural, not technical: you will forgive a page that is missing an item, and you will abandon a page that invents one. An untrusted panel is worse than no panel, because you now have a daily ritual that produces nothing.

The click is the approval. Buttons post to a small local server that executes a short, explicit list of actions and returns a real confirmation. Sending the drafted email is the approval, and there is no second confirmation screen, because a second screen is just the bottleneck again in a nicer font. Keep the action list short enough to hold in your head, append every action to an audit log, and make anything destructive re-check its target before it fires.

Free text is an input, not a note. One text box. What you type is queued to a file, and a small supervisor process drains that queue by handing items to a headless AI call, one at a time, with a lock, a timeout, and a cap per run. Results come back as files. This is what makes the panel two-way: it tells you what needs deciding, and it takes new direction without you opening a terminal. Typing "chase the Thursday quote and prep tomorrow's meeting" into a phone at a school pickup is the whole feature.

Human in the loop and human on the loop: you need both

Most advice on this collapses into one instruction: keep a human in the loop. That is half a design.

Human in the loop means the system stops and waits for a person before it acts. Nothing goes out until someone approves it. Human on the loop means the system runs on its own and the person supervises, stepping in when something looks wrong.

Trying to be in the loop on everything is what produces the bottleneck this article opens with. You become a queue of one, and the agents' throughput is capped by your attention. Being on the loop for everything is how you discover in week three that an agent died in week one.

A control panel does both, and the split is decided by reversibility:

• In the loop for anything that touches money, a client relationship, or the outside world: sending an email, publishing a page, moving a deal stage. These become cards with buttons. Nothing sends itself.
• On the loop for everything internal and reversible, such as research, drafting, monitoring, file writes. These run unattended and report by exception. Your supervision is the health strip, not a card per run.

Writing the split down is most of the work. Once every agent knows which side of the line each of its actions falls on, "draft-first, never send" stops being a hope you have about your agents and becomes a property of the system.

The stack is boring on purpose, and one model can build all of it

I did not want to learn about vector databases or pay for another LLM subscription. I wanted to build on top of what I already had. Fable, the Claude model I work in, worked the whole stack out in half an afternoon:

• One file running a standard-library HTTP server. No framework, no build step. It serves the page and accepts button clicks.
• Flat files for state. JSON for what is true now, append-only logs for what happened. No database, no migrations.
• Your computer's own scheduler. launchd on a Mac, cron elsewhere. Three jobs: the server, the rebuild, the queue drainer.
• Headless calls to one coding agent, used only for the judgment step.

Almost nothing new to install, which is why this is buildable by a founder who does not write code. Flat files are also what let the agents and the page share one source of truth: agents write files, the panel reads them, your clicks append to the same logs the agents read on their next run. Nothing to integrate.

Reach it from your phone, or you will not use it. I ran the first version on localhost and checked it twice a week, because I was only ever at my desk when I was already working. Put it on Tailscale: same account on machine and phone, bind the server to 0.0.0.0, reach it at the tailnet IP. No port forwarding, no domain, no cloud host. Add a short PIN so a borrowed phone sees a lock screen instead of your pipeline. Then design for a 390px screen, and never truncate text on the server.

What it costs to run: nothing you are not already paying.

• Coding agent: $0 incremental. These run as local agents on the subscription you already pay for, not as cloud agents on the metered API. Strip API billing keys out of the environment your scheduled jobs inherit, or the same command silently switches to per-token billing and your "free" panel starts charging you.
• Tailscale: $0. The Personal plan is free indefinitely, up to six users and unlimited devices.
• Hosting: $0. It runs on a computer you already own.
• Database, domain, TLS certificate, cloud account: none of the above.

The one real requirement is a machine that stays on. A laptop that travels and sleeps will not do it: the agents stop firing the moment you shut the lid. I run mine on a Mac mini that sits on a shelf and never sleeps, which is the whole hardware budget.

Where the time actually goes is the scheduler. Jobs run there in a far emptier environment than your shell, so a headless AI call that works perfectly by hand will fail under the scheduler with an unhelpful error. Log everything.

What a control panel will not do for you

The limits are worth stating plainly, because this is a personal tool and not a product.

It will not fix agents that produce bad work. A decision queue surfaces output faster. If the drafts are wrong, you will now see them being wrong every morning, on schedule. Fix the agents first.

It does not remove judgment, and should not try. Every item on the page is there precisely because it needs a person. The win is that you spend your judgment on the decision instead of on finding the decision.

It needs a real gardener for the first month. The first few builds will surface things that do not need you, and each one has to be either automated away or suppressed. A panel that shows twenty items is a to-do list, and you will stop opening it.

It is single-operator by design. Everything above assumes one person approving. The moment two people need to clear the same queue you need shared state, locking, and an audit trail with names on it, which is a different and much larger build.

Preference toggles are not enforcement. Mine has standing-rule switches that currently record a preference and nothing more, and the page says so under each toggle. Recording an intention and enforcing a rule are separate pieces of work, and a control panel that quietly implies the second while doing the first is a control panel that lies to you.

Frequently asked questions