I'm Brett Anderson. For the last several years I've been the integration layer for a mid-market remanufacturer — ERP, order flow, shipping, the internal tools nobody demos but everybody depends on. Lately most of my work is agent workforces: putting language models on real operational work with charters, autonomy limits and human gates, so the question stops being "can it do the task" and becomes "what happens when it's wrong."
Below are three things you can actually open and use, and a written account of how the agent work is governed.
All three are single static pages — no backend, no build step, no dependencies. Source is public for each.
A shift on a governed agent workforce, and you're the overseer. Three agents at three different autonomy levels work a support queue; anything leaving the building stops at a gate you have to click. The interesting beats are where agents stop — one catches its own charter violation mid-draft, another refuses work it is perfectly capable of because its charter forbids it.
Mastermind with the deduction made visible: all 1,296 possible codes render as a grid, and cells go dark as your guesses eliminate them. Two decent guesses take 1,296 down to about 30, and what survives forms a lattice, because the constraints are structural rather than random. A Knuth minimax solver plays alongside you and is guaranteed to finish in five.
Live crypto markets rendered as a pixel battle. The 24-hour move decides where the front line sits, three-minute momentum swings it, and individual trades arrive as gunfire sized by notional value. It is a real-time data pipeline wearing a silly costume — the useful part was learning which market signals actually correlate with price and which are noise.
?theme=.This is the part I actually get hired for, so it's worth writing down properly. Everything below is described at the level of the pattern; the specifics belong to the clients I built them for.
Getting a language model to do a piece of operational work stopped being the hard part some time ago. Ask it to triage a ticket, reconcile two systems, draft the customer reply — it will do a decent job. The hard part is everything around that: knowing what it's allowed to touch, catching the confident mistake before it reaches a customer, and being able to answer "who approved this?" three weeks later when someone asks.
So the model I use treats agents like staff rather than like scripts. Staff have a written job description, a level of trust they've earned, a manager who signs off on the risky things, and a paper trail. All four of those turn out to have direct technical analogues.
A charter is a short written document, kept in version control next to the code, that says what one agent is for: the systems it may read, the systems it may write, the things it must never do, and who owns it. It is written in plain language because its real audience is the human who has to approve it, not the model.
The MAY NOT lines are the ones that earn their keep. They're usually specific and slightly odd — the kind of rule that exists because of one bad afternoon. "Never link an internal document to an external recipient; attach it instead." Those lines are the institutional memory that would otherwise live in one person's head.
A single "is this agent allowed to act" switch is too blunt. Four rungs cover nearly everything, and an agent starts at the bottom and moves up on demonstrated track record — not on how impressive its demo was.
The ladder from Agent Floor. The empty top rung is the point.
Demotion matters as much as promotion. A charter violation drops an agent a rung, the same way you'd pull back responsibility from someone who made a serious mistake, and it goes back up by working correctly at the lower level for a while.
A gate is a hard stop in front of a specific class of action: anything that reaches a customer or vendor, anything that moves money, anything that can't be undone. The agent does all the work up to that line, then presents the finished artifact and waits.
The design detail that makes gates survive contact with reality is that the gate has to show its work. A prompt that says "approve this action?" gets rubber-stamped within a week. A gate that shows the actual email, names the rule that triggered the stop, and states what happens on approve versus deny gets read. If your reviewers are clicking approve without reading, you don't have a gate — you have a speed bump and a false sense of safety.
Every action, every refusal and every human decision lands in a log that is written once and never edited. Not for compliance theater — for the ordinary Tuesday when a customer asks why they got a particular email and the honest answer needs to include which agent drafted it, which rule let it through, and which human pressed send.
Refusals go in the log too, and they're the most useful entries in it. An agent that declined work is telling you either that a charter is too tight or that a real hazard exists. Both are worth knowing; neither shows up if you only log successes.
Once more than two or three agents are running, the bottleneck moves to the human, and the question becomes what one overseer needs on one screen to stay genuinely in control. In practice it's four things:
The measure of the whole arrangement is simple: an overseer should be able to walk away for an afternoon and, on returning, reconstruct exactly what happened and why — without asking anyone.
Pick one queue with real volume and low blast radius. Put a single agent on it at Draft and leave it there longer than feels necessary. Write the charter before writing any code. The first two weeks should produce more edits to the charter than to the implementation — if they don't, the charter isn't specific enough to be doing any work.
Best reached by email — I read everything and reply to anything that isn't a template. If you're putting agents on real operational work, or you have an integration layer that's become load-bearing and nobody wants to touch it, that's my territory.