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 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:
insufficient evidence - escalate
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:
facts
|
v
judgment
|
v
disposition
|
v
execution policy
|
v
action
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 question is exactly where they differ.
The boundary I want to test
My current hypothesis is that the two systems may operate at different semantic levels.
A Judgment Pack evaluates evidence in order to determine an organizational disposition.
A temporal policy evaluates execution history and runtime state in order to determine whether an action is currently permitted.
For vendor onboarding, that might mean the Judgment Pack evaluates:
sanctions status
tax documentation
risk
annual spend
exceptions
missing evidence
and produces:
approve
reject
committee review
insufficient evidence
The runtime policy then evaluates things such as:
was approval recorded?
did the required previous step occur?
has the spending limit already been consumed?
is the authorization still valid?
may this tool execute at this point in the sequence?
That separation makes sense on paper.
I do not yet know whether it survives implementation.
Some JPS rules may turn out to belong naturally in runtime policy.
Some Dogwood policies may look much closer to organizational judgment than expected.
There may also be workflows where maintaining the distinction creates unnecessary complexity.
That would be useful to learn.
The next experiment should implement both
Rather than debate the architecture abstractly, I think the better next step is to take one realistic workflow and implement it twice.
Vendor onboarding is a useful candidate because it contains both kinds of constraints.
The decision side can include required evidence, a sanctions hard stop, a spend threshold, unknown facts, and escalation.
The execution side can require that the decision occurred, enforce ordering, prevent action after relevant state changes, and control the final tool invocation.
Then compare the two representations.
Which rules naturally belong in the Judgment Pack?
Which belong in Dogwood?
Which can be represented in either system?
Where does duplication appear?
What evidence would be required to prove that the final action was both justified and correctly executed?
Agent governance is becoming infrastructure.
That makes the boundaries between its components more important, not less.
The useful question now is not whether we need more governance layers.
It is whether we can define precisely what each layer is responsible for.
Top comments (1)
I like the separation here. The boundary I keep coming back to is: judgment decides whether the evidence supports an outcome, runtime policy decides whether the system is allowed to execute the next action, and auditability has to preserve both. If those get collapsed into one layer, failures become hard to diagnose because you cannot tell whether the agent made a bad decision or the runtime allowed a bad sequence.