The bottleneck moved to the scaffolding

In a controlled run of concurrent coding agents sharing one task pool, the share of work that merely re-did a teammate’s task fell from 78% to 0%, and useful throughput more than tripled. That number, from Before the Pull Request: Mining Multi-Agent Coordination, is the cleanest evidence yet for a claim the field keeps circling: when autonomous agents fail together, the failure usually predates the pull request. Large studies show agent-authored PRs ship faster and get accepted less often, and PR-level telemetry can’t say why. Dipankar Sarkar’s answer is to instrument the step before the diff exists, the moment when concurrent agents claim, divide, and collide over shared work.

The mechanism is deliberately unglamorous. grite is a coordination substrate with no central server; it writes an append-only, signed event log directly inside git. Every agent’s copy converges to the same state with no write silently dropped, which is exactly where a plain file-based tracker fails, losing concurrent writes under contention. And because the log is structured and signed, it becomes a mineable artifact: conflicting edits, lock starvation, redundant rediscovery, and race-to-close are all automatically recoverable with provenance, several of them invisible in the PR history they eventually produce. The release ships the dataset, harness, and mining toolkit, so the failure taxonomy is reproducible rather than anecdotal.

That theme, state as a first-class thing rather than a byproduct, ran through almost everything fresh in the last day. OpenRath makes the argument structurally. Today’s agent systems scatter runtime state across transcripts, tool effects, memory events, workspace placement, branch provenance, and replay evidence, each recorded separately, none easy to inspect or reproduce. OpenRath’s pitch is a PyTorch-like programming model whose central abstraction is Session: the runtime value passed between agents and workflows, carrying conversation chunks, sandbox placement, lineage metadata, token usage, pending work, and tool evidence. Because that state rides the same value the program executes on, fork, merge, and replay stop being reconstructions from external logs and become explicit runtime operations. The authors are careful about scope, limiting their claims to controlled runtime properties and deferring quality comparisons, which reads as honest rather than thin given how many agent frameworks oversell. The thesis is narrow and useful: give the system one auditable value to compose around.

Where OpenRath governs state across sessions, PACMS arbitrates it within a single one. Its target is the default every framework still ships: recency truncation, sometimes with periodic summarization, deciding what to drop when the context window overflows. That policy is topic-blind. A fact established early gets discarded because it’s old, even when the current query is about exactly that fact, while verbose but irrelevant recent material survives. The cases where this hurts most, agents recalling information across many turns, are the defining case for memory. PACMS reframes the assembly step itself: treat memory entries, conversation turns, and tool outputs as one candidate pool, and run submodular selection over it by relevance at the moment the prompt is built. RAG fetches external documents but doesn’t arbitrate the context already present; compression shrinks token count query-blind and lossily. Selecting from the pooled context at assembly time is a different operation than either, and it’s the one most stacks skip.

The retrieval framing carries straight into memory infrastructure, where two industry write-ups landed real numbers. Elastic’s search-labs team described a persistent agent memory layer built on Elasticsearch hitting 0.89 recall with zero tenant leaks, and the second clause matters as much as the first: in multi-tenant agent deployments the failure that actually ends you is one tenant’s memory surfacing in another’s retrieval, not a missed hit. Recall is a tuning problem; leakage is a security boundary. Pairing the two as joint objectives is the right framing for anyone running agent memory in production rather than a notebook. Alongside it, Perplexity published Self-Improving Memory for Agents, arguing memory shouldn’t be a passive store the agent reads and writes but something that reorganizes itself from use. The two pieces bracket the open question in agent memory right now: how much structure to impose up front versus how much to let the system earn from its own traces.

Rounding out the day, SIGMA goes after a quieter limitation in multi-agent design. Graph-based multi-agent system builders mostly optimize communication topology over a fixed cast of agents, roles, or groups, and because each node stays a closed-set entity, they generalize poorly to tasks needing unseen combinations of capabilities. SIGMA’s skill-incidence graphs make capability the unit of composition instead of the agent, which is the right altitude if you believe the interesting systems are the ones assembled per-task rather than wired up once. It’s an early paper, but it names the constraint precisely: a multi-agent system that can only recombine roles it was given is a system that can’t surprise you.

What connects all six is that none of them is about the model. The coordination log, the Session value, the context selector, the memory index, the skill graph, these are the scaffolding around an agent, and a day where the freshest research clusters there says the bottleneck has moved. Worth watching whether grite’s in-git coordination log gets picked up the way AGENTS.md did, since a substrate only matters if more than one harness writes to it.