Your AI demo worked. That was the easy part.
Most AI automation works in the demo and dies before it runs every day. Here is the gap where it dies, three of the systems that run this site (you can operate them yourself), and how the parts that could embarrass you get handled.
You wired a language model into something at work, and in the demo it felt like magic. Then you tried to make it a thing you could actually depend on, and it quietly came apart: the odd input it mangled, the step it skipped, the worry about what it might do while nobody was watching. So it stalled in a branch somewhere. That gap, between a prompt that works once and a system that runs every day without embarrassing you, is the whole job. It is also what this website is built out of. Three of those systems are running below, not as screenshots but as things you can operate. Poke them.
The demo is the easy part
The reason your prototype stalled is almost never that the model was not smart enough. The model is the cheap part now, and it keeps getting cheaper. The expensive part is everything wrapped around it: the retries when a call fails, the state carried across steps, the check that catches a bad answer before it ships, and the person left in the loop wherever a mistake would actually cost something. That wrapper is the , and it is where the weeks go.
One more thing the demo hides. When most people picture AI automation, they picture a system that runs the whole job by itself. What almost everyone actually wants is narrower and better: heavy leverage on the one repetitive, judgment-light part, with a hand still on the wheel for anything irreversible. The people who have already been burned know that difference in their bones, and they tend to be the ones worth building for.
Three of them, running. Try to break them.
None of these is a mockup. Each is a real system operating this site right now, and each is the same shape I would install in your stack. I have just pointed it at my problems instead of yours. Underneath each one, in bold, is what the same machine looks like pointed at yours.
One overloaded prompt, split into specialists. This site's content pipeline hands a single job to five small agents, each with one narrow task, and they converge on a single reviewed write. In your world this is the invoice that gets read, categorized, matched to a purchase order, and flagged for a human, or the support ticket that gets triaged, drafted, and routed, by steps that each do one thing well instead of one prompt trying to do everything. It is catalogued at /store/enrichment-orchestrator and mapped in the architecture tour; the code is scripts/enrichment/orchestrator.mjs.
A check that refuses to let a bad answer out. Every change to this site's games is run against a fixed list of checks, its , and the change is blocked until all of them pass. No model gets a vote, which is the entire point: whether an output is safe to ship is not left to the model's mood. In your world this is the rule that stops a mispriced quote, a malformed export, or an email addressed to the wrong customer, before it goes out the door. It is the playtest harness guarding the live games library; the checks live in .github/workflows/playtest-gate.yml.
The risky click waits for a person. An agent here can draft and critique all day, but nothing publishes until a approves it, and rejecting sends it back. In your world this is the outbound invoice, the customer reply, the post that sits in a queue until someone says yes. Everything up to that click is automated; the click you would lose sleep over is not. You can see what comes out of that gate in the public broadcasts archive and the open notebook; the gate itself is scripts/workflows/approve.mjs. It is also the exact shape of the engagement I sell.
The two things that actually go wrong (and how I handle them)
Honesty is worth more than a pitch here, so here are the two failures that reliably show up in this kind of work, both handled by design rather than by hope.
The first is the machine doing something dumb while no one is watching. The answer is the gate you just used: the agents only read, every write goes through one audited path, and a person clears anything irreversible. I do not build fully autonomous systems with no human in the loop, and I will talk you out of it if you ask. The second is the slow, quiet failure: the workflow drifts, or the model bill balloons, and nobody notices for a month. The answer is an eval that scores output against a written definition of good, cost tracking on every run, and the cheapest model that clears the bar at each step instead of the biggest one everywhere.
And the honest floor under all of it: the work is scoped to one workflow in a fixed window, and if the first week shows it cannot clear the bar, I tell you then and we stop. You are not buying a roadmap of ten things. You are buying one thing that works.
The model is the part that finally got easy. Everything that keeps it from embarrassing you is the part that did not.
Is this you?
This is worth a conversation if a repetitive, text-shaped task is eating real hours out of your week, you have already tried an LLM on it and stalled before you could trust it, and you would rather own one workflow that works than rent a roadmap of ten that do not. It is not for you if you want a fully autonomous system with nobody in the loop, or if the task has no examples of a right answer to hold the machine to, because then there is nothing to measure and nothing to trust. If that first description sounds like your week, the engagement is scoped and priced on a call. If it turns out not to be a fit, that call is still worth your time, and you leave with an honest read instead of a proposal.
Get the next one
An occasional note when something genuinely new ships here — essays, free tools, projects. No schedule, no filler, easy out.
Need something like this built?
I design and ship AI tools, full-stack apps, and data pipelines — end to end, to production. Tell me the problem in a sentence; I'll give you an honest read on fit within a day.
Work with me →