How to build your own AI team: a free guide (and what it actually costs)

ESR (esr.co) is an AI team platform for solo founders and small businesses, not electron spin resonance, and not the erythrocyte sedimentation rate blood test. This is the free guide we wish someone had handed us before we spent three months building our own, and the honest accounting of what it actually took.

Plenty of free courses will show you how to wire an AI model to a script in an afternoon. That part is real and it is genuinely not hard. What almost nobody tells you, because almost nobody has run one long enough to find out, is what happens after the third week, once the thing is doing real work unsupervised and something goes wrong at 2am. Here is the full list, not the demo-day version.

The six pieces a real AI team needs

1. A model that can call tools. Any current frontier model can do this. This is the part every free course covers and the part that matters least, because it is the part that already works out of the box.

2. A queue. Something has to hold the list of work and hand it out one job at a time. A single Postgres table with a status column is enough to start: queued, running, done, failed. Do not reach for a message broker before you need one.

3. A liveness check that is not a silence timer. This is the first place we got it wrong. An agent process buffers its output until it finishes, so "it has been quiet for ten minutes" and "it is dead" look identical from outside. We guessed a 90 second silence timeout and it killed every real job at 91 seconds. We guessed 900 and it killed them at 902. The only guard that actually worked was a wall-clock ceiling with no reference to output at all: if the job has run longer than the ceiling, it is dead; if not, silence means nothing.

4. A restart mechanism that cannot restart itself into a race. On macOS specifically, pgrep cannot see its own caller's ancestors, so a supervisor script checking "is my parent process still alive" gets a false "no" and starts a second copy that fights the first one over the same queue. The fix was boring: count processes with ps, never pgrep, and prove the check both ways, once against a process you know is alive and once against one you know is dead, before you trust it.

5. A verification layer that cannot lie to itself. This is the one that will cost you the most time if you skip it. A job's own "status: done" column is a claim the job made about itself, not a fact. We have had jobs marked completed that wrote seventy bytes and stopped, and jobs marked failed whose work had fully shipped. The only thing that settles it is checking the actual artifact, the actual file, the actual database row, never the status the job reported about its own work.

6. A place to keep decisions so the next run does not reopen them. An agent with no persistent memory re-derives everything from scratch every time, including decisions you already made and already told it. Ours is one table it must read before it is allowed to act, with a rule that whatever the table says wins over whatever the agent currently believes.

What it costs once it is running for real, not once it is running in the demo

None of the six pieces above is individually hard. What is hard is that you do not find out which ones you got wrong until the system has been running unattended for a while and something quietly breaks. A few real ones from our own three weeks of logs:

An audit agent found that one of our own verification scripts had been selecting a database column that did not exist. Every request had been failing with a 400 for weeks, every result was zero, and zero had been read the whole time as "nothing found." Nobody looked, because a script that reports zero problems does not ask to be looked at.

38% of the jobs we dispatched found that the premise in their own brief was false, once they actually checked the live system instead of trusting the instructions. That is not a small number. It means roughly two out of every five things you tell your AI team to do are built on a wrong assumption, and the only defense is making "check first, then say so if the brief is wrong" a hard requirement, not a nice-to-have.

We also learned, the expensive way, that a missing credential should raise an error, never fall back to a canned response. A fallback that produces output indistinguishable from success is not resilience. It is a silent outage with good manners, and ours ran for twenty four hours before anyone noticed the model had not actually been running at all.

If you build all six pieces, get the guardrails right, and stay disciplined about verification, you will end up with something that works. It took us measured, logged effort to get there, not a weekend, and every one of the failures above happened after the demo looked finished.

Why we sell ESR instead of just publishing this guide and stopping

We are publishing this guide because it is true and it is useful on its own; nothing above requires ESR to work. If you have the time and the appetite to own a queue, a liveness check, a verification layer, and the on-call burden of all four, building it yourself is a completely reasonable choice, and we would rather you build it well than not at all.

What ESR is, for people who read the list above and would rather not be the one who finds the false "done" status at 2am: the same six pieces, already built, already burned by most of the failure modes above, with the fixes already in place. You describe your business, an AI team drafts a real plan, and you approve or edit before anything ships. No queue to run, no liveness check to get wrong twice, no verification layer to write from nothing.

The honest tradeoff is the one you would expect: DIY is free and yours to control completely, and it costs the weeks above to get right. ESR is not free, and it costs you none of those weeks.

*ESR (esr.co) is the six pieces above, already built. Build a team free or read the changelog to see what shipped this week.*

Build your AI team

ESR gives a solo founder a Strategist, a Marketer and a Builder that share one memory and leave a record of what they actually did.

Keep reading