It was still written down
How we Organise
Cognitive capability profiling and which work should go to a machine
Prunty and four colleagues posted this on 26 August. They built two halves that meet on one vocabulary. The first infers what an AI system can do from a benchmark battery. Every item in it is annotated for the cognitive demands it makes. The second asks domain experts how much each of those same capabilities matters in their own work. Both sit on the same dimensions. Either can therefore be updated without redoing the other, and the two combine into a suitability estimate for a domain, a role or a single duty.
They validated capability recovery on synthetic agents, profiled six AI systems, and elicited requirements from 410 employees across six occupational domains. Two results came back. The systems differed more from each other across cognitive dimensions than they did across model families. The workplace activities converged on a shared cognitive core.
Our position asks a client to name the capabilities it means to keep exercisable without the machine, and to date each one the last time it was exercised. The list exists so a firm knows what it has kept.
Nothing here bears on whether such a list exists, only on the unit it is written in. If activities share a cognitive core, a list written activity by activity splits work that is cognitively the same and groups work that is not. A firm can hold a complete and freshly dated list and still not know what it has retained. We may have the level wrong rather than the practice. For the position to survive, the naming has to happen on the dimensions the profiling uses, and the date has to attach to the dimension rather than to the activity.
It is a preprint. Capability recovery is validated on synthetic agents rather than in a deployment. The requirements are experts’ stated importance rather than observed work, and six occupational domains are not the labour market. Somebody could reasonably read the shared cognitive core as an artefact of how the battery’s dimensions were drawn.
If it stands, a named and dated list of retained activities stops evidencing retained capability. We stop telling a client that it does. The client this reaches first is the one furthest along, with a complete list reviewed on a cadence, the strongest reason to believe it and the least reason to look again.
How we Build
What survives when an agent’s context is compacted
Zerhoudi, Mitrovic and Granitzer posted this on 24 August. A safety rule and an episodic log compete for the same tokens. When the budget overflows both are summarised at the same rate, and only the rule needs its exact wording to remain enforceable. Across 20 production agent configurations they measured what survives Claude Code’s compaction prompt on Sonnet 4.6. After one round, 53 per cent of safety rules. After five, 10 per cent. They call it the Compaction Cliff.
Their answer classifies each line of a knowledge base by type. Each type then gets its own retention policy, applied across the three ways context is managed: rewriting in place under a per-type fidelity bound, partitioning a topic too large to compact and replicating the in-scope rules into every partition, and fetching from storage with in-scope rules pinned ahead of relevance. On five public corpora the type-aware compactor preserved two to four times more rules at every ratio, with recall at 96 per cent over five rounds. Partitioning went to no locality violations, against 93 per cent under uniform partitioning. Retrieval reached full recall at fifty, against 73 per cent.
We ask that an agent’s context be budgeted. It states which sources are admitted, how stale each may be, what gets compacted when the window fills, and what survives. This is the first source we have seen to put a number on the last of those. The number argues with us.
Writing down what survives does not make it survive. The budget states an intention. The thing doing the compacting is a language model summarising lossily, with no notion of which lines carry authority. So the document can be complete and current while the rule it names has been paraphrased into something nobody could enforce. No release is cut and nothing alerts. Perhaps this does not belong to the budget at all, and we were wrong to put it there.
Again a preprint. The compactor tested is one vendor’s on one model, so 53 and 10 are readings rather than constants. A reasonable objection is that a safety rule belongs outside the context altogether and inside the harness, on which reading the practice is aimed at the wrong layer rather than strained.
Should that hold, a written context budget stops being evidence that anything named in it is still present. The practice needs a retention rule per type that the compaction step actually runs. It also needs a check that reads the rule back afterwards rather than reading the budget. A client running a long-lived agent on a policy in its system prompt has a claim about the first turn and nothing about the hundredth.
How we Assure
Separating what induced an action from what authorised it
Guo and seven colleagues posted this on 27 August. Tool outputs that stop supplying data and start specifying actions become commands, and the danger they name comes from treating an induced action as an authorised one. Their system splits the two. On the observation side a context-isolated probe exposes the action-inducing content in a tool’s return. It records where an action came from and carries that provenance across steps. On the execution side a tool call is authorised only against the user’s stated objective, and against audited evidence from earlier authorised runs that succeeded. Support has to hold at the level of the goal, the execution chain and the individual argument, and a rule called No-History-Promotion stops a recurring step from laundering its origin into authority. Across two agent benchmarks the attack success rate stayed at or below 0.63 per cent in four primary settings. Task utility held, and the result was consistent across other backbones.
An agent should act under its own scoped, short-lived credential, holding no more entitlement than the person who set it going and no more than the task in front of it needs. This is the second source in five days to argue that the second half of that cannot rest on a credential. The AADP Internet-Draft made the same point on 24 August from the other direction, that the state governing whether an action may run now moves after the credential is issued.
The task in front of the agent is not knowable when the credential is minted. It is settled at runtime by observations the credential never sees. So the entitlement test passes on every call while the agent does something outside what the user asked. We could be wrong here: this may be a second control sitting beside the position rather than a defect in how the position is stated.
Their evaluation runs on two benchmarks and is the authors’ own. An attack success rate is not an incident rate. The cost of an extra probe and an authorisation check on every call is not reported. Read another way, this is one more control rather than a correction.
The consequence is that we stop telling a client that a correctly scoped credential answers whether an action may run. Authorisation has to be a runtime decision carrying the objective and the action’s provenance, with the credential as its floor. The clients this reaches are the ones who finished the identity work and closed the question.