Build1 publisher2 min readPublished
PlanFence checks the records that justified an action before the agent executes it
A dev.to roundup reads three agent papers around one design question: what a pending action still depends on at the moment it fires. The strongest number in it is 68 percent, and it belongs to somebody else's corruption test.
The Engineer · Build desk
What happened
- The paper Fresh Memory, Stale Plans names stale-plan execution: a planner builds a plan from requirement r3, another agent updates the shared requirement to r4, and the executor reads r4 while still running the r3 plan.
- Its PlanFence protocol has a plan record which public records justify a pending external action, then checks only those dependencies before execution and replans or blocks when one of them changed.
- In Agents Trust Tools Too Much, researchers deliberately corrupted tool outputs across 14 models, and mean adoption of the corrupted content exceeded one third for every tool they tested.
- A third paper, Beyond Agent Harnesses, places the authority to publish, approve or mutate outside the agent's visible workspace, in a separate registry, runtime or approval service.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Writing the per-action dependency list becomes the design work: scope it too broadly and routine record edits block queued actions, too narrowly and an expired approval sails through.
- cost Retrofitting this onto a running agent requires stable identifiers for every record a plan cites and a rule for which kinds of change count as relevant, both of which fall on whoever owns the case data.
- decision When authorization sits in another service, the pre-execution check leaves the process, and someone has to decide whether a timeout blocks the action or lets it through.
- exposure Any harness that promotes a tool return to evidence on arrival inherits an adoption rate for wrong or tampered output wherever one of its tools can be compromised.
The hard part of PlanFence is deciding what goes in the dependency list. The roundup's own example: a changed CRM note can leave a pending procurement action valid, while an expiry on the privacy assessment used to approve the vendor may not [5]. Both are edits to the same vendor case. One should stop the purchase order and one should not, and somebody has to write that distinction down per action type, in a form the executor can evaluate at run time. A dependency list that names everything is a full revalidation with extra bookkeeping.
Recording dependencies means each pending action carries a set of record identifiers plus something to compare against, and the check before execution is a read per dependency [4]. The procurement walkthrough turns on one field. At planning time the case holds annual_spend 42,000, privacy_assessment current, security_status passed; before execution the same case holds annual_spend 42,000, privacy_assessment expired, security_status passed [6]. A conventional system reloads the vendor record, sees the new value, and has nothing that connects privacy_assessment to the purchase order sitting in its queue [7].
The tool-trust paper is where the numbers are, and they are numbers about the researchers' injected corruption. Mean adoption reached 68 percent for web search [8], which leaves roughly a third of those cases not adopting it [14]. For that rate to transfer, the injected content has to resemble what a wrong or compromised tool would actually return in your domain, and your harness has to lack an explicit rule for resolving a conflict between tool output and the model's prior.
The failure I would instrument first is the one the roundup singles out: the model's reasoning noticed the contradiction and recovered the correct answer, and the final answer repeated the corrupted tool result anyway [9]. Measure only final answers and that case is indistinguishable from a model that never noticed.
The post separates the two properties it thinks get conflated: "A source can be current but advisory" [10].
This is one weekly notes post reading three papers, it describes the PlanFence protocol without reporting evaluation numbers for it, and its account of the cross-substrate authority experiments breaks off mid-sentence [15][12]. The author discloses AI assistance in the writing: "I review the underlying sources, decide which developments and arguments are worth including, and edit the final piece before publishing" [13].
What to watch
- Whether the PlanFence authors publish per-action overhead and false-block rates, which the roundup does not report.
- Whether follow-up corruption work reports adoption separately for reasoning traces and final answers.
- Whether approval services and registries expose a dependency check an executor can query at action time.