← Notes

06 / Workflow control

Some steps do not need a model

Code can control a step that must follow a fixed rule.

· 2 min read

What the teams report

Stripe’s blueprints combine model-directed work with ordinary code. A model can implement a task, while code runs configured checks and pushes changes. [1]

Dropbox keeps code publication outside the agent. Its workflows start continuous integration (CI) checks and return failures to the agent for repair. [2]

PostHog checks whether a pull request is eligible for agent approval. Its fixed gates remain authoritative. The model can make approval stricter but cannot relax a gate. [3]

“not every step belongs inside the agent loop.”

Dropbox, on control of the workflow. [2]

01Model taskPropose a result
02Fixed checkApply a known rule
03Next stepProceed or return a failure
Our illustration of a model task followed by code-controlled steps. The cases use different checks and actions.

Our observation

The rule and the judgment can stay separate

A known rule can have a predictable check. The model can handle the parts that require interpretation.

This separation can also make failures easier to inspect. The record can show which rule blocked the next step.

A passing check proves only what that check covers. It does not establish that the complete result is correct.

A question for your buildWhich step must happen the same way on every run?

Sources

  1. Stripe: Minions, part 2Blueprint nodes that run without a model.
  2. Dropbox: Introducing NovaPublication and test control outside the agent.
  3. PostHog: PR approval agentPinned implementation with authoritative safety gates.