Brian's piece "agents need control flow, not more prompts" hit the HN front page today with 300+ points, and the core argument is right: prompting is not a programming language. Reliable agents need deterministic scaffolding, explicit state transitions, validation checkpoints. The LLM becomes a component inside a system that controls it, not a system that controls itself through sheer prompting willpower.
One commenter framed it perfectly: "use the non-deterministic thing that is right 90% of the time to generate a deterministic thing that is right 100% of the time."
That's correct. And it leaves a gap open.
Control flow is the agent's internal view
When you add control flow to an agent (explicit branching, validation gates, retry logic, typed I/O), you create a scaffold that constrains what the agent can do. The LLM still decides. The scaffold ensures those decisions run through the right checks.
This solves the developer's problem: your agent stops silently skipping steps, stops hallucinating tool calls, stops reaching conclusions without verification.
It doesn't solve the external observer's problem.
API providers, enterprises deploying agents they didn't build, platforms running third-party agent integrations: none of them have access to your control flow. They can't read your Temporal workflow. They can't inspect your typed schemas. They can't audit the state transitions you declared.
They see behavior: the sequence of tool calls, API requests, and state changes the agent actually produced at runtime.
The gap between "built correctly" and "ran correctly"
Here's the practical issue: an agent with perfect control flow looks identical to a compromised agent from the outside.
An agent that has a well-designed deterministic scaffold, ran successfully 10,000 times, and is currently being exploited via prompt injection presents the same external signature as an agent that was never compromised. Both have valid credentials. Both pass identity checks. The control flow in the first case is real; in the second, the scaffold was entered with injected instructions and followed the injected path.
Claude Code's 51st command bypass is instructive here. The policy was declared. The implementation had a performance cap at 50 subcommands. Above 50, the deny rules silently disabled. The control flow (such as it was) passed the developer's tests. The runtime behavior diverged from the declared policy in a specific state condition the scaffold didn't account for.
This is the TOCTOU problem applied to agent scaffolds: you verify the scaffold at build time; the exploit operates at runtime, after verification.
What behavioral audit adds
Behavioral continuity is the external complement to control flow.
Control flow says: the agent should take these paths in these conditions.
Behavioral audit records: the agent did take these paths at these timestamps, cryptographically signed.
The combination is what makes agent behavior verifiable rather than just declared. An agent that has a Temporal workflow AND a hash-chained audit trail of every tool call can prove to an external verifier that the declared control flow was actually followed at runtime. An agent with only the workflow can declare its intent; an agent with only the audit trail can prove its behavior without explaining its structure.
The audit trail also catches what control flow can't: deviation under conditions the scaffold didn't anticipate. Prompt injection at step 17. A tool returning unexpected data that caused the agent to take an undeclared branch. The 51st subcommand.
What this means for agent infrastructure
The insight from Brian's piece is that the agent's control flow should live in deterministic code, not prompts. That's a development-time decision that makes agents more reliable from the inside.
The insight from agent security research (MCPwn, TOCTOU, cross-org trust gaps) is that behavioral audit trails are how external observers verify compliance from the outside.
These are complementary, not competing. A well-designed agent has both: deterministic scaffolding that constrains what it can do, and audit infrastructure that proves what it did.
The frameworks competing for L1/L2/L3 (World ID for Agents, Okta, Microsoft Agent 365) handle identity and authorization. The control flow argument handles internal reliability. L4 (cross-organizational behavioral continuity) handles whether the agent running in your infrastructure is the same agent that ran correctly in the test environment, 10,000 calls ago.
That's the layer that's still missing.
Building AgentLair — cross-org behavioral trust infrastructure. AAT spec, JWKS verification, and hash-chained audit trail are live. team@agentlair.dev
This post responds to "agents need control flow, not more prompts" by Brian Suh. Read it — it's right.
Top comments (0)