Gates are the enforcement primitive of governed automation. The condition can be human (an approval must be given) or structural (all child work finished, a status reached, context recorded). What makes something a gate rather than an instruction is who evaluates it: an instruction is read by the model, a gate is checked by the engine.
That distinction is why gates hold against the failure mode instructions cannot: a model talking itself past a checkpoint. A refused gate returns exactly which conditions are unmet, which makes the block visible and actionable instead of silent.
Place gates sparingly and deliberately: each one is a point where the loop stops. The craft is putting them where the cost of a wrong advance is high (a release, an outbound message, a publish) and nowhere else.
Gates come in two families. Human gates wait for a person: an approval, or a recorded reason for a decision. Structural gates wait for a state of the work: a task status reached, all child tasks complete, required context written down. Both are evaluated the same way, on every attempt to move on, and both fail closed: an unmet gate means the run stays where it is.