Make the Model's Judgment Small, Make Everything Around It Boring

CodeRabbit’s agentic reviews get rejected 56.3% of the time. That’s the headline number from a new empirical study mining 31,073 code-review-to-feedback pairs across 10,191 pull requests and 239 GitHub repositories (arxiv.org/abs/2607.03316). Only 36.4% of comments were accepted outright, and the rejections cluster in a predictable place: false positives, redundant suggestions, and comments that miss the developer’s actual intent. The agent also skews toward functional nitpicks over evolvability concerns, and those functional comments are the ones more likely to be wrong. The authors trained a lightweight classifier to predict which reviews will get rejected before a human ever reads them, and it hits 76% F1 — evidence that rejection has a learnable signature, which means the reviewer’s failure mode is systematic rather than random noise.

Systematic failure is exactly the problem a production ESG-analytics team describes solving by giving up on a different goal entirely. In a write-up posted to r/LLMDevs, an engineer running a multi-agent system for two years lays out the reframe that changed their architecture: stop trying to make the LLM deterministic, and make the orchestration around it deterministic instead (reddit.com/r/LLMDevs/comments/1v48jc6). Concretely, the planner emits a typed task graph, a contract of what it wants rather than how to get it, and can’t reach into a worker’s internals. Tasks sit on durable queues, so a worker dying mid-task isn’t a recovery problem, it just waits for the next consumer to pick it up; no in-process state to lose. The aggregator pre-registers the expected task set before dispatch, so it never synthesizes an answer early or hangs waiting on a task that was never sent. The stochasticity gets quarantined to the workers, where judgment is actually wanted, while the control plane stays boring by design. The one gap the author admits to: the planner’s emitted task list currently has no validating schema before dispatch, the same class of problem CodeRabbit’s study surfaces from the other direction, ungated model output reaching downstream consumers.

AWS just shipped infrastructure that formalizes half of that pattern. The Lambda Durable Execution SDK for .NET went GA this week, giving C# developers checkpointed, resumable workflows without hand-rolling progress tracking or bolting on an external orchestrator (aws.amazon.com/about-aws/whats-new/2026/07/lambdadf-dotnet). Executions can pause for up to a year waiting on an external event, which is squarely aimed at human-in-the-loop and agent-in-the-loop approval steps, and it ships with a local testing emulator so you can debug the durable path before it’s live. AWS names “AI agent orchestration” directly as a target workload alongside payment pipelines, which says something about where the cloud vendors think this category is heading: durable execution as a primitive, not a library you assemble yourself.

The orchestration layer itself is also getting its own optimization target. Most multi-agent research tunes for task accuracy or token cost and treats latency as a byproduct; a new framework called LAMaS argues that’s backwards, because end-to-end latency is governed by the critical execution path, not total cost, so cutting cost doesn’t reliably cut latency (arxiv.org/abs/2607.13359). LAMaS learns latency-aware execution graphs at training time with critical-path credit assignment, then adds a lightweight runtime controller that prunes redundant future agent calls as execution unfolds, since a graph committed during training can’t react to what’s actually happening at inference. Across four benchmarks it cuts end-to-end latency by more than 50% while holding accuracy steady, and the authors report it transfers to other multi-agent systems with minimal changes.

On the evals side, Tencent released WorkBuddy Bench, a coding-agent benchmark built specifically to resist contamination (arxiv.org/abs/2607.20911). Instead of adapting public issue text, every task is reverse-engineered from a real commit, PR, or business scenario and rewritten as a short, colloquial request, so the prompt can’t be traced back to its source material by search engine. It spans four domains, repository engineering, front-end, office workflows, and red/blue-team security, each with its own scoring instrument, and the whole thing, including environment images and reference solutions, is released openly. The team explicitly declines to report a suite-wide average since the subsets aren’t comparable, which is a small but pointed rebuke of leaderboard culture: four different verification styles shouldn’t collapse into one number.

Retrieval got a structural fix worth noting too. M-RAG proposes splitting the retrieval key from the generation payload, so a document gets a compact, discriminative key for lookup and a separate, fuller value for what actually lands in context (arxiv.org/abs/2603.26667). That decouples the two things chunk-based RAG conflates: retrieval wants small, precise records, generation wants faithful, complete evidence, and forcing one chunk size to serve both is why small chunks fragment answers and large chunks waste the token budget. On LongBench QA subtasks it beats chunk-based baselines especially under tight budgets, with better document coverage and lower retrieval latency as the candidate corpus grows.

Watch whether AWS’s durable-execution bet pulls Temporal-style patterns further into mainstream serverless tooling, and whether anyone answers the ESG team’s open question: what actually validates an LLM-emitted task graph before it hits a durable queue.