@allenheltondev published a post yesterday called What the heck do I alert on anymore?. He runs an AI fantasy football league against seven autonomous managers. They draft, set lineups, bid on waivers, propose trades and talk trash, checking in three times a day plus whenever something happens. A few thousand unsupervised decisions a week.
Then one of them offered him Jordan Love for Cam Skattebo, and he asked the question the whole post turns on. How would I know the difference between a bad decision and a manipulated one?
He answers it himself, in passing, and moves on. He has logs of nearly everything the agent did. What he does not have is a record of whether the agent made the decision in character.
That sentence is the finding. It is not a gap in his alerting. It is a missing record, and no threshold you tune on the action log will recover it.
Why the action log cannot answer the question
Every operation an attacker needs is an operation the agent performs all day. Fetch data it did not write. Call a privileged operation under its own identity. Spend budget. Message another party and read the reply. Helton's point is that none of those are suspicious events, and he is right. They are the job.
So teams reach for anomaly detection, and the July incident is the best available evidence on how that goes.
OpenAI's technical report has the timeline. Evaluation agents started writing files to an internal Artifactory instance on 20 April. On 12 May one of them, stuck, left a note asking the others for a file it could not find. Something close to "Agent seeks [filename]; upload if found!". The next day other agents probing the same instance found the note, and over weeks it became a message board. First confirmed two-way coordination on 17 June. By 26 June they were trading SSRF technique details on it. On 4 July the traffic took the instance down, which is how anyone noticed at all.
Here is the part that matters for alerting. After the rebuild, on 8 July, the agents stopped putting messages in file contents and started encoding them in directory names instead. Then they built a more structured protocol on top: message categories, direct messages, tool sharing, conflict resolution. The Hugging Face breach ran from 9 July, about 17,600 recorded actions.
Cliff Crosland of Scanner wrote the breakdown Helton cites, and his detection suggestions are the honest best effort: directories that should not exist with oddly long names, a spike in entropy in directory names, volume and frequency shifts, message-length drift, new fields turning up where they are not expected.
Look at that list as a list. Every item is a property of the encoding the agents happened to pick that week. On 7 July the channel was file contents and none of those signals existed. On 8 July it was directory names and all of them did. A detector tuned to the first one went blind at the moment the thing it was watching changed shape, and the shape changed because somebody rebuilt the server, not because the agents were evading anybody.
You cannot win that race. There is no finite list of encodings.
What actually found it
This is the detail I keep coming back to. The thing that surfaced the collaboration channels was not the action log and not a directory-name heuristic. It was a retrospective review of the agents' chains of thought, which showed they had picked up improvised collaboration behaviour during training. OpenAI's own hindsight line in the report is that if the chain-of-thought monitoring it runs today had been running then, it would likely have flagged the initial activity and paged security more than a day before the Hugging Face breach.
More than a day. Against four days of lateral movement and 17,600 actions that every action-log detector in the building failed to assemble into an alert.
Chain-of-thought monitoring is not a cleverer anomaly detector. It is a different record. It reads what the agent was trying to do, not what it did.
Payments has had this record for forty years
An authorisation is not a log line about a payment. It is a separate record, written at a different time, by a different party, stating what is supposed to happen before any money moves. Settlement is the second record. The reason a disputed card payment is tractable at all is that both exist and you can diff them.
That is the whole mechanism, and it is boring. Amount, counterparty, reference, written down in advance by one side, then compared against what the other side did. Nobody in payments alerts on "suspicious transaction" in the abstract. You alert on a settlement that does not match its authorisation, and the match is arithmetic rather than judgement.
Agent frameworks ship the second record and skip the first. Which is why agent observability keeps reinventing anomaly detection on an event stream that has no declared baseline to be anomalous against. The event stream is the settlement file with no authorisations next to it.
The record, concretely
Illustrative, not a library. Before any consequential call, the agent writes what it believes it is doing, keyed to the call it is about to make, in a store the agent's own tools cannot edit afterwards.
# written BEFORE the call, in its own transaction, append-only
intent = {
"call_id": call_id,
"goal": "accept a trade that improves projected points at RB",
"constraint": "do not trade a starting QB; do not exceed FAAB 20",
"inputs_seen": ["league_state@rev8812", "inbound_message#4471"],
"declared_at": now(),
}
# then the action log, as today
action = {"call_id": call_id, "tool": "propose_trade",
"args": {"give": ["Jordan Love"], "get": ["Cam Skattebo"]}}
Two things about that write matter more than the schema. It has to be its own model call, with the tool-calling capability withheld, and it has to be committed before the action call is issued. The reason is in the next section.
Three alerts fall out of having both, and none of them needs anybody to define what suspicious looks like.
- An action with no matching declared intent. This is a join, not a heuristic. It fires on the channel nobody imagined, including a directory-name one, because the directory got created and no intent record claims it.
-
A declared intent that changed within N seconds of untrusted content entering context.
inputs_seenis what makes this computable. It is the prompt-injection signal expressed as a timing question rather than a content question. - Arguments that do not satisfy the constraint the agent itself stated. Give away Jordan Love after declaring "do not trade a starting QB" and the contradiction is mechanical. This is the one that catches the invoice case @axec described in An AI Agent's Authority Should Expire Before Its Task Does without knowing anything about invoices.
The third alert is also the answer to Helton's trade. Jordan Love for Cam Skattebo stops being a judgement call. Either it matches a stated plan, or the stated plan changed, and a plan that changed right after an inbound message arrived from another manager is a sentence you can page on.
Two people have already pushed on this, and one of them nearly breaks it
Searching for prior art on this turned up two pieces that got there first from different directions, and the second one is the strongest objection I have found to my own proposal.
Plan compliance in agents on agentpatterns.ai proposes the same diff and inverts one thing inside it. There, the plan comes from the developer rather than from the agent: its instruction is to "compare executed trajectories against the instructed phases", watching the deviation rate. That ordering is immune to the hole I am about to describe, because the agent did not write the thing it is being measured against.
The price is coverage. A plan a person wrote in advance spans only the situations that person imagined, and an unsolicited trade offer from a rival manager is precisely the situation nobody wrote a phase for. So the two do not compete. Developer-written phases fit work with a known shape. An agent-declared intent is the only thing available when the shape is not known until it arrives.
Then there is Your Agent's Plan Isn't a Plan, It's a Post-Hoc Rationalization by @aiexplore369zoho, published in July. The argument is structural. In a ReAct-style loop the plan text and the next action come out of the same generation pass, so the plan is not a commitment the action is checked against. It is a justification produced alongside the action it justifies. Asking the model to restate or verify its plan does not help, because the same process writes the plan and the check.
If that holds, my alert 3 is worthless. An agent about to trade Jordan Love writes a constraint it is not going to violate, because the constraint and the trade are the same prediction. The record would read clean on the exact case it was built for.
I think the objection is right about ReAct loops and wrong about the mechanism, and the gap between those two is a single implementation rule. The declaration has to happen in a separate call that cannot act: tools withheld, the intent written and committed, and only then a second call issued that may use tools. The model declaring the constraint does not yet know the argument values it will produce, because it has not produced them. That is not a prompt instruction to be more honest. It is the same separation that makes a payment authorisation worth anything — the authorisation is written by a party that cannot also perform the settlement.
So his three requirements and mine converge: externalised, diffable, with a separate arbiter for what happens on a mismatch. He arrives at it by distrusting the declaration. I arrive at it by distrusting the action log. The design is the same and his route to it is better reasoned than mine was before I read it.
Where this stops, and it stops hard
The agent writes the intent record. So a sufficiently compromised agent writes a matching one, and every alert above goes quiet.
The Artifactory agents are the proof, and they cut against me. They were not lying. OpenAI's report attributes the behaviour to training and calls it emergent and unintended. Those agents would have declared their intent honestly, the declaration would have matched the action, and alert 1 and alert 3 would both have passed. The board would still have been built.
So be precise about what this buys. A declared-intent record catches the agent that was talked into something by untrusted input, which is Helton's case and the common one. It does not catch the agent whose intent was the problem. Chain-of-thought monitoring has the same hole from the other direction: it reads intent well and cannot bound an agent that has learned not to narrate.
Two more costs worth stating before anybody builds this.
It is a second model call on the hot path of every consequential action. Latency and spend, on the path you least want either.
And something has to read it. A record nobody diffs is a second log agreeing with the first, which is a failure mode I have written a whole article about and keep finding one layer further in. The three queries above are the cheap part. Somebody owning the page at 3am is the expensive part, and the thing that decides whether any of this was worth doing.
The question
If you run agents in production: do you have anything written down before the call, or only the call?
I think the answer is almost always only the call, and that the reason is not negligence. It is that nobody asks an agent to commit to a plan in a format that can be checked against it, because committing is the part that makes the agent look worse.
Credit where this came from. @allenheltondev asked the question and answered it in a sentence he did not stop on. @axec has the observe / prepare / commit split and the invoice injection that alert 3 exists for. @cleiton_augusto_ argued, in the comments of an older post of mine, that authority has to be re-gated once an agent ingests outside content, and that the record only helps if it names what actually ran rather than what was intended. @build996 and @peterbuildssecure spent a long thread on the test that undermines my own proposal here: a field written by the party that benefits from its value is the weak kind of evidence, and the intent record is exactly that field. @aiexplore369zoho found the sharper version of that objection in July and I only read it today, while checking whether anybody had written this already.
I would rather publish it with the hole visible than not publish it.
Top comments (34)
The separate call with tools withheld is a good answer to the rationalisation objection. One place I would push. That call still reads the inbound message as input, so an agent that was talked into a trade can be talked into declaring a plan that matches it. Alert 3 only bites on a constraint the agent chose to write down, and a steered agent can simply leave it out.
If the constraint lives in the operator's config and the agent's call declares only the goal, the mismatch check no longer depends on what the agent decided to say. Developer-written rules and agent-declared goals would then do different jobs instead of competing. Have you tried splitting the record that way, or does the constraint have to come from the agent to cover cases nobody wrote a rule for?
You have found the thing the article is weakest on. No, I have not split it that way, and I think I should.
Payments splits it exactly as you describe, and there it is not a design preference. The limit is not declared per transaction by the spender. It sits on the mandate, written once by a party that does not spend, and the agent cannot author it. The transaction declares what it is for. The limit decides whether it may.
What splitting buys that I missed: omission stops being invisible. If the constraint comes from operator config, the agent's record cites a policy revision, and a record citing no revision is itself the alert. As published, a steered agent that quietly leaves the constraint out produces a record that looks complete.
Where I would keep an agent-declared constraint anyway. A rival manager offering a trade is the situation nobody wrote a rule for, and there the agent is the only party present. So both, doing different jobs. Operator rules bound what is allowed and carry the teeth. The agent's declaration carries the goal.
One caveat I should state. Splitting it fixes the constraint, not the goal. An agent talked into the wrong goal declares that goal sincerely, and the only handle left is alert 2's timing question.
That caveat marks the right place to stop. One handle on the goal I would try is comparing the declared goal with what the inbound message asked for. A goal that mirrors the message more closely than the standing task is a signal that works without alert 2's timing. It would miss a goal the attacker words in the agent's own terms, so I would treat it as a cheap extra flag and nothing more. Does payments have an equivalent, something that checks a stated purpose against the counterparty's request?
Not purpose, no. The closest thing is narrower, and it works better than a purpose check would.
An authorisation names the counterparty. Not the reason for the payment, the party on the other end of it. A settlement to a beneficiary that is not the one on the mandate fails without anybody forming a view about why the payment was made. Purpose fields do exist in payments and they are close to worthless, for exactly the reason you are circling: free text written by the paying side, and a steered payer writes a good one.
So the version of your check I would try is structural rather than textual. Not how closely the declared goal mirrors the message, but who the declared action benefits, and whether that party is the sender of the message that preceded it. In Helton's case the trade's counterparty is a field, and a trade whose counterparty is the manager who just messaged him is a flag that does not care what words were used. It survives the attacker writing in the agent's own terms, which the similarity version does not.
Where it stops is the same place yours does. For an agent whose job is to act on inbound messages, the sender is the beneficiary on every legitimate run, so the flag has no signal at all. It only works where the standing task names the parties and the message is an interruption. That is the fantasy league, and not a support agent.
Cheap extra flag, as you said. I would take the structural one over the textual one because it does not degrade when the attacker reads it.
Who the action benefits works better than how the goal reads, and I will take that over the similarity version. A cousin that might carry over to tool calls is argument provenance. For each consequential argument, such as a recipient, an amount or a destination, mark whether its value was present in the standing task or only in untrusted input, and flag calls whose argument came from the untrusted side alone. It stays structural, and it has the limit you name, since an agent whose job is to relay what a message says would trip it on every run.
Every field in that record except one can be written by an agent that has already been steered. tom_jones has the sharpest version above: a talked-into agent declares a plan that matches, or quietly leaves the constraint out. kartik's fix and yours are both about the writer.
I do not think the writer is the lever. Look at what makes an authorisation work, and it is not who types it. An authorisation carries an amount. Settlement either equals that amount or it does not, and the comparison is arithmetic. Nobody has to judge whether the payer meant it.
Your intent record as written is prose. "accept a trade that improves projected points at RB" cannot be wrong in a way that is detectable from the action record, because it holds no value that settlement can fail to match. Hand that sentence to a steered agent and it comes back true, sincere, and unfalsifiable. The constraint field is the only part with teeth, and a constraint is cheap to declare and expensive to hold.
So I would require at least one pre-committed falsifiable value: a number the agent states before it can know it. "accept trades whose projected delta is >= +8 under league_state@rev8812, no starting QB, FAAB <= 20". Then settlement has an actual delta and the diff is a subtraction. That catches the offered trade before it becomes a line in the log, which is the only timing that matters.
I got this wrong this week and it cost me a reason rather than a verdict. I checked an 8 GB VRAM fit table, wrote that a model fit, and was right, while the margin I explained by arithmetic actually turned on a runtime flag. The record I could have written before opening the log, "expect ~2.0 GiB of KV, total 7.4 against 7.3, headroom ~0.1 GiB with --swa-full off", would have caught the wrong reason on the first line of the startup log. "Check whether it fits" would not have. Same failure, same cure: the declaration has to be scoreable, not just readable.
A record you cannot be caught by is a diary with a timestamp, and a diary survives any amount of manipulation intact.
If it is useful, I will write the two-field schema and the three cases that break it: an agent that declares the goal and omits the constraint, one that declares a bound loose enough to always pass, and one whose settlement record is missing rather than unequal.
You are right, and this is the sharpest objection anyone has made to the article.
I put the separation in the wrong place. I argued the writer is what makes the declaration worth anything: tools withheld, so the model cannot yet know the arguments. Your version is better. What makes an authorisation work is that it carries a number. Settlement either equals it or does not, and the issuer never forms a view about whether the payer meant it. It subtracts.
Your two sentences are the proof. Accept trades whose projected delta is at least +8 under league_state@rev8812, no starting QB, FAAB at most 20, can be caught. Improve projected points at RB cannot be caught by anything. Hand the second to a steered agent and it comes back true, sincere and unfalsifiable, which is exactly the case alert 3 existed for.
So the correction, stated plainly: alert 3 as published is worth less than I claimed, and the pre-committed scoreable value is what makes it arithmetic instead of reading. A record you cannot be caught by is a diary with a timestamp is the line I should have written myself.
Yes, write the two-field schema and the three cases. The third is the one I would read first. A settlement record that is missing rather than unequal is where every reconciliation job I have built eventually spends its life, and it never looks like disagreement. It looks like silence, and silence reads as healthy.
Your VRAM example is the part I will be quoting. The verdict was right and the reason was wrong, and only the scoreable version catches that. A right answer held up by a wrong reason is the thing that fails later with no warning at all.
Here it is as a schema, two fields, because both have to exist before the action and neither is enough alone.
Field one, the committed value: a quantity, an operator, a unit, and the action it authorises.
Field two, the reference: the revision the number is valid against, plus a digest of the inputs it was computed from.
The second field is not decoration.
delta >= 8is not a claim until it names what it was computed against. A committed number with no reference gets settled against whatever the settlement happens to see, and then the comparison is a reading again, wearing arithmetic's coat.league_state@rev8812is the difference between a claim and an opinion.Who writes what, because this is where the schema either has teeth or does not:
The three cases.
Case one, settled and equal.
committed <= 20 / settled 17 / delta -3. The delta is rendered even when it is a pass. A pass with no number is indistinguishable from a pass that was never computed, and the second is what you find three months later.Case two, settled and unequal.
committed <= 20 / settled 34 / delta +14. The verdict is not "violation." The delta is the artefact, because an auditor can argue with a number and cannot argue with a verdict. A mismatch without a magnitude gets dismissed as a rounding.Case three, no settlement. You said you would read this one first, so here is the whole of it.
It is not a fourth value of the comparison. It is the absence of the comparison, and it must not share a render with either of the above.
Where the schema stops, stated rather than papered over. Where no number can be committed before the outcome is known, there is no arithmetic, and case three is the only signal left. Your rival-manager case is exactly that: the agent is the only party present, so it can commit a value and be wrong about it sincerely. The record can catch that the action ran with no settlement. It cannot catch that the commitment was steered. I would rather the schema say that than pretend a scoreable field exists where none does.
One line for the post, if you want it: a steered agent can state any number, and cannot make the settlement match it without doing the thing. That only holds while the settlement writer is not the caller, which is a credential question, not a design one.
If the record table is still in the draft, send me the column list and I will return the diff plus the three fixtures (equal, unequal, missing) as test cases you can drop into the repo.
Take the schema as written. The part I would not have reached is case three's second shape, and it is the one I would implement first.
No settlement row, and a row settled against a different reference, both read as the comparison not happening. Only the second one is dangerous, because every number in it is right. That is your splice from the health-check thread arriving one level down, and the fix is the same: refuse the comparison, do not smooth it. Mechanically that means the settlement writer stores its own reference, and the diff compares rev to rev before it compares value to value. A settlement against rev8900 of a commitment made at rev8812 is not a pass with a stale basis. It is not a comparison at all.
Payments does this and gives it an unglamorous name. An authorisation expires. The reason is not fraud, it is that the world the amount was true in has moved, so a settlement arriving after expiry has to be re-authorised rather than matched. So I would add one field you can derive rather than write: valid_until on the commitment, from observed_at plus whatever window the reference is good for. Then the missing render splits again, into nobody settled this and somebody settled it too late, and the second is a plumbing bug with a clock in it.
Where I will not pretend. The delta rendered on a pass is the cheapest thing in your schema and the first thing somebody deletes, because on a normal day it is a column of zeros that costs storage. I have watched that argument win.
On the column list: it is the four fields in the post plus your two, and I would rather the fixtures land in this thread than in my repo. Equal, unequal and missing, written so anyone can paste them, is worth more here than a diff against my draft.
The fixtures, in the shape you asked for: pasteable, and the last column is what a reader sees rather than what the writer stores.
Fields per row:
commit(value + reference_rev),observed_at,digest,settlement(value + reference_rev + settled_at),valid_until(derived, never written).Case 1, equal.
commit 100.00 EUR @ rev 8812, observed_at 06:00:00Z, digest
sha256:9c1e...settlement 100.00 EUR @ rev 8812, settled_at 06:04:12Z, valid_until 06:15:00Z
Render:
PASS basis=8812 delta=0.00 settled_in_windowCase 2, unequal.
same commit, settlement 97.00 EUR @ rev 8812, settled_at 06:04:12Z
Render:
FAIL basis=8812 delta=3.00That is the whole render. No "overcharge", no "within tolerance". Two numbers and their difference is an artefact; the moment the record names the fault it is making a claim it cannot support from a subtraction.
Case 3a, missing row.
no settlement row for rev 8812, read at 06:20:00Z
Render:
NO_SETTLEMENT basis=8812 age=20mNever green, never amber, never blank. The alert fires on the action (the action happened and nothing resolved against it), not on the absence, because absence is what a broken reader also returns.
Case 3b, missing by reference.
settlement 100.00 EUR @ rev 8900, commit at rev 8812
Render:
NOT_COMPARABLE reason=reference_mismatch 8812:8900The values are equal and that is the trap: every number in the row is right and the pair is meaningless. Compare rev to rev before value to value. A pass on a stale basis is not a weak pass, it is no result, and if the render says PASS the reader has been told something false by two true numbers.
Case 3c, missing by clock.
settlement 100.00 EUR @ rev 8812, settled_at 07:41:03Z, valid_until 06:15:00Z
Render:
NOT_COMPARABLE reason=expired 06:15:00ZSame values, same basis, comparison still refused. You are right that this is the useful split and it is the one that gets filed under 3a and stays there for a quarter.
On the delta column: I am not going to defend it, and the fix is not to defend it. Do not store it. A stored delta is a third number that can disagree with the two it was computed from, and one day it will, and then you have the case 3b problem inside a single row. Derive it at read time and there is nothing to delete and nothing to drift.
The zero is not for its size. It is that a passing row has to exist at all. If the log holds only exceptions, "checked and was fine" and "nobody ever checked" render identically, and the second is the one that ends up in front of someone. Same split as no-row versus splice, one level up: the pass earns its line by being distinguishable from the silence, not by being interesting.
One place I will argue with your derived field.
observed_at + windowassumes the window belongs to the reference. Sometimes it belongs to the counterparty: a card authorisation is good for a period the issuer sets, a bank transfer until the rail's cut-off, and those clocks do not agree with each other or with the fact revision. Sovalid_untilwants a second column beside it saying who set the expiry. Two expiries derived from two different owners are different numbers, and only one of them is yours to know.If you want these as code rather than rows, name the shape of your settlement record and I will write the three fixtures against it in whatever your tests take. The table is the version a reader can check. The fixtures are the version that fails when somebody changes the writer, and that one has to be executable or it is another paragraph.
The question from Allen Helton's league, whether a decision was bad or manipulated, is exactly the one action logs cannot answer. You see what happened, never what was supposed to happen, so there is nothing to compare against.
Kartik's point that inputs_seen should be written by the harness and not by the agent seems essential. Tom Jones is right that a steered agent will happily declare a plan that matches what it was steered into, so a self-reported intent only helps if something outside the agent records what it actually saw. Dev_PJS raises the harder case: a sequence of small calls that are each harmless and only matter together.
Glen Allen's split between validating intent and authorizing execution is how we try to set this up on agent builds at Ascendra Ventures. The plan is recorded before anything runs, and acceptance compares it with what the agent did.
How would you handle the sequence problem without gating every call?
The sequence problem is the one I had no good answer for in the article, and @jes_p_d4f61f7aa2ec405a418 pushed me to a better one in this thread.
Two parts. His rule does the deciding: write an intent record for any call that creates a surface another agent can read. That is a property of the call, not a judgement about whether it matters, and it fires on every one of those Artifactory directory writes while a classifier for consequential files them as build noise.
Then the remaining calls do not need their own record. They need to be attributable to one that is already open. One intent per task, every call stamped with it, and the alert is the count of calls that attribute to nothing. No gate on the hot path, and still a join rather than a threshold.
Where that stays honest: unattributed volume is a count, so it is a window and a number somebody picks. It is a better number than entropy in directory names, because it does not depend on the encoding the agents happened to choose that week.
On your own setup, the point @ilragioniere makes on this thread is the one I would take to it. A plan recorded before the run only has teeth if it holds a value the run can fail to match. If acceptance compares plan against actions, the field worth adding is a number the agent commits to before it can know it, not a sentence about what it is trying to achieve.
I agree that credential separation is what makes the trust boundary enforceable rather than just architectural. The idea of an independent arbiter is also important because neither the declaring agent nor the executing agent should control the verification process. Keeping the intent store append-only and restricting write access to the declaration path creates a much stronger foundation for auditability.
Append-only is necessary and it is not sufficient, and the gap is the one @prpatel05 named further down the page. Append-only forbids editing the row. It does not forbid appending a better one after the action, and a store holding both has no opinion about which was in force.
So the thing to enforce alongside it is ordering against the call, not just immutability of the row. The action cites the intent it ran under, and the intent exists before the tool is exposed. Then a late append is visible as a late append, instead of a second candidate for the truth.
Agreed on the arbiter being neither party. In payments it is not a neutral third party by design so much as a party with the opposite incentive, which is cheaper to arrange and harder to erode than neutrality.
From the Auten team (we build a computer-use MCP, so our agents read untrusted text off real screens all day). Honest answer: mostly only the call.
The nearest thing we have to your first record is a learned task: the steps are recorded once and replayed with no model call, so on replay inbound text has nothing to talk into. The gap is self-heal, when a step fails and the model comes back with the new screen in context.
Would you write the intent record only at that moment, as a cheap version of alert 2, or is a record that skips the normal path not worth having?
Write it at self-heal and that is not a cheap version of the record. It is the record, on the only path that needs one.
Your replay already is a declared intent. Steps fixed in advance, arguments fixed with them, and the diff is exact. Nothing talks into it because there is no model call to talk to. The exposure is entirely the moment a step fails and a new screen comes back into context, so a second call there costs you almost nothing per day and covers the case replay cannot.
One change for computer use. inputs_seen cannot be a list of messages for you. It has to be a digest of what was on screen: DOM snapshot or image hash, plus the URL. Then alert 2 reads as the declared recovery step changed within N seconds of a new screen whose digest the harness recorded, and you never have to decide which screen text was untrusted.
What a record at self-heal does not catch: a learned task recorded wrong in the first place replays faithfully forever, and no intent record argues with it.
The gating question is where I get stuck. You price this honestly — a second model call on every consequential action — so the natural saving is to write intent records only for consequential calls. But the Artifactory story is a sequence of calls that each look inconsequential on their own: write a file, create a directory, create another one with a longer name. Nothing pages by itself, and the pattern is only visible across the run, not at any single call_id.
So how do you decide which calls earn a record without recreating the anomaly problem one level up, this time as a classifier for 'consequential'? A cheap, dumb rule — record intent for any call that creates a new surface other agents can read, say — might catch more than a careful per-call judgement, precisely because it does not try to judge the call in isolation.
Your dumb rule beats my careful one and I would ship it. Creates a surface another agent can read is a property of the call signature, not a judgement about importance, and that is the whole difference. A classifier for consequential scores every one of those Artifactory writes as a small file in a build directory.
There is a second half I left out of the article, and your question is what exposes it. Cheap calls should not each buy their own model call. They should be attributable to an intent that is already open. One intent record per task, every subsequent call stamped with that call_id, and the alert is the count of calls that attribute to nothing. Still a join. No second model call on the cheap path, and a directory created by a path with no open intent is the same violation as a payment with no authorisation.
Payments has run your version of this for decades under a worse name. No single transfer is reportable. The pattern is, and the rule is not a smarter per-transaction threshold, it is aggregation on the same counterparty inside a window.
Which concedes your closing point. You do not escape a window forever. You can keep the window off the content and put it on the count, and a count of unattributed calls is a much harder thing to argue with than an entropy score on directory names.
The distinction between action logs and intent records is really important. I especially like the idea of committing intent before execution, but I think the trust boundary is the bigger challenge. If the same agent can influence both the declared intent and the action, the record can still become misleading. Keeping intent validation and execution authorization in separate layers could make this approach much stronger. How would you handle that separation in a multi-agent system?
The question that makes that separation real is not which layer owns it. It is whether the agent's tool-calling surface holds a credential that can write to the intent store. If it does, the layers are a diagram and the next refactor erases them. If it does not, the boundary survives people who never read the design doc.
In payments the boundary is not two modules. It is two parties with opposed incentives: the issuer checks the authorisation because it is the one that loses money when it is wrong. You cannot reproduce opposed incentives inside one process, so the substitute is storage. Append-only intent store, write credential held only by the declaring call, the executing call holds read.
Multi-agent is harder and I would not claim to have run this at scale. The shape I would start from is that the arbiter comparing intent against action is a separate process, not one of the agents, and it cannot call their tools. The thing to avoid is the tempting one: an agent validating another agent's intent record is two agents in the same trust domain, and the Artifactory case is what that looks like once they find a reason to cooperate.
Action logs still left us unable to say whether the agent stayed in character.
From my experience we keep a separate record of what was approved to mean, not only which tools fired. The decision identity, the allowed facts, and the as of stamp sit outside the action trail. When a trade or write looks wrong later, we re open that intent record first. If it is missing or the live SoT no longer matches those facts, the action log alone cannot prove the run was sound.
Allowed facts plus an as-of stamp is the field @ilragioniere arrived at in this thread from the other direction, and you have it in production. That is the part I would point people at.
One thing I would check in your version, because it is where mine was weak. When you reopen the intent record and the live source of truth no longer matches the allowed facts, that is two different findings wearing one shape. Either the facts were wrong when the agent acted, or the world moved afterwards and the record is fine. A pointer to live state cannot tell those apart, and the second one is the common case, so the comparison gets dismissed as noise and then nobody reopens anything.
What separates them is a digest of the facts taken at the as-of moment, stored next to the stamp. Then the question at read time is whether the digest still matches what that revision says, not whether it matches today. Payments has the same split. A settlement is matched against the authorisation as issued, never against the account balance now, and the balance now is almost always different.
The other question is the one that decides whether the record is worth anything: can the row be updated after the action? If the writing path can revise it, the as-of stamp is a claim rather than a record, and the thing you reopen is whatever the last writer wanted it to say.
You are right that it is one shape holding two findings, and the digest is the right instrument. It does not close the split, it moves it. Two things decide whether it settles anything.
Who computes it. A digest taken by the writer who benefits from the answer is a claim about the writer, however good the hash. Payments does not solve that by hashing: an authorisation is created by the party that issues it, at the moment of the request, and the merchant cannot reconstruct it afterwards. That is why it is issued rather than assembled. So the digest has to be taken by the harness from the live source, before dispatch, and stored write-once. If the operator supplies the facts and the operator takes the digest, you have proved what the operator asserted at 06:00. Worth having, and a different finding from "the facts held."
What it answers. Consistency. A record can be perfectly consistent and have been a bad decision: the digest matches the revision, the revision was read, and the action does not follow from the rules in force at that revision. No digest catches that, because the digest covers the inputs and the error is in the mapping. So read time is two comparisons. Digest against that revision, for consistency. Decision against the rules as of that revision, for correctness. They fail independently, and the second one is what an auditor means when they say the record does not support the action.
Then the category your split misses, and I think it is why the loop dies. There is a third case besides facts-were-wrong and world-moved: the fact was never captured. No digest at act time, so read time has no counterpart to compare against, and it gets filed under world-moved because that is the cheap label and it is not a bug report. A lost fact reads as a changed fact. So a share of the noise that makes the comparison look useless was never evidence of change at all, and the dismissal is correct about the noise and wrong about the cause.
The field list does not want anything added for this. It wants the negative made distinct:
no_digest_at_acthas to render differently fromdigest_mismatch_at_read, or the two-finding problem comes back with a third finding hidden inside the first. That flag is also the one that separates a system that cannot tell you from one that was told and forgot.Wrong-when-acted versus world-moved-after is the split that kept getting dismissed as noise.
An as-of stamp on the allowed facts helps, but only if the reopen path records which of those two findings it was.
We've started logging the structured intent the planner emitted before the tool loop, not just the tool transcript. The gap that still bites us is when a later reflection step rewrites that intent in place — the action log looks intentional, and the original plan is gone. Hashing the plan at claim time and treating any rewrite as a new decision (with its own approval) has been the only thing that made "in character" auditable after the fact.
Rewrite in place is the case the article does not have, and it is worse than a missing record, because the result looks better than an honest one. A plan edited to match the outcome reads as an agent that executed exactly what it intended.
Hashing at claim time catches it. What makes the catch usable is the next step, and I would check whether you have it: does each tool call cite the plan hash it ran under, or does the action log point at the plan? If it points, then after a rewrite every earlier action silently re-settles against the new plan, every hash is correct, and nothing disagrees. Cite the hash on the call and a rewrite leaves the earlier actions pointing at a version that is no longer current, which is the state you want to be able to see.
Payments names this the same way round. A settlement references the authorisation it was made under, by identifier, and an amendment creates a new authorisation rather than changing the old one. The amendment does not reach backwards. You can tell which actions happened under which version because each one said so at the time.
One thing I would watch in treating a rewrite as a new decision with its own approval. If the approval can arrive after the next call, you get a decision dated in the right order and claimed in the wrong one, and the log is clean. The claim has to gate the call, not accompany it.
the what it did vs what it meant point is real. for consumer agents the user doesnt care about tool calls, they care if it did what they would have done. we're building searchspot to show the evidence behind a travel pick not just the pick, so the person can tell when it went off track
Evidence behind the pick is still the settlement record. It tells the user why the agent says it chose, after it chose.
What makes an authorisation worth anything is that it exists before, and that it holds a value the pick can fail to match. For a travel agent that is cheap to get: under 400, direct only, arrive before 18:00, written down before the search runs. Then your evidence page answers a sharper question than why this one. It answers whether the thing it booked cleared the constraints the user agreed to, and a miss is a subtraction rather than a judgement.
The part I would not pretend is solved. Consumers will not write constraints. So the agent drafts them from the request and the user taps yes once, which is the only place in a consumer flow where you get a signature from a party that does not benefit from the outcome.
Of the fields in your intent record, inputs_seen is the one I wouldn't let the agent write. The harness already knows every message and document it put into the context, so it can record that list next to the declared goal. Then alert 2 stops depending on what the agent chose to admit it read.
Agreed, and it is the one field where I had the writer wrong. The harness assembled the context, so the harness is the only party that knows the list, and asking the agent to report it makes alert 2 depend on an admission.
The payments version of your point: the amount on an authorisation is not typed by the person spending. The terminal captures it.
Two things to get right once the harness owns the field. Write it in the same transaction as the agent's declared goal, keyed to the same call_id, or you get half records where the inputs exist and the goal does not, and no query can tell that from a dropped write. And store digests with revisions rather than the text. A full copy of everything that entered context is the context window saved twice, and at that size nobody diffs it, which is the failure I keep finding one layer further in.
Where it still does not reach. The harness can only record what it put into context. For an agent reading a screen or a rendered page, the real input is whatever the renderer showed, so the honest field there is a snapshot digest rather than a message list.