Where Does Judgment End and Runtime Policy Begin?
AWS introduced something this week that is close enough to the problem I have been working on that I do not think it should be casually labeled complementary. Amazon Bedrock AgentCore added temporal policies , along with an open-source policy language called Dogwood . Instead of asking only whether an individual tool invocation is allowed, the gateway can evaluate the sequence of actions that led to it. Consider a purchasing agent with this rule: purchases under $10,000 do not require escalation The agent makes six purchases of $9,000. Every individual action satisfies the rule. The sequence may violate the organization's intended limit. The same problem appears with approvals. An API call may be permitted only if a human approval occurred earlier in the workflow. Looking only at the final call cannot establish that condition. Something needs to remember the relevant execution history and evaluate policy against it. That is the class of problem temporal policy addresses. The interesting architectural choice is that this logic lives outside the agent. The model does not need to faithfully remember the constraint from its prompt. The runtime owns the control. More agent behavior is becoming explicit This is not the only sign that agent instructions are moving out of conversations and into inspectable artifacts. A recent ESEM 2026 study of Agent Plans screened 36,710 engineered GitHub repositories and found 85 Markdown plan files across 10 repositories. That is a very small population, so I would not interpret the result as evidence of broad adoption. But the content is interesting. Those plans commonly described implementation steps, specific files or locations, and testing or validation instructions. The agent's execution intent was being preserved as part of the repository. There is a similar pattern in distribution. Tenable's CyberAgents Exchange treats agents, skills, MCP servers, and multi-agent playbooks as separate reusable components. The ecosystem is graduall