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: 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 gradually decomposing "the agent" into more explicit pieces.
MCP gives the agent capabilities.
Skills help it understand how to use them.
Plans describe how work should be performed.
Runtime policies constrain what actions may happen and in what order.
That decomposition raises another question.
Where should organizational judgment live?
A permitted action is not necessarily a justified decision Suppose an agent is onboarding a new vendor.
The runtime can verify that the user is authorized.
The gateway can verify that the agent is allowed to call the vendor-management API.
A temporal policy can require a recorded approval before the vendor is created.
But what determines whether the vendor should receive that approval?
The answer might depend on sanctions screening, tax documentation, annual spend, personal-data handling, risk classification, or an exception requiring committee review.
There may also be incomplete evidence.
If a required sanctions check could not be completed, the correct outcome may not be approval or rejection.
It may be: This is not quite the same problem as tool authorization.
The runtime policy can enforce that approval must exist.
Something else still has to determine whether the evidence warrants approval.
This is where Judgment Pack currently sits This distinction is part of what I have been exploring with the open-source Judgment Pack Specification.
A Judgment Pack externalizes the organization's decision criteria from the agent.
Instead of asking the model to reconstruct the business decision from a policy document every time, the pack can explicitly define the relevant evidence, rules, exceptions, unknown handling, and possible dispositions.
Conceptually: But Dogwood makes the boundary less comfortable than that diagram suggests.
Both systems move deterministic logic outside the model.
Both are inspectable.
Both can produce an outcome that prevents an action.
Both can encode conditions and escalation.
That means the useful question is not whether JPS and Dogwood are "different." The useful questio