JJoeven

Curriculum/Production Agents

Boring Ops Is the Goal

Production is a queue, traces, caps, tenancy, CI that can say no, and a practiced kill switch. A public URL is just DNS. Stop the loop, see the trace, prevent the encore.

advanced22 min24 / 24

The teams that survive agent production are not the ones with the longest system prompts. They are the ones who can stop the loop, see the trace, and prevent the encore. You now have a gateway that enqueues, workers that checkpoint, versions on every run, traces with dollars and redaction, caps, queues, idempotency, tenant filters, canaries, kill switches, CI gates, and a playbook that ends in a golden. That is the product. The model is a box inside it.

Joeven’s projects are where you practice without production keys: weather tool-agent, research agent, RAG support, multi-agent team, ops approval. Same shapes: typed tools, a transcript, a budget, a test that can fail the build. You started with Python names and lists. You learned math, models, prompts, tools, retrieval, loops, teams, and evals. Production is those pieces with owners, budgets, and a stop button.

A public URL is DNS. Calling a larger model is not a stack. Temperature 0 is not a kill switch. Boring is the goal.

How the box actually works

A readiness checklist is allowed to be rude. If a box is missing, you are not in production. You are in a demo with extra steps.

NeedWhy it is not optional
QueueJobs outlive requests
Job storeDeploys and crashes
Trace storeWhy job_17 spent this
Kill switchStop the loop this minute
CI gatePolicy cannot ship untested
RedactionTraces are a PII store
Tenant filterReads are the quiet breach
PlaybookContain before prompt art
Boring ops is the product
QueueTracesCapsCIKill

A public URL is just DNS. Stop the loop, see the trace, prevent the encore.

Boring ops is the product

Owners still matter when the team is small. Write the names. Practice the stop button on a calendar. Review cost per successful job weekly. Promote canaries only when watched. Drain before you kill pods.

The smallest stack lesson said four tables and a lever. This lesson says: if any row is false, ready is false. A demo with a queue is not ready.

Run ready in staging CI against real config flags, not against a test double that always returns true. Flip each need off once a quarter and confirm the product fails closed: no silent success, no writes, no cross-tenant reads. Game-day the kill switch on a calendar. Review cost per successful job weekly even when nothing is on fire.

Narrow workflows first: handbook Q&A, refunds off, one tenant in the volunteer list. Widen the allow-list when the checklist is still true, not when a blog post is due.

A public-URL ticket

A launch blog said “in production.” The checklist was queue true, job store true, everything else false. No traces, no kill, no CI gate, no redaction, no tenant filter, no playbook. A leaked note and a prompt-only tenancy sentence arrived the same week. They pulled the DNS, built the missing rows, ran a game day, then relaunched a narrow workflow with refunds off. The blog was quieter. The pager was quieter too.

Live PythonOpen full playgroundpython
Output
Run to execute this in your browser. Nothing is sent to a server.

demo is not ready: missing traces, kill switch, CI gate, redaction, tenant filter, playbook. prod is ready with an empty missing list. A demo with a queue is not ready. The full checklist is. Use this function in staging CI if you want to be unkind to yourself in a useful way.

What goes wrong

Calling the URL production. Growing the allow-list before the stop button. Skipping game days because “we are busy shipping.” Treating this track as a recap of ReAct. Buying another orchestrator instead of naming owners. Letting the checklist rot.

A second anti-pattern: a beautiful architecture diagram that does not match the four tables in the database. If on-call cannot find jobs and flags in one query, the diagram is art. Update the checklist when you add a box. If ready is always true in CI because someone stubbed it, you are lying to yourself on a schedule.

How to test it

Run ready against staging config in CI. Flip each flag false once and confirm the product still fails closed (no silent success). Game-day the kill switch this quarter. Replay last incident’s golden on old vs new SHA.

Print missing in the staging smoke test so a new hire sees the list, not a boolean. If the list is empty in staging and full in prod, you rehearsed the wrong play again.

How agents use this

Ship a narrow workflow. Keep the eval in CI. Practice the kill switch on a game day. Then widen the allow-list — not the other way around.

On-call should be able to draw the six boxes, open a trace by support code, trip a cap on purpose, pause one tenant, and point at the golden that came from the last scare. If they cannot, you have a demo. Make it boring. Then you can add the next tool.

You now have the operating loop: admit work as a job, see it as spans, move it with keys and fairness, ship it with canaries and gates, survive it with contain → see → golden. The model remains one box. Keep it that way.

On-call should draw the six boxes from memory, open a trace by support code, trip a cap on purpose, pause one tenant, and point at last quarter’s golden. If they cannot, schedule the game day before the next tool. Magic is an unowned box. Name the owner.

Note:When something feels like magic, look for a missing owner. Magic is an unowned box.

Check your understanding

What makes an agent “in production” more than a public URL?