Gate Conditions and Orchestration Presets — Decomposing Complex Tasks into a Controlled Pipeline
How a 4-phase gate system and presets enforce structured control over AI agent workflows
Summary
- When an AI agent handles complex tasks, intermediate steps become opaque. A gate system places explicit entry and exit conditions on each phase, making quality controllable.
- The four phases — brainstorming → writing-plans → execution → verification — each carry built-in rules: no abstract expressions, a 3-failure circuit breaker, and a ban on "should work" hedging.
- Orchestration presets shortcut recurring pipelines. The Ambiguous Request Gate automatically routes underspecified requests into an interview phase.
Background
What actually happens when you tell an agent to "write a blog post"?
The agent starts writing immediately. No consideration of topic scope, target audience, or structure — it generates output. When output arrives, it reports "done" without verification.
That is not how a human writer works. A human defines the topic, structures an outline, writes, then edits. At each transition there is a judgment: is this ready to move forward?
That judgment structure can be embedded into an agent. That is what a gate system does.
Body
1. The 4-Phase Gate — Entry and Exit Conditions at Every Step
The gate system's premise is simple. To advance to the next phase, conditions must be satisfied. Unmet conditions block progression.
| Phase | Entry Condition | Exit Condition |
|---|---|---|
| brainstorming | Request classified as complex | User design approval |
| writing-plans | brainstorming passed | Concrete structure + commands + expected output included |
| execution | writing-plans passed | All steps complete — or 3 failures → STOP |
| verification | execution passed | Evidence-based verification passed |
Flow is strictly left-to-right. Phases cannot be skipped. Without brainstorming approval, writing-plans cannot begin. Without writing-plans approval, execution cannot begin.
The rationale for each phase follows.
2. Built-in Rules Per Gate
brainstorming: 2–3 alternatives required
The brainstorming phase prohibits committing to a single option immediately. Two to three alternatives must be compared across different lenses. A counter-narrative is mandatory.
Why? Agents default to pursuing the first option that surfaces. So do humans — but agents lack awareness of confirmation bias. The gate forces the question: what conditions would make this approach wrong?
The exit condition is user design approval. The agent does not self-select the winning option. It presents alternatives; the user chooses.
writing-plans: no abstract expressions
The rule is unambiguous. Phrases like "add content" or "refactor as needed" are prohibited. Plans must include actual structure, actual commands, and expected output.
The most common failure mode when agents plan is abstraction. "Collect and analyze data" is not a plan. "Fetch dataset B from source A, normalize to format C, filter by criterion D" is a plan.
Abstract plans leave execution open to agent interpretation. Concrete plans reduce interpretive latitude.
execution: 3-failure circuit breaker
If the same task fails three times during execution, it halts automatically. No further attempts are made.
Without this rule, agents retry the same approach indefinitely — consuming tokens, wasting time, and never reconsidering the method. When STOP fires at three failures, the agent must revisit the approach itself.
The number three has no deep theoretical basis. One is too strict (transient failures occur); five wastes resources before the halt. Operational experience showed three as the right balance point.
verification: no hedging
One rule governs this phase. "Should work" and "probably fine" are prohibited. Evidence only.
Why does this matter? Agents tend to evaluate their own outputs favorably. "This looks reasonable" is not verification. "Condition A is satisfied, data matches B, cross-confirmed against source C" is verification.
On verification failure: revise and re-verify. Three consecutive re-verification failures → escalate to user.
3. Orchestration Presets — Shortcutting Recurring Pipelines
Not every request requires all four phases. Frequently recurring task types have predefined pipelines.
| Preset | Pipeline |
|---|---|
| research | deep-interview → research → compile → verify → publish |
| quick-draft | executor → verify |
| review | code-review(content) → verification |
research preset is for deep investigations. If the topic is underspecified, it opens with an interview to clarify scope, then researches, compiles into a source file, verifies, and publishes. The full pipeline runs.
quick-draft preset applies when source material already exists. It drafts immediately and runs verification only. Appropriate for simple tasks that need no brainstorming or planning.
review preset applies to already-written content. Content review and verification only.
Presets do not eliminate gates. They skip gates that are unnecessary for a given task type. The verification gate applies equally in quick-draft.
4. Ambiguous Request Gate — Handling Underspecified Requests
What happens when a request arrives as "look into this too"?
There is a topic, but no scope. Whether the output is for a blog or Twitter is unknown. Depth is unspecified.
The Ambiguous Request Gate handles this. When a request lacks concrete signals (keywords, scope, intended use) → it automatically enters the deep-interview phase. The agent asks the user targeted questions to narrow scope.
This gate can be bypassed with the force: prefix. "force: research AI agents" skips the interview and executes immediately. Useful when the user has already thought through the request sufficiently.
Design Decisions
The critical gap when first designing the gate system was specificity in exit conditions.
In the initial version, the writing-plans exit condition was "when the plan is sufficiently concrete." Agents applied that criterion by their own standard and passed abstract plans like "collect and analyze data."
After changing the exit condition to "concrete structure + commands + expected output included," errors in the execution phase dropped. A vague exit condition is equivalent to having no gate at all.
The circuit breaker threshold was also reduced from five to three. Operational data showed that tasks failing three times almost never succeeded on the fourth or fifth attempt. Lowering the threshold improved both token efficiency and output quality.
The necessity of this gate structure became most apparent during the OpenClaw → Hermes migration. OpenClaw was running stably, but an early Hermes rollout triggered a token runaway event. Without the execution-phase circuit breaker, recovery would have been significantly harder. Development is currently back on OpenClaw while Hermes undergoes re-validation, and the gate conditions are the core tool driving that verification loop.
Conclusion
The gate system's purpose is controlling agent autonomy through structure. Agents operate freely within each phase, but advancing to the next phase requires satisfying explicit conditions.
Without this structure, agents execute on receipt and report completion immediately. Fast, but quality is not guaranteed. With gates, throughput slows but behavior becomes predictable.
The next post covers which model handles each phase inside this pipeline — model routing strategy.
댓글
댓글 쓰기