News · · 15 min
Period: September 4 — morning of September 5.
Today's main story is not about a new "smartest LLM." It's about how model capabilities are beginning to transform into more complex engineering systems: multi-agent orchestration, formal verification, speculative execution, control of shared state, and managing fleets of coding agents.
What happened. Anthropic published what it claims is the first complete computer-checked proof of Fermat's Last Theorem. Claude worked mostly autonomously for 11 days, generated about 13 million lines of Lean code, and proved 30,300 intermediate theorems, of which 29,500 were included in the final proof. The final result is verified by Lean itself, and the full code is published.
The most interesting aspect for our topic is not the mathematics, but the architecture. Initial attempts with several agents failed: they lost the project state and stopped coordinating effectively. Success came after switching to a Prove2Me + Claude Code multi-agent harness: a DAG of dependencies between theorems, separate storage of statements and proofs, shared search, and reuse of results. The project required approximately 6 billion output tokens.
Why it matters. This is an extremely clean, production-like example of the thesis: model capability alone proved insufficient. The task became solvable only after introducing proper external state, decomposition, and a deterministic verifier.
This is almost the same pattern needed in software engineering:
large task → dependency graph → independent workers → shared state → deterministic verification.
What the data showed. This is not a benchmark or a model comparison. It's a large vendor-run experiment on one specific task. The strength of the evidence is that the final artifact is verified by a formal system, not an LLM-judge.
What you should already understand: formal verification, Lean, DAG, multi-agent orchestration, deterministic verifier.
What this could change. For complex coding agents, what's becoming more interesting is not "long prompts," but explicit dependency graphs and verifiable intermediate artifacts. If a team is building a long-running agent workflow, this is a good reason to see if it can be broken down into dependency-aware units instead of one huge context.
Date: September 4. Primary source: Anthropic — Formalizing Fermat's Last Theorem
What happened. The Speculative Macro Commit paper proposes a two-tier architecture: a large authoritative model makes real decisions, while a small, fast model simultaneously speculates on several next actions and pre-executes them in an isolated copy of the environment. If the first predicted action matches the main model's decision, the system can immediately commit the already calculated chain of subsequent steps.
What the data showed. Using Qwen3.5-27B INT4 as the actor and Qwen3.5-4B as the drafter, the authors achieved the same overall accuracy on τ²-Bench Telecom, but latency was 18.59% lower compared to standard sequential execution and 10.23% lower compared to a simpler speculative-actions baseline. On AppWorld, wall-clock time was reduced by 44.9% compared to sequential execution, although the completion rate slightly decreased. The code is open.
Why it matters. Agent latency is not just token generation speed. In browser/code/tool agents, a huge portion of time is spent in the sequence:
think → call → wait → observe → think → call.
If the next set of actions can be predicted and safely pre-executed, the architecture begins to compensate for the latency of the environment itself.
What you should already understand: speculative execution, tool calling, actor/drafter, sandbox snapshot, wall-clock latency.
What this could change. While this is still at the research stage, the idea is practically applicable to agents with repeatable workflows. It's especially interesting for browser automation, CI/CD, and enterprise SaaS, where external actions are slower than model inference.
Submission date: September 3; the paper appeared in the fresh arXiv listing on September 4. Primary source: arXiv — Speculative Macro Commit
What happened. The Fresh Memory, Stale Plans paper identifies a separate failure mode in distributed agent systems: an agent can receive updated shared state but continue to perform an action permitted by an old version of the plan.
The authors propose PlanFence: each plan explicitly specifies the records it depends on, and just before an external action, the executor checks only the relevant dependencies. If they have changed, replanning is required or the action is blocked.
What the data showed. In 30 controlled live workflows after requirements changed, a simple freshness-only executor executed a stale plan 30 out of 30 times. PlanFence completed all 30 workflows without an invalid action. The authors specifically emphasize: this is a safety/systems-cost result, not a general increase in task accuracy.
Why it matters. This is a very practical distributed-systems insight. A multi-agent system has two distinct properties:
state is fresh ≠ decision based on state is still valid.
For agents that create PRs, make purchases, change cloud infrastructure, or update CRMs, this distinction is critical.
What you should already understand: shared state, stale state, dependency tracking, optimistic validation, replanning.
What this could change. If multiple agents are working with shared state, it's worth thinking not only about memory synchronization. Provenance is more important: based on which version of the data was a specific decision made.
Date: September 3; in the new arXiv listing — September 4. Primary source: arXiv — Fresh Memory, Stale Plans
What happened. In MasterControl Seventeen Every Time, the authors compared two approaches to enterprise analytics.
In the first, small LLMs themselves generated SQL and selected tools at runtime. In the second, Qwen3-8B only interpreted the user's intent, after which a deterministic policy selected a pre-approved analytical program.
What the data showed. Out of 330 agentic runtime-planning runs, none completed the full answer-and-evidence contract across all test datasets. The deterministic-policy architecture completed 110 out of 110. The authors specifically warn: this is a result of a specific configuration, not proof that runtime agents don't work in principle.
Why it matters. Sometimes the right way to use an LLM is not to let it control the entire system.
A useful architecture:
LLM understands intent → deterministic software decides what is permitted → deterministic executor performs operation.
This is especially relevant for finance, analytics, permissions, compliance, and other systems where auditability is more important than maximum autonomy.
What you should already understand: deterministic execution, SQL generation, policy engine, evidence contract, auditability.
What this could change. A good question for the team: which decisions truly require agent reasoning, and which, after recognizing intent, can be handed back to regular deterministic software.
Submission date: September 2; new arXiv listing — September 4. Primary source: arXiv — MasterControl Seventeen Every Time
The Astra release itself was covered in the previous issue, so here we focus only on the new significant update.
What happened. On September 4, GitHub made GPT‑6 Astra available in Copilot for VS Code, Visual Studio, CLI, coding agent, JetBrains, Xcode, Eclipse, GitHub.com, and mobile.
GitHub separately notes that in internal tests, the model didn't just generate a better final result: it planned, independently validated intermediate work, combined diagnosis with verification, and separately confirmed the result before completing the task. GitHub claims this led to stronger long-horizon coding results with fewer steps compared to previous OpenAI models; absolute benchmark numbers were not published here.
Why it matters. The boundary between "model capability" and "harness behavior" is becoming increasingly blurred. Part of the planner/verifier logic is gradually moving directly into the model.
This potentially simplifies the harness but raises a new question: what can be trusted to the model's built-in self-verification, and what should still be checked by an external deterministic layer.
What you should already understand: long-horizon coding, self-verification, agent loop, model policy, usage-based billing.
What this could change. Don't change the team's default model immediately. It's worth running Astra on internal tasks and comparing primarily human interventions, number of steps, cost per completed issue, and post-review defects, not just the subjective quality of the response.
Date: September 4. Primary source: GitHub Changelog — GPT‑6 Astra in Copilot
What happened. VS Code 1.136 introduced a public preview of Agent Merge: the agent receives a pull request and attempts to independently handle review feedback, failed checks, and merge conflicts until the PR becomes merge-ready. Simultaneously, hierarchical chat sessions and experimental multi-root agent workspaces appeared.
Why it matters. Coding agents are gradually moving further along the SDLC:
write code → create PR → react to review → fix CI → resolve conflicts → merge-ready.
It's precisely the later stages that typically consume a large amount of engineering time after the initial code generation.
What the data showed. GitHub has not yet published independent completion-rate or defect-rate data for Agent Merge — this is a product preview, not a confirmed productivity improvement.
What you should already understand: pull request, CI, merge conflict, agent session, SDLC.
What this could change. If a team is already actively using coding agents, it makes sense to measure not "how much code AI wrote," but time from issue to merge and human review minutes. That's where the tooling is now heading.
Date: September 4. Primary source: GitHub Copilot weekly releases
What happened. Amsterdam-based Wonderful closed a Series C round of $550M at a $5B valuation. The round was led by Insight Partners, with participation from Salesforce, Index Ventures, IVP, Vine Ventures, 9Yards, and Bessemer. The company reports operating in over 35 markets with 650 employees.
Wonderful is now positioned not as a set of ready-made agents, but as a common AI operating layer: workflows, context, applications, compliance, and coordination of multiple agents within an enterprise.
Why it matters. The SaaS market is beginning to sell not an individual "AI sales agent" or "support agent," but a control plane for an entire organization of agents.
This is an important architectural evolution:
single AI feature → isolated agent → fleet of agents → organization-wide agent platform.
What the data showed. The funding and geographic expansion are confirmed by the company. Independent client productivity/ROI metrics are not included in the release.
What you should already understand: agent orchestration, enterprise context, AI control plane, workflow automation, governance.
What this could change. For now, observe. But if dozens of autonomous workflows start appearing within a company, the question "which agent to use?" quickly turns into "where is the shared context, permissions, audit log, and policy stored?"
Date: September 4. Primary source/official announcement: Wonderful Series C announcement
What happened. GitHub added a privacy-safe Star History REST endpoint. It's now possible to retrieve historical star counts with timestamps without accessing the identity of individual stargazers.
This is technically a small update, but important for open source analysis: after recent restrictions on stargazer APIs, tools can once again properly calculate repository growth velocity, not just the current total.
Why it matters. Now, "+N stars per day" can be restored from the official GitHub source, rather than relying solely on third-party snapshots.
For our feed, this also means the quality of the GitHub section in future issues can be significantly improved.
What you should already understand: GitHub REST API, star history, leading indicator, repository activity.
Date: September 4. Primary source: GitHub — Star History API
stablyai/orca is currently among the noticeably growing agentic-devtools. A third-party snapshot from September 4 recorded about +914 stars in a day; the current GitHub shows approximately 32.8k stars. Precise historical values before the new GitHub Star History API are best considered approximate.
Architecturally, the project is more interesting than the star count: one prompt can be fanned out to several agents, each working in a separate Git worktree, after which a human compares the results and selects a variant for merging. It supports Claude Code, Codex, Grok, Copilot, Kimi, Qwen Code, Hermes, and other CLI agents.
Market signal: developers increasingly don't want to choose "one perfect coding agent." A layer is emerging:
task → several agents/models → isolated executions → compare/review → merge.
What you should already understand: Git worktree, parallel agents, fan-out, orchestration, human review.
What this could change. An interesting internal experiment: give the same complex issue to two or three models in parallel and measure whether the increased token cost is offset by reduced human debugging time.
Primary source: GitHub — stablyai/orca
pacifio/atlas is also growing in current developer-tool snapshots; one snapshot from September 4 estimated growth at roughly +419 stars.
Unlike a regular IDE wrapper, Atlas attempts to solve the provenance problem: it stores the history of agent sessions, plans, failures, architectural decisions, and file changes; Claude Code and Codex can use shared memory. By default, sessions are stored locally.
Market signal: regular Git is insufficient if a significant portion of engineering work is performed by agents. Git knows what changed. Agent-aware source control attempts to additionally preserve why, by which agent, and based on what context it changed.
What you should already understand: provenance, agent session, shared memory, version control, context.
What this could change. For now, it's an early signal, but if a team runs many coding agents in parallel, agent provenance could become as much of a production requirement as regular commit history.
Primary source: GitHub — pacifio/atlas
Today it's especially noticeable that agent engineering is beginning to borrow ideas from mature software/distributed systems.
Not "give the model another prompt," but:
dependency graphs → isolated execution → speculative execution → provenance → stale-state validation → deterministic verification → source control for agents.
And Anthropic's formalization of Fermat shows this on a very large real workload: dozens of powerful agents initially failed at coordination, but the right external harness turned the task into a manageable graph of work.
Which of our agents' decisions are currently validated by another LLM, even though they could be checked deterministically?
If a requirement or shared state changes after a plan is made, can the agent determine that its current plan is no longer valid?
Can complex coding tasks be represented as a dependency graph of independent, verifiable subtasks instead of one long agent session?
Should we try a parallel-agent workflow: several models → separate worktrees → comparison → human merge?
Are we preserving the provenance of agent work: which agent made a decision, based on what context, and why was a specific change made?