This will be available in the next version. A team step can now carry an entry check: a shell command the runner executes before the step's agent is even launched, on every entry (first visit, loop-backs, resume after a restart, parallel branches measured before any of them starts). Exit 0 starts the step; any other exit code, a cut-off or a command that cannot start never starts it, with zero model turns spent. The step's policy then either blocks the run, with the command's exit code and stderr shown on the run box and on the timeline, or skips to the step you designate. The fields (entryCheckCommand, entryCheckPolicy, entryCheckSkipTo) are also accepted by teams_save and described by capabilities_get. If this is not how you imagined it, tell us and we will adjust.
Deterministic gate on node entry in a team run
From Pedro FigueiraDone 6 days ago
Today a team node's guardrails live entirely in stepInstructions and in the skills it loads. That makes every guardrail advisory: it holds only for as long as the LLM reads the text and complies. We run an operational kill-switch (a repo variable that must halt all automation instantly) and we had to implement it as "first line of every node's instructions" — which means a node that simply doesn't follow the instruction runs anyway, and nothing notices.
checkCommand doesn't cover this. It's an exit gate: it runs in the handoff path, after the agent has already completed the step. By then the work is done. There is no hook between entering a node and the agent acting.
Proposal — entryCheckCommand + entryCheckPolicy on the node, symmetric with the existing checkCommand/checkFlag, but executed by the runner before spawning the agent. Exit 0 proceeds; any other exit, a timeout, or a spawn error blocks the run. entryCheckPolicy chooses between blocking the run and skipping to a designated node.
Acceptance criteria
- With the check command returning non-zero, the run blocks at the first node having consumed zero LLM turns — verifiable in the run's token accounting.
- The block is visible in the UI with the command's stderr, not a silent skip.
- A node without entryCheckCommand behaves exactly as today.
- Command timeout and spawn failure are treated as failure (fail-closed), never as success.
Replies
Thanks: your idea is implemented and ships in the next release. We built it the way we pictured it, so if the result is not what you had in mind, tell us and we will adjust it.