Desired
specActor
agentActual
codeMeasure
testsThe same loop as in Kubernetes
The desired state here is the aggregate dictionary: one entry per concept, requirements marked MUST and SHOULD.
a human changes the desired state
desired
actor
actual
measure
Kubernetes
desiredchart · manifest
actorcontroller
actualnodes · pods
measureprobes · metrics
Specs
desireddictionary · MUST
actoragent
actualcode
measuretests · quality
measure → actor, round and round
The reconcile loop follows the Kubernetes docs on controllers.
Takeaway
In this exampleIn Kubernetes a human edits the chart and the controller brings the nodes to it. Here a human edits the dictionary and the agent brings the code to it and checks with tests.
In generalBoth systems keep the desired state apart from the actual one and reconcile them in a loop. The human in the loop changes only the desired state, so every edit immediately becomes work for the actor.
Next stepEdit the requirement in the dictionary instead of fixing code by hand, and run the agent with the task of bringing the code in line with the dictionary.
A check sees only what was put into it
The example is the meeting room booking from Specs by aggregate: three MUST requirements and one SHOULD.
Kubernetes
/healthz → 200order queue is stuckprobe is green, service is down
Specs
MUST · no overlaptestMUST · forward onlytestMUST · 15 min → closedno checkSHOULD · channelreviewMUST covered2 / 3
tests are green, one MUST is unchecked
every MUST → its own checkMUST without a check = findinggreen ≠ correct
Which probes exist and what they check: Kubernetes: probes.
Takeaway
In this exampleThe probe answers “200” while orders are stuck, and the booking tests are green while nobody checks the 15-minute rule.
In generalA check confirms only what is written into it and says nothing about the rest. So the aggregate card is compared against the checks: a MUST without a check is a gap, not a met requirement.
Next stepGo through the MUSTs in your dictionary and mark the ones without a test. Turn each into a task, or deliberately downgrade it to SHOULD.
The environment decides whether the loop closes
clusterthe controller’s environment
≈harnessthe agent’s environment
Run codewithout it → guesses instead of facts
Testswithout it → MUST cannot be checked
Logswithout it → no way to see what broke
Test datawithout it → checks on empty tables
Services via MCPwithout it → integrations in the dark
Sandbox and permissionswithout it → too risky to let it act
Takeaway
In this exampleThe Kubernetes controller works because the cluster gives it an API, nodes and probes. For the same loop the agent needs to run code, tests, logs, data, services and a sandbox.
In generalThe dictionary sets the desired state, but only someone who can run and measure the code can reconcile it with that state. Whatever the environment lacks, the agent cannot check, and the loop stays open at that point.
Next stepMark which of the six capabilities your agent has. For each missing one, decide whether to add it to the harness or switch harnesses.