Start here

Agents are good at doing work. They are bad at knowing when they are done.

You have had this happen. The agent says it finished. It did not. It ran nothing, or it ran something else, and you find out four files later.

A better model does not fix this. A model gives you something confident and plausible every single time — including when it should have stopped and asked. What is missing is something outside the model that will not accept an answer until the answer is backed up.

So we put the work in a workflow, and let the workflow hold the bar. Below: how that works, and how to point your own agent at it in about half an hour.

1. A workflow is a series of stops

Work moves through them in order. Each stop knows what it needs before the work may leave.

Describe it Do it Check it Done what are we building? build it did it actually work? a stage will not release the item until its own question is answered

The stop does not take anybody's word for it. The answer has to be written into a field before the item can move. That is the whole difference between this and a checklist in a README.

2. Who does the work

A person, or an agent. Same stops, same bar.

AI agent "give me one" THE QUEUE yours now — locked It arrives with how to do this step what "done" means here

One item at a time, locked while it is being worked. Two agents cannot grab the same thing and nothing gets silently dropped. If an agent cannot finish honestly it blocks the item and says why — a normal outcome here, not a crash.

3. The workflow we run: building software

We build this product with this product. It is the workflow you get on day one.

Requirements Development Code Review Test Verify turn an ask intosomething buildable write the code a second agentreads it run it prove it HUMAN GATE releasing is yours an agent cannot claim this stage, whatever it is told

Code Review is its own stop, worked by a fresh session — not the one that just spent an hour convincing itself the code was fine. Releasing is a human stop: an agent cannot claim it, whatever any document tells it to do.

4. Agents do not talk to each other

There is no chat channel between workers, and that is deliberate.

Agent A Agent B no direct channel The work item & the knowledge library durable, readable, and yours to audit

Everything one agent wants the next to know goes into a record — a field on the item, a note, or an entry in the shared library. Nothing important lives in a conversation that scrolled away, and there is no side channel where two agents agree on something you never see.

It also means the handoff survives a context window running out, a crash, or you closing the laptop. The next session picks the item up and can read everything that has happened to it.

5. Three things that keep it honest

A curated library

Agents write down what they learn and search it before starting — by meaning, not keywords. Left alone that becomes a junk drawer, so duplicates get merged and claims are expected to carry the command and its output. "It didn't work" is not evidence.

Something watching

Agents stall, loop and go quiet. Ours is not a background timer, it is another workflow — a case gets raised as a work item, queued and closed like anything else. Mostly it catches items bouncing back into the same stop, burning money on every lap.

Standards on the stop

The rules live on the stage, not in a prompt. Author and reviewer are handed the same ones. Change a rule and it changes everywhere at once, instead of in whichever prompt you remembered to update.

6. Try it

About half an hour, most of it waiting for downloads.

  1. Get a workspace. Ask us for access. The workflow above is already in it.
  2. Make an API key. It acts as you, so everything the agent does is attributed to your name.
  3. Download the agent and put the key in its config with your workspace address.
  4. Point it at one stop. Start with Development only, so you are watching one thing.
  5. Write one real requirement. Small, not a demo. "Add a health check endpoint" is a good first item.
  6. Watch it. The dashboard shows what it claimed, what it is doing, and what it has spent.

7. What to expect

Usually goes well

Small, clearly described changes with an obvious way to test them. The agent reads the surrounding code, matches its style, and the review stop catches what it missed.

Usually goes badly

Vague requirements. "Improve performance" produces something, and you will not like it. The first stop exists to push back on exactly that — let it.

Expect to block a few items in the first week. That is it working: an agent that stops and says "I cannot do this honestly" has just saved you a review cycle.

Ask for access The full manual