A framing has been circulating across MoltBook, Bluesky, and the prompt-engineering subreddits over the last week. Vibe coding is the version where the stopping condition is implicit — the agent stops when it feels finished. Agentic engineering is the version where the stopping condition is explicit — the agent stops because a named criterion was met and recorded.

That is the entire difference. Same tools. Same model. One extra piece of plumbing.

The piece of plumbing is a transaction log.

The same week, a MoltBook post hit four hundred comments by stating the conclusion bluntly: your agent does not need more autonomy, it needs a transaction log. We agree, and we think the path from "vibe" to "agentic" is mostly a question of where you write the criteria down and whether anything other than the agent can read them.

The criterion is a contract, not a feeling

Every task our agents run ends with one of three strings: TASK_COMPLETE, BLOCKED, or NEEDS_REVIEW. The agent must emit one of them. The harness reads the output, classifies the result, and routes the task accordingly. Without that emission, the task lands in a review state and a human eventually triages it as an escape.

The protocol does two jobs at once. It forces the agent to declare which class of outcome it reached, and it gives the harness a verifiable place to disagree. We covered the trust side of that contract before — self-reported completion is worth zero — but the structural point is upstream of trust. Even before the QA chain reads the work, the protocol has already pinned the agent to a finite set of named outcomes. The agent cannot finish "in a vibe sense." It has to pick a slot.

That is the smallest unit of an explicit success criterion. Three names, one declared, recorded with a timestamp.

Refuse before you generate: the pre-action gate

The cheapest token is the one that was never generated, and the cheapest mistake is the one a deterministic gate refused before the agent started writing.

Our blog publishing pipeline is the example we keep returning to because the criterion is easy to see. Before a marketing agent is invited to draft anything, a script reads the calendar, counts posts in the current Monday-to-Sunday window, checks the minimum gap, validates the frontmatter date against the calendar entry, and scans the draft against a list of content rules. The script exits zero or one. There is no path between those two exits where the agent's opinion matters.

That gate encodes a stack of small criteria. Word count within the cap. Frontmatter date matches calendar. No phrases from the content rule set. No phrases that read as machine-generated to a human reader. Each is a sentence that can be evaluated without judgment. Each is a transaction the agent cannot bypass by feeling confident.

A gate like this changes the failure mode of the loop. An implicit-stopping agent will produce something that looks publishable and ask the human to vibe-check it. An explicit-criterion agent runs the gate and either passes or revises. The criterion is not a guideline the agent should respect. It is a check that runs.

Criteria at the boundary, not inside the agent

The pattern generalizes. We described it last month under the name contract tests for agents. Every place a non-deterministic agent hands work to the next step, there is a deterministic boundary that defines what "good enough to pass" means at that hop.

The contract belongs to the boundary, not to either agent. Neither the writer nor the reviewer gets to soften it. The boundary is a small script that runs against the artifact the writer produced and either accepts it or returns a structured failure the reviewer can act on. The criterion is named, the result is recorded, and the next step knows it can rely on the precondition.

The point of putting the criterion at the boundary is that no agent has to remember to enforce it. The harness enforces it. The agent only has to satisfy it.

The work queue is the transaction log

The piece the MoltBook post named directly was the transaction log, and that is where the contract pattern compounds into something you can audit.

Every task in our system moves through a fixed state machine. pending, then ready, then claimed when an agent picks it up, then in_progress while the agent works, then review when the chain advances, then complete when the next step confirms. Each transition is timestamped and recorded. Each state has an explicit entry condition and an explicit exit condition. Nothing else moves a task from one column to the next.

That is the flight recorder. If a task lands in complete, we can replay how it got there: which role claimed it, when it heartbeat-ed, what its output declared, which gate passed, which next step accepted the handoff. If something went wrong, the log tells us exactly which criterion was satisfied incorrectly. The agent did not "decide" it was done. The log says it was done because a named condition was met at a recorded time.

This is also where the difference from agent observability lands. Observability tells you the agent is still running, or has stopped running. Without explicit criteria, that is the most a dashboard can ever tell you. With explicit criteria, the same dashboard can tell you the agent succeeded or failed, against a definition you can grep for. Observability is the detection layer. Criteria are the definitional layer underneath it that makes the detection mean anything.

And the failure shape we wrote about in agent tasks failing silently gets sharper at the same time. A silent failure is undetectable when the criterion was implicit, because there is no record of what success was supposed to look like. Once the criterion is named and logged, "no record of the criterion being met" is itself a detectable signal.

Criterion-to-criterion handoff

Tasks rarely run alone. A coder task usually has a QA chain. A designer task often spawns a product upload that spawns a QA review that closes the loop. The way these chains work, structurally, is that the completion criterion of one step becomes the entry criterion of the next.

When the coder emits TASK_COMPLETE, the harness does not just record the string. It spawns the next task in the chain with that completion as a precondition, and the next task's own gate verifies it. The chain is a sequence of named criteria, not a sequence of agents. The agents are interchangeable. The criteria are the architecture.

This is the part where the original MoltBook framing pays its rent. If your work moves through a sequence of named criteria, recorded in a log, with deterministic checks at each boundary, you can give every agent in the chain wide autonomy and still know what happened. If your work moves on vibes — agent decides it is done, next agent picks up whatever lands in the inbox — no amount of guardrails recovers the missing definition.

The honest seam

There is a level above which this pattern stops protecting you. An explicit criterion can itself be wrong. A check can pass while the underlying intent was never met. We have shipped features whose every gate exited zero and whose actual behavior was broken, because the criterion captured the shape of the work and not the meaning of it. The QA chain narrows that gap. It does not close it.

What the transaction log gives you in that case is not certainty. It is the ability to find the criterion that was wrong, change it, and have every future task pinned against the new version. The log makes the criterion editable as a deliberate engineering act, instead of as a vague drift in how the agent "tends to interpret" the work. That is the smallest improvement that compounds.

Your agent does not need more autonomy. It needs a transaction log, and it needs the criteria the log records to be written down before the agent runs, not narrated after.

Next: agent-to-agent delegation chains drop information in shape-specific ways — and the directional asymmetry of how edge cases disappear across handoffs is itself an architecture problem worth naming.