What a Human Gate Looks Like

A concrete walkthrough: approve the plan, build, review the evidence, release.

Human gates sound like process theatre. But it's the opposite. Here's the actual mechanics, on a real feature. So, you be the judge.

The setup

You are building a feature. Let's say a session manager for a service. You open your agent in the project directory and initialise the harness. Two minutes later you have the constitution, the requirements, the architecture. The agent derived them from the code and docs that already exist.

Gate 1: Design, before any code

You ask the agent to define the feature. It produces a single spec file that has the requirements, the design decisions, the file layout, the task list, and the acceptance criteria. Then it stops.

This is the first gate. You read the spec. You spot that the agent missed the idempotency requirement so that retries are safe. You add it. You say "approved."

Nothing was implemented yet. The one change you made just saved you a rework cycle later. That's the point of the gate. Catch the wrong assumption while it's still one line in a spec, and not when it is a hundred lines of code.

The build with one commit per task

Now the agent works. It follows the approved task list in order. One commit per task. No improvising, no adding features, no "I also noticed this other thing."

If a task fails three times, it stops and escalates instead of thrashing. You're not watching it type. You're reviewing a series of small, traceable commits, each tied to the approved plan.

Gate 2: The evidence, before release

The agent runs the evidence contract. The tests, acceptance criteria, the verification report. It marks the release as pending. Then it stops again.

You read the report. You approve. The agent merges, archives the feature, bumps the version, and records every decision in the build narrative.

Why this scales

Nothing here requires you to be a hero. The two gates take minutes. The agent does everything else. And because every decision is recorded, you don't have to hold the project in your head. Six months later, git log tells you what happened and why.

That's a human gate. Not ceremony. The two moments where a person looks at the work and decides, before it's too late and maybe too expensive to change.

The honest part

No harness guarantees the agent will follow it. The agent may skip steps, forget to update the log, or drift from the approved design. The harness makes the right path clear. It can't force the agent to walk it. Deterministic enforcement is the engine's job, not the protocol's. The protocol is the method, the engine is the paid layer.

So, you still have to watch, correct, and decide. A status command shows you where you are and what the agent should do next, without touching your working tree. But the human stays responsible. That's not a flaw in the harness. That's the whole point. A process that removes the human isn't more reliable, it's just less accountable.

The workflow is free. Bring any agent. Keep your standards. github.com/oystro/oystro-oss