Fresh Context Is Not Enough: An Agent Action Needs a Valid Chain Back to Its Decision

AI Use Disclosure: I use AI tools to help research, organize, and refine these weekly notes. I review the underlying sources, decide which developments and arguments are worth including, and edit the final piece before publishing.

---

This week's most interesting agent architecture question was not whether models have enough context, but whether a pending action is still justified by the state, evidence, and authority that originally produced it.

A common assumption in agent architecture is that keeping state synchronized solves most coordination problems. If every agent can see the latest database values, shared memory, task status, and messages, then the system should have a coherent picture of the world.

Several developments this week challenge that assumption. New research showed that an agent can read fresh shared state while continuing to execute a plan derived from stale state. Another study found that tool-using agents often adopt corrupted tool outputs even when their internal reasoning notices the conflict. A third showed that authority may live outside the agent's visible workspace entirely.

The issue is becoming less about stale memory and more about keeping several different states aligned: evidence, plans, organizational decisions, authorization, and execution.

Fresh state can coexist with a stale plan

The paper Fresh Memory, Stale Plans starts with a simple multi-agent scenario.

A planner reads requirement r3 and generates a plan. Another agent later updates the shared requirement to r4. The executor receives the new shared state, so its memory is current.

The plan is still based on r3.

Conceptually:

state r3
   |
   v
plan P3
   |
   |      state changes to r4
   |             |
   |             v
   +------> executor sees r4
                 |
                 v
           still executes P3

The paper calls this stale-plan execution.

Its proposed PlanFence protocol does not revalidate the entire world before every action. Instead, a plan records which public records actually justify the pending external action. Before execution, the system checks those dependencies and replans or blocks only when something relevant changed.

That distinction matters.

If a CRM note changes, a pending procurement action may remain valid. If the privacy assessment used to approve a vendor expires, it may not.

The action needs to know why it exists

Consider a procurement agent.

At planning time, the case contains:

annual_spend = 42,000
privacy_assessment = current
security_status = passed

The organization approves the purchase and the agent prepares a purchase order.

Before execution, the state becomes:

annual_spend = 42,000
privacy_assessment = expired
security_status = passed

A conventional system may reload the current vendor record and still have no mechanism connecting privacy_assessment to the purchase order waiting in its queue.

The deeper requirement looks more like this:

pending action
    |
    +--> depends on evidence E
    +--> depends on policy P
    +--> depends on disposition D
    |
    v
validate dependencies before execution

This is not the same as keeping memory fresh.

It is preserving the justification chain of the action.

Current evidence can still be bad evidence

Another paper this week, Agents Trust Tools Too Much, attacks a different assumption.

Tool output often enters an agent context with an implicit upgrade in status. The model called a search engine, code interpreter, sub-agent, or another tool, so whatever came back starts to look like evidence.

The researchers deliberately corrupted tool outputs across 14 models. Mean adoption of corrupted content exceeded one third for every tested tool and reached 68% for web search.

One of the more interesting failure modes occurred when the model's internal reasoning noticed the contradiction and recovered the correct answer, but the final answer still repeated the corrupted tool result.

The model had enough information to notice the problem.

The system did not have a reliable rule for resolving it.

That suggests another important distinction:

tool returned X

is not equivalent to:

X is authoritative evidence

A source can be current but advisory. It can be trusted for one type of claim and not another. It can conflict with a stronger source. The tool itself can also be compromised.

Evidence freshness and evidence authority are separate properties.

Authority is another state entirely

Beyond Agent Harnesses: Cross-Substrate Authority for Multi-Agent Systems adds another layer.

An agent may have full visibility into its workspace while the authority needed to publish, approve, or mutate something lives in another registry, runtime, or approval service.

The paper's controlled experiments suggest that simply making authority information visible to the planner is not always sufficient. A deterministic guard at the mutation boundary still plays a separate role.

This gives us at least four questions:

What facts are currently available?

What decision follows from those facts?

Is the existing plan still justified?

Is this actor currently authorized to execute it?

A single language-model context can contain answers to all four.

That does not mean the model should become the final authority for all four.

Payment infrastructure is starting to encode this distinction

This week Visa, Mastercard, and Ant International announced a Know-Your-Agent interoperability initiative. India's National Payments Corporation is separately developing an agent registry for UPI.

The specific protocols are still evolving, but the direction is significant.

Agent identity and delegated transaction authority are becoming infrastructure.

Imagine an enterprise purchasing agent:

business disposition = approved
agent identity = verified
payment authority = 10,000
purchase amount = 15,000

The correct result is not:

business disposition = rejected

The business decision can remain valid.

Execution authorization fails independently.

Now reverse the example:

business disposition = review_required
agent identity = verified
payment authority = 50,000

The fact that the agent can spend the money should not manufacture a business approval.

This sounds obvious once the states are written separately. It becomes much less obvious when all of the rules are placed into one system prompt.

Control planes are becoming their own platform category

Salesforce's new enterprise AI architecture makes the market direction clearer.

Its Trusted Enterprise AI Harness spans context, agency, action, governance, security, and models. Salesforce is also building an AI Control Plane intended to discover agents, establish identity and policy, manage lifecycle, evaluate behavior, observe outcomes, and control costs across Salesforce and third-party AI environments.

Red Hat is moving in a similar direction through its enterprise AI stack and support for OpenClaw. Dedicated security companies are building identity and data-access graphs for both people and non-human agents.

Agent governance is no longer one missing feature.

It is becoming an infrastructure market.

That should influence how smaller governance projects define themselves.

Not every rule belongs in a judgment layer

Suppose we separate the architecture like this:

documents / APIs / tools
          |
          v
evidence acquisition
          |
          v
organizational judgment
          |
          v
plan
          |
          v
runtime authorization
          |
          v
execution

A tool security policy belongs close to tool execution.

A payment limit belongs in payment infrastructure.

Agent identity belongs in identity infrastructure.

Network restrictions belong in the runtime.

None of those needs to move into an organizational decision specification merely because they contain rules.

The possible role for something like the Judgment Pack Specification is narrower:

declared evidence
       |
       v
reviewed organizational criteria
       |
       v
disposition

For example:

privacy_assessment = expired
annual_spend = 42,000
security_status = passed

        |
        v

review_required

That disposition can then become one dependency of a plan.

Runtime authorization remains separate.

The harder problem is binding the decision to the action

If a judgment artifact produces:

approved

and an agent creates a purchase plan from that result, the plan should probably retain enough information to answer:

Which policy produced this result?

Which version?

Which evidence values mattered?

Which evidence sources were authoritative?

When was the decision evaluated?

Which action was this decision intended to justify?

A simplified representation might look like:

{
  "decision": {
    "policy": "vendor-review",
    "version": "1.4.2",
    "disposition": "approved"
  },
  "dependencies": {
    "privacy_assessment": {
      "value": "current",
      "source_version": "a821"
    },
    "annual_spend": {
      "value": 42000,
      "source_version": "f319"
    }
  },
  "action": {
    "type": "submit_purchase_order"
  }
}

Before execution, the system does not necessarily need to rerun everything.

It checks whether the dependencies capable of invalidating this action changed.

That is the PlanFence idea applied to an organizational decision boundary.

Human review should also be durable state

AWS's newly open-sourced Pizza Bot provides a practical interface pattern for this architecture.

Pizza Bot is designed around agents working asynchronously rather than keeping a human inside a live chat session. Completed items go into one inbox. Work requiring a decision stays in an Action queue. Approvals can persist across sessions.

That matters because review_required should probably be a durable workflow state.

It should not mean:

show a popup and hope a person is watching

It can instead mean:

decision = review_required

create durable review item

preserve evidence and decision path

wait for authorized human action

The approval interface remains an application responsibility.

The judgment mechanism only needs to explain why review was required.

Evaluation itself needs the same decomposition

The final lesson from this week comes from agent evaluation.

Interface-Induced Trajectory Censoring showed that a model can emit a valid tool call that disappears because the serving template and parser disagree. A downstream benchmark can then record zero tool use and attribute the behavior to the model.

The researchers released a small preflight test that sends a canonical tool call through the complete stack before the real benchmark begins.

Then BenchShield goes one level deeper by treating the benchmark itself as an attack surface. Interactive agents can inspect files, manipulate state, use tools, and potentially discover ways to improve their score without satisfying the intended task.

Together they imply another layered contract:

model evaluation
       |
       v
interface validation
       |
       v
trajectory integrity
       |
       v
benchmark integrity

A score only means what we think it means if those layers are working.

A practical experiment

A useful end-to-end experiment would combine the week's strongest ideas.

Start with a procurement case:

annual_spend = 42,000
privacy_assessment = current
security_status = passed

Evaluate the organizational rule and create a pending purchase.

Then introduce four changes.

Case 1: irrelevant evidence changes

A CRM comment changes.

Expected result:

decision remains valid
plan remains valid

Case 2: decision-critical evidence changes

The privacy assessment expires.

Expected result:

decision requires reevaluation
pending plan cannot execute

Case 3: authority changes

The business evidence remains identical, but the agent's payment limit drops below the purchase amount.

Expected result:

business disposition remains approved
execution authorization fails

Case 4: tool evidence conflicts

A search or sub-agent returns a new claim contradicting an authoritative system.

Expected result:

conflict becomes explicit
tool output does not silently replace authoritative evidence

Now change the model.

Change the runtime.

Move the workflow behind a different control plane.

The organization-owned decision semantics should move only when the evidence or reviewed policy changes.

If changing the infrastructure silently changes the business meaning, the layers were never truly separated.

The open question

Agent systems are becoming better at sharing memory, calling tools, running asynchronously, and coordinating across infrastructure.

The next reliability problem may be less about whether the agent remembers enough and more about whether every consequential action can answer a harder question:

What exact evidence, policy, authority, and decision still justify me right now?

If an agent cannot answer that, fresh context alone is not enough.