Daily digest

The Complexity Bill Splits on Whether AI Config Is Committed

Aug 28, 2026 · 🎧 12 min

agentic codingevalsmulti agentagent reliabilityinformation retrieval

Across 441 repositories, agent-first teams with no committed AI configuration saw cognitive complexity rise 53% versus 27% for teams that committed some, at identical commit throughput. StarHarness moved three enterprise benchmarks 20-35 points by evolving only the harness, and ToolRobustBench localizes the dominant tool-calling failure to misreading tool output rather than picking the wrong tool. Plus verifiable durable execution from Diagrid, a selection-rule fix worth 7 points in multi-agent judging, the token price of a vague spec, and hybrid search inside SQLite.

Highlights

  • 441 repos: agent-first teams without committed AI configuration saw +53% cognitive complexity versus +27% with it, and 1.7x the static-analysis warning growth, at identical 28-38% commit throughput gains.
  • StarHarness improved ITBench SRE, EnterpriseOps-Gym ITSM and AutomationBench Finance by 20-35 percentage points after 4-12 accepted harness changes, with gains holding on held-out tasks and transferring across GPT and Qwen.
  • ToolRobustBench (15,456 instances, 7 models, 14 perturbation subtypes) finds tool-output/observation perturbation the dominant failure source, and mixed-family failures that are non-additive.
  • Changing only the multi-agent selection rule, frequency plus judge score, moved accuracy from 63.82% to 70.82-70.95% across 81,390 replayed candidate pools.
  • Reducing a full task spec to a bare user story raised agent token spend 29.7% on average (13% to 115% by task) across 2,700 Kimi K3 runs.

Across 441 repositories, agent-first teams with no AI configuration committed to version control saw cognitive complexity climb 53% after adopting coding agents. Teams that had committed some configuration saw 27%, and 1.7× less growth in static-analysis warnings. Commit throughput rose 28–38% in both groups. The velocity was the same; only the bill differed.

That split comes from A Few Pages of Markdown, an ASE ‘26 paper out of Stanford, CMU and Grid Dynamics that introduces RAMP, a four-level maturity model scored from artifacts a team actually commits rather than from a leadership survey: behavioral rules and coding standards at the base, named agent definitions above that, multi-agent orchestration at the top, with nearly all observed practice sitting in the first three levels. The levels behave as a cumulative scale, and independent human annotation reproduced the repository-level labels on 97% of a held-out sample, which is a stronger instrument than most maturity models bother to validate. The authors flag that maturity is observational and that correlated engineering discipline could account for part of the gap, and they publish the finding as hypothesis-generating. The cost of acting on it anyway is close to zero, because 73.8% of these artifacts are committed once and never touched again.

Set-and-forget is exactly what StarHarness argues against. The framework evolves an environment-specific harness while model weights stay fixed, and its search space is everything around the model: prompt and task framing, tool interfaces, skills, MCP-backed providers, subagent structure, agent-loop configuration. On ITBench SRE, EnterpriseOps-Gym ITSM and AutomationBench Finance, evolution moved full-benchmark performance 20 to 35 percentage points over the default harness after only 4 to 12 accepted changes per environment. The gains held on tasks excluded from evolution and transferred across GPT and Qwen families without re-evolving. Trace analysis attributes the improvement to interface repairs, environment conventions, and operational knowledge that shortens search, with fewer false-positive diagnoses and shorter trajectories. Set against the argument we covered two days ago that harness tuning is where teams burn effort chasing benchmark numbers, the reconciliation is in the held-out and cross-family results: 4 to 12 changes that survive transfer is a different object than a hundred that overfit one leaderboard.

The thing that keeps breaking is not the model’s plan. ToolRobustBench ran 15,456 single-family instances across 7 models, 16 local tools, 4 perturbation families and 14 subtypes, attributing each failure to a specific stage: tool selection, schema grounding, argument binding, or handling of tool output and runtime feedback. Clean end-to-end accuracy was high and fairly uniform. Robustness was not, and the dominant bottleneck was perturbation of the tool’s own output, meaning the agent picks the right tool with the right arguments and then misreads what comes back. Mixed-family runs produced non-additive failures that the isolated single-family results do not predict, which is the part that should worry anyone estimating production reliability from a per-stage error budget.

On the runtime side, Diagrid Catalyst 2.0 shipped Dapr-based recovery, signed workflow history and execution attestation across several agent frameworks. The signed-history piece is the interesting one. Durable execution has been available from Temporal and its neighbors for years, and framework-native durability is now common; making the replay log independently verifiable is a different claim, aimed at the audit conversation rather than the uptime one. Whether that matters depends on who is asking to see the trace.

Two papers this window attack cost and correctness at the level of the pipeline rather than the model. Candidate supply and answer selection separates multi-agent reasoning into generation, peer communication and terminal selection, then holds the first two fixed: the authors replayed 81,390 frozen candidate pools drawn from 16,278 questions across five benchmarks, after mapping judge reliability over 15,336 questions from MMLU-Pro, GPQA, MedXpertQA and MuSR. A correct answer is frequently already sitting in the pool when the system reports a wrong one, and consensus without quality control drifts toward popular errors. Changing only the selection rule, combining answer frequency with a judge’s evaluation, moved accuracy from 63.82% to between 70.82% and 70.95%, mostly by rescuing correct answers that were outvoted. Judge reliability turned out to vary with task, generator, and how rare the correct answer is, so it is not a property you can measure once and carry across deployments.

The cost side is Can your AI agent be cheaper?, 2,700 runs on Kimi K3 at three thinking efforts. Reducing a full task specification to a bare user story raised token spend 29.7% on average, with per-task sensitivity ranging from 13% to 115%, and run-to-run variance unmoved by any prompt change. A simple predictor fit from one cheap probe priced an unseen task’s full distribution of specification and effort settings within 36%. Read alongside RAMP, both point at written specification as the cheap lever: one paper prices vague prompts in tokens, the other prices absent conventions in complexity.

For retrieval, scrydb puts lexical, semantic and hybrid search inside SQLite, FTS5 for the keyword lane, sqlite-vec for vectors, plus reranking and rank fusion, MIT licensed, with reported latency and effectiveness trade-offs across standard IR benchmarks. For agentic search over a corpus that fits on one machine, a single file with no service to operate is the right default, and it is worth knowing where the ceiling actually sits before reaching for a vector database.

What to watch: whether anyone replicates the RAMP quality gap with an intervention rather than an observation, since the causal direction is the whole question, and whether ToolRobustBench’s finding on tool-output handling starts showing up as a design constraint on MCP server responses rather than as a model complaint.

In this issue

← All digests