I spent this summer on agent runtime for an SQA process: daily regression tracking, and a test-plan lifecycle that used to be handwritten end to end. The work was not “give the model more tools.” It was deciding which state the agent is allowed to write, which state a human has to sign, and which state is allowed to become a rule.
Two loops covered most of it. They look small on a whiteboard. They were enough to change who did the repetitive work, and how long a test plan took.
People and agents do not think the same way. The first design question is where the human checkpoint has to be.
Enterprise knowledge is for humans
A lot of real workflows live in people’s heads. Edge cases have no SOP. Review pages, job setup, inspection thresholds, and “what we did last time this failed” are scattered across docs, tickets, and memory. You cannot make that knowledge agent-friendly overnight, and you should not pretend a prompt dump is a knowledge base.
If you let an agent treat every session as gospel, it will encode accidents: a one-off workaround, a wrong threshold, a comment that was only true for one machine. If you wait until every case is documented, you never ship. The useful move is a staging layer.
The agent is allowed to notice reusable experience while a human is using the harness. It is not allowed to promote that experience into the harness by itself.
The skill self-update loop
The first loop is about memory that wants to become a skill, but is not one yet.
At runtime the agent extracts reusable fragments from the session — a way to name a job, a check that kept failing, a coverage pattern that applied again — and writes them into a temporary shared-memory layer. That layer is not the harness. It is a inbox.
A human periodically audits the inbox: keep, edit, reject. Only after that review does the agent persist the change into harness internals: a skill, a template, a default, a check. Retrieval then uses the canonical copy, not the session residue.
| Layer | Who writes it, and what it is allowed to do |
|---|---|
| Session | Ephemeral. The agent may work here. Nothing here is a rule. |
| Shared memory | Agent proposes reusable experience. Humans read this on a schedule. Still not executable policy. |
| Canonical knowledge | Human-edited. This is the only memory allowed to become a skill. |
| Skill / harness | Agent writes only after approval. This is what later sessions retrieve. |
Two failure modes this avoids:
- Unchecked self-rewrite. The agent never patches its own skills from a hot session. Promotion is a human gate.
- Up-front completeness. You do not need a finished ontology before the first useful run. Coverage grows as people actually use the harness.
Don’t let it rewrite itself unchecked, and don’t expect to cover every case up front.
The stage loop with human checkpoints
The second loop is about long tasks. Long tasks fail by letting errors propagate. A bad assumption in the plan becomes a wrong job, which becomes a wrong inspection, which becomes a week of noise.
So the work is split into a few stages that matter. For a test plan that was roughly: plan → execute → verify. Not twelve micro-steps. A small number of surfaces a human can actually review.
Inside a stage the agent may loop with tools: read docs, draft artifacts, set up jobs, pull results. That inner loop is cheap to retry. Crossing a stage is not. The stage outcome is a document a human can reject.
The plan stage writes the follow-up, not just the intent
In the plan stage the agent does not write “run tests.” It writes the full follow-up while the human is still cheap to involve:
- how jobs will be set up
- how results will be checked
- thresholds and inspection criteria
- what happens when a job fails
That is the checkpoint. After approval, execution can be asynchronous. The agent runs jobs, then writes job results and inspection results back. QA no longer authors the entire plan by hand. They review a draft that already covers the common cases — in this process, more than twenty coverage types from the input cases — and they only add the few exceptional ones.
The human time for a full test plan went from on the order of two weeks of writing to as little as a few hours of review. Daily regression follow-up dropped a large fraction of the copy-paste work for the same reason: the harness owned the repetitive path, and people owned the gate.
State has to survive the session
A stage loop is useless if the plan lives in a chat transcript. An agent workspace plus shared file formats keep the draft, the approval, the job records, and the inspection results across sessions. The next invocation does not reconstruct the plan from vibes. It reads the artifact.
That is also why the inner loop can be an LLM plus tools, while the outer loop is closer to a durable workflow: wait for approval, claim a job, write results once, replay if the process dies.
Where the checkpoint has to be
The design question is not “how many humans in the loop.” It is which mistakes are expensive to catch late.
- If a skill is wrong, every later session inherits it. Promotion to the harness is a checkpoint.
- If a plan is wrong, every job and inspection downstream is waste. Leaving the plan stage is a checkpoint.
- If a single tool call is wrong, retry is cheap. That is not a checkpoint.
Review stays concentrated: a short inbox of proposed skills, and a plan document that already contains execution and verification. It does not mean staring at every token the model emits.
Keep review concentrated, so mistakes do not travel downstream.
What this is not
This is not an argument that agents should not write code or run jobs. They should, after the expensive decisions are frozen. It is also not a claim that you need a particular workflow product. The primitives that mattered here were ordinary: durable state, an approval signal, idempotent writes, and a place to put memory that is not yet true.
Nothing fancy. The loops worked because they matched how the work already failed: silent accumulation of prompt residue, and errors that only showed up after the heavy jobs had run.