Some steps do not need a model

Who controls the next step?

Stripe’s blueprints interleave agent work with ordinary code. The agent can decide how to implement a task or repair a failure. Configured linters and the push step run as deterministic nodes. Their execution does not depend on the model remembering to request them. [1]

Dropbox draws another boundary around Nova: the agent changes one branch, while surrounding workflows retain publication control. Those workflows trigger continuous integration (CI) and call the agent back when failures need repair. Dropbox reports that letting agents manage this themselves caused long waits or validation against the wrong tests. [2]

An approval rule the model cannot relax

PostHog’s StampHog checks pull-request eligibility with fixed gates. If a gate rejects the request, the model cannot override it. If the request is eligible, the model can still impose a stricter decision. A backend error or pending reviewer-bot work withholds approval and preserves the trigger for a later retry. [3]

The cases assign different responsibilities to code: running a required step, owning publication, or limiting an approval decision. An eligible StampHog request can still be refused by the model; a Nova validation result returns control to its surrounding workflow.

Our interpretation is that a passed check needs a named scope. A formatter can establish formatting; a test can exercise the behavior it covers; an eligibility rule can permit further review. None of those results alone grants permission to publish. That permission belongs to the workflow’s separate approval and publication controls.