If the Rule Matters, Put It in the Structure: A Week of Agent Reliability Reading
Four articles I read on Builder Center this week kept arriving at the same conclusion from different directions: the behaviors you actually need from an agent (stopping, counting, staying on budget, resisting injection) should be enforced by code and architecture, not requested in a prompt. Here is the pattern, with the pieces that convinced me.
The problem: prompts fail silently
Every agent system carries two kinds of rules. Some live in the prompt ("do not loop forever", "only use the data I gave you") and some live in the structure (an iteration cap in code, a state machine that times out, a validator that rejects bad output). The difference shows up only when things go wrong: a structural rule fails loudly, while a prompt rule fails silently, and you find out from the bill or the output. Reading Builder Center this week, I noticed author after author converging on that distinction, usually after learning it the hard way.
Decide who decides, then enforce it in code
Kenneth Gabriel Alido's "Who Decides the Next Step? Multi-Agent Patterns in Strands Agents" ( https://builder.aws.com/content/3LUbHxhsYgloMVN8Isrcp6q1ALB/who-decides-the-next-step-multi-agent-patterns-in-strands-agents ) is the best decision guide I have seen across Strands' multi-agent options: Workflow, Graph, agents-as-tools, Swarm, and A2A. Two details stood out. First, the session-manager rule: attach persistence to the orchestrator only, a constraint I had not seen called out elsewhere and one that explains some confusing state behavior in multi-agent graphs. Second, his treatment of execution limits as structure rather than instructions. An iteration cap in code fails loudly; a "do not loop forever" line in a prompt fails silently. My own default is agents-as-tools, largely because the docstring acts as a contract and makes failures legible, though I still wonder how often the orchestrator itself becomes the cost bottleneck he warns about.
Give the swarm a referee that is not a model
Decentralized agent swarms push the problem further: when no single agent is in charge, where do the limits live? "Master Secure AI Swarms on AWS Step Functions" by VIVEK (published Oct 30 on Builder Center) answers with architecture: govern the swarm with Step Functions state machines, enforce token budgets with circuit breakers, and isolate agents from each other with zero-trust boundaries. The appeal is that the referee is deterministic. A state machine does not get persuaded, and a token budget circuit breaker does not care how convincing the loop's reasoning sounds. If a swarm is worth running in production, it is worth wrapping in machinery that cannot be argued with.
When in doubt, move the risky part into deterministic code
The most instructive piece of the week was Alexander Bolaño Cervantes's field notes, "I Built an NBA AI Agent. Then I Tried to Break It" ( https://builder.aws.com/content/3KblerFGwtxylcHVQdq16QV4bL2/i-built-an-nba-ai-agent-then-i-tried-to-break-it ). Coming from data engineering, he documents five failures and frames each as the same choice: "trust the model a little more, or move the risky part into deterministic code". The specifics are worth reading: three models produced three different wrong standings calculations, so arithmetic moved into code; the agent explored dates it was never asked about, so a hard fourteen-day limit went into code where no instruction can override it. His follow-ups complete the arc. When an external API kept timing out from Lambda, he swapped the data source behind a stable tool contract, so the agent never knew anything changed, and he then went back to prove the agent could recover from failures using Strands Evals. Reliability came from contracts and tests, not from better prompting.
Treat everything the model reads as untrusted
The same logic applies to security. Alido's piece includes a note I want to amplify: in multi-agent systems, inter-agent messages are untrusted input and can carry injection payloads between agents. Another article I commented on this week proposed a layered answer for code generation: keep the auditing model away from the raw untrusted text entirely, so it cannot inherit the injection, and verify the generator's output with AST and schema checks. I think the pattern is sound with one caveat I raised there: the generator's output can itself carry payloads (obfuscated strings, dependency changes, install scripts), so the deterministic check needs to cover more than syntax. Structure helps here too, but only if the structure inspects the right layer.
A checklist I am taking into next week
Before shipping an agent, I now ask: does every loop have an iteration or token cap in code, not just in the prompt? Is persistence attached in exactly one place, and do I know which component owns it? Can I swap a data source or model without touching the tool contract? Is every calculation that must be correct done in deterministic code? Is anything the model reads (tool results, retrieved text, messages from other agents) treated as untrusted input? And is there a test that proves the agent recovers when a dependency fails, rather than a demo that proves it works when everything is healthy?
Your turn
Where do your agent systems still rely on the prompt to enforce a rule that matters, and what would it take to move that rule into structure?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article