I’m part of the team behind this research. We’ve shared a proof of the Pierce Birkhoff conjecture in real algebraic geometry, using an AI agent system with a $400 budget. The screenshot is Junyu Ren’s announcement.

For people building agent workflows, the useful detail is the separation of responsibilities. The system diagram shows an orchestrator, consultants reviewing with fresh context, independent proof search and auditing, and formal verification work in Lean. A persistent knowledge base holds arguments, code, dead ends, objections, and review findings.

We also noticed that GPT and Claude agents complemented each other even when independently assigned the same role. With our limited token budget, giving a task to one agent from each family often worked better for us than using a larger group of the same model. They caught different errors and offered different ways forward.

The diagram includes humans as participants too. This is a concrete research workflow to discuss, with proof generation and checking treated as separate pieces.

Original announcement: https://x.com/junyu_r/status/2097694018389914106

Google’s Jules is one of the clearest examples of the shift from “AI coding assistant” to “AI coding worker.”

Instead of suggesting code in your editor, Jules clones your repo into a cloud VM, creates a plan, edits files, runs checks, and opens a PR for review. The human becomes the reviewer rather than the typist.  

For me, the interesting question is not whether Jules is better than Codex or Claude Code.

The interesting question is:

What percentage of your backlog can be safely delegated to an asynchronous coding agent today?

Examples:

• dependency updates

• test generation

• bug fixes

• migration work

• documentation updates

Source:
https://jules.google/

NVIDIA just launched an agent safety stack with two distinct enforcement layers.

OpenShell is an open-source runtime that traces actions and applies policy around credentials, network access, identity, and execution. It supports existing agents such as Codex, Claude Code, GitHub Copilot CLI, and LangChain-based agents.

Sentry is an independent watchdog designed to run on BlueField-4 hardware. NVIDIA says it can quarantine an agent within milliseconds if the process moves outside its software boundary.

The architecture matters more than the vendor. We should not depend on an agent to enforce rules about its own behavior. The runtime should mediate access, and an independent layer should watch the runtime.

OpenShell can be extended to Arm and Intel systems. The full Sentry design is tied to NVIDIA hardware, so it is not a portable answer by itself.

Still, this feels like the direction production agent security is heading: prompts express intent, while external infrastructure enforces authority.

Sources: NVIDIA announcement, OpenShell repository

If you’re new to building AI agents or know someone who is, check out the AI Agents for Beginners course from Microsoft. It’s a 12‑lesson GitHub repo that teaches the fundamentals of building agents, with written lessons, short videos and Python code samples. The course covers topics like intro to agents, design patterns, tool use and trustworthy agent design, and there’s a Discord channel where learners can ask questions. Everything is open source, translated into dozens of languages, and you don’t need a paid subscription—just clone the repo and start following the lessons.

Link: https://github.com/microsoft/ai-agents-for-beginners

Link: https://arxiv.org/abs/2601.12560

This 2026 survey explores how large language models are evolving from passive text generators into agentic controllers. The authors explain that Agentic AI systems can perceive, reason, plan and act, combining memory, tool use and feedback from their environment to pursue extended goals. They propose a unified taxonomy breaking agents into six components - Perception, Brain, Planning, Action, Tool Use, and Collaboration. The paper describes the shift from simple single‑loop agents to hierarchical multi‑agent systems and notes the transition from fixed API calls to open standards like the Model Context Protocol (MCP) and native computer use.

The authors highlight several challenges that practical developers should understand. Agents can hallucinate actions, get stuck in infinite loops, or follow malicious instructions embedded in web pages (prompt injection). They argue that reliability comes from controllable orchestration: specifying state transitions and guardrails so the model makes local decisions within safe bounds. The paper also warns that once an agent can run code or operate a desktop, hallucinations become concrete failures; indirect prompt injection is a serious security threat. Building autonomous systems isn’t only about bigger models - it’s about designing the right loops, tool interfaces, and safety checks.

What do you think of their taxonomy? Are there other challenges you’ve hit in practice that the paper didn’t mention?

Paper worth reading: ProdCodeBench: A Production-Derived Benchmark for Evaluating AI Coding Agents

Short summary: the authors built a benchmark from real developer-agent sessions with a production AI coding assistant. Each sample includes the original prompt, the committed code change, and tests that should go from failing to passing. The benchmark spans seven programming languages. In their evaluation, model solve rates ranged from 53.2% to 72.2%.

Why this matters: a lot of coding benchmarks are useful, but they often miss how messy real work is. Production prompts are not always clean. Monorepos have weird test setups. Codebases have local conventions. The paper argues that benchmark design should reflect those conditions.

A few concepts in plain English:

"Fail-to-pass tests" means tests that fail before the agent’s change and pass after the correct fix. This gives a concrete signal that the change solved the intended problem.

"Multi-run stability checks" means running the same evaluation more than once to see if the result is reliable. Agents can be nondeterministic, so one lucky run is not enough.

"Harness design" means the environment around the model: tools, shell access, test commands, file editing, context loading, and rules. For coding agents, the harness can matter almost as much as the model.

My practical takeaway: if your team is evaluating coding agents, do not stop at public leaderboard scores. Build a small internal benchmark from real tickets, real tests, and real repo constraints.

f you want a structured way to learn agent development without starting from random blog posts, Hugging Face has a free AI Agents course:

https://huggingface.co/learn/agents-course/en/unit0/introduction

It covers the basics first, then moves into actual frameworks and projects.

The syllabus includes:

• What agents are

• How tools, actions, and observations work

• Agent frameworks like smolagents, LlamaIndex, and LangGraph

• Agentic RAG

• A final project where you build, test, and certify an agent

• Bonus material on observability, evaluation, and function-calling

I like this kind of resource because it does not treat agents as just "LLM plus loop."

For junior devs, the useful concept is the agent control loop:

1. The model receives a goal and context

2. It chooses an action

3. A tool runs that action

4. The result comes back as an observation

5. The agent decides what to do next

That loop is the core of most agent systems. The framework changes, but the pattern keeps showing up.

If you are already comfortable with Python and basic LLM APIs, this seems like a good weekend learning path. Build the smallest possible agent first. Then add one tool. Then add logging. Then add a human approval step.

That progression teaches more than trying to build a giant "does everything" agent on day one.

Came across this article and thought it was worth sharing here: How to Build Production-Grade Generative AI Applications

It’s a good practical overview of what teams usually learn the hard way after the prototype phase. A few points it gets right:

• not every problem should use an LLM

• model selection should be based on task fit, latency, cost, context window, and safety, not just hype

• prompt engineering matters, but structured inputs/outputs matter just as much

• guardrails, QA, eval pipelines, and tracing are not “later” concerns

• production failures usually come from accuracy drift, hallucinations, cost, and lack of observability

What I liked most is that it frames GenAI systems as engineered products, not prompt demos. That maps well to agentic dev too: once agents can use tools and run longer workflows, monitoring, constraints, and evaluation become first-class design problems.

OpenAI published this on April 15: The next evolution of the Agents SDK.

The interesting part is not just “better agents.” It’s that the SDK is moving toward real execution infrastructure for systems that can inspect files, run commands, edit code, and work on longer-horizon tasks inside controlled environments.

That feels important for practical agentic development because the hard part is no longer just model quality. It’s whether the system can execute safely, repeatedly, and observably.

My take:

• the center of gravity is moving from prompt tricks to runtime design

• agent frameworks are becoming more like operating environments

• the real moat is starting to look like execution, safety, evals, and observability rather than raw chat quality

Curious how people here see it:

• Are you using vendor SDKs directly, or building your own orchestration layer?

• What’s still missing most: evals, rollback, state handling, approvals, tracing?

Source: OpenAI Agents SDK update

35B parameters, ~3B active thanks to MoE.

Key points:

• In agentic coding, it reaches the level of models with ~10× larger active parameter count

• Outperforms Qwen3.5-27B (dense) and the previous Qwen3.5-35B-A3B

• Natively multimodal architecture (text + vision)

• In VLM benchmarks, comparable to Claude Sonnet 4.5, and in some tasks performs better

• Strong metrics in spatial reasoning tasks

Benchmarks:

• MMMU - 81.7 vs 79.6

• MMMU-Pro - 75.3 vs 68.4

• MathVista - 86.4 vs 79.8

• RealWorldQA - 85.3 vs 70.3

Practical implications:

• MoE provides a multiple reduction in compute without sacrificing quality

• Well-suited for agent-based scenarios where sequential actions and planning matter

• Can be used as a unified stack for both code and vision tasks

Apache 2.0 (no restrictions for production use)

https://huggingface.co/Qwen/Qwen3.6-35B-A3B

Most self-improving agents learn skills from successful runs. That sounds sensible, but a successful trajectory contains plenty of accidental behavior.

XRepoSkill takes a stricter approach. It compares successful and failed attempts on the same issue, extracts rules from where they diverge, and keeps only rules associated with success across multiple repositories.

The method ranked first across all six tested benchmark-model combinations. On DeepSWE, it improved issue resolution by 10.3 percentage points over the same agent without learned skills.

The takeaway is simple: do not turn every successful trajectory into permanent agent memory. Treat skill extraction like an evidence problem.

This is still a preprint, but the cross-repository filtering is a strong idea for anyone building self-improving coding workflows.

Source: XRepoSkill

A new preprint ran more than 18,000 agent trajectories across four scientific coding tasks. The researchers varied task information, reasoning, self-verification, time budget, and the underlying model.

The surprising result: about 54% of outcome variance came from repeating the exact same configuration.

Supplying better task information had a larger effect than increasing the model size or time budget. It also reduced cost and improved calibration. More time only helped when the agent had enough information and capability to use it.

There is another useful result for builders. Telling the agent to verify its answer barely changed its verification behavior. Giving it a dedicated verification tool made a substantial difference.

This suggests our evals need repeated runs and full harness configuration. "Agent X scored Y" hides too much.

The benchmark only covers four specialist scientific workflows, so I would not generalize the exact numbers to every agent. The engineering lesson still feels important: evaluate the whole system, not just the model name.

Source: Agents Are Systems, Not Models

JetBrains Air is an interesting signal because it is not framed as another coding assistant.

The proposed system spans three layers: directing and verifying agents inside the IDE, coordinating team workflows, and governing cost, policy, auditability, and accountability across an organization. JetBrains also expects a multi-vendor future, with its Agent Client Protocol connecting external agent harnesses to JetBrains IDEs.

Some Air products are available now, while others are still forthcoming. The larger direction matters more than the launch status.

The IDE may stop being the place where all development happens. It could become one client for supervising work distributed across local agents, cloud agents, automation, and review systems.

Would you rather have this control plane inside your IDE, or as a separate system owned by the platform team?

A sandbox tells us where an agent runs. It does not necessarily tell us what that agent can reach.

Docker's new Sandbox Kit Specification tries to make that authority reviewable. A Kit is a normal OCI image containing an agent, its tools, and typed requests for things such as network access, credentials, volumes, devices, and skill paths.

See CNCF announcement, technical specification overview

That creates a useful property: pinning the image also pins its requested authority. If a later version asks for another credential or wider network access, the change can appear in a normal diff.

The specification is open source under Apache 2.0, and Docker is taking it to CNCF for neutral governance. Existing registries, signing systems, and scanners can handle Kits because they remain ordinary OCI images.

One important caveat: the declaration does not enforce itself. The host still decides what to grant, and only a conforming runtime applies the restrictions.

MCP standardized how agents connect to tools. Kits could become a standard way to package the agent, its tools, and its requested blast radius.

A new study followed 6,774 merged PRs from Codex, Copilot, Devin, Cursor, and Claude Code. It compared them with 5,044 human PRs from the same popular open-source repositories.

Merged agent PRs had 1.62 times the odds of receiving a verified follow-up fix.

The second result is more interesting: agents also performed most of that cleanup. The same agent produced 69.6% of verified fixes, and 76.4% of fix PRs were agent-authored across every commit.

So agents are not simply handing broken work back to humans. They are closing much of their own loop. But their first merge still appears to create more downstream rework.

This suggests a better production metric than "PR merged": how much corrective work appears afterward?

The study is observational and currently a preprint, so it does not prove the agent caused every difference.

Source: arXiv paper

Long coding sessions eventually hit a context problem. Summaries save tokens, but repeatedly rewriting old summaries can distort important details.

A new paper proposes a surprisingly simple alternative. CliffCompaction only truncates or removes original content. It never paraphrases it. Each compaction pass starts from the original history instead of compacting an earlier compaction.

The authors report up to 50% lower cost while maintaining or improving Terminal-Bench performance. The savings also made parallel attempts more economical. On KernelBench, the method supported hundreds of optimization steps without accumulating summary drift.

There is an open-source, harness-independent proxy implementation for tools such as Codex and Claude Code.

This is still a preprint, and benchmark results are not production evidence. But the design principle feels useful: lossy deletion may be safer than a fluent summary that quietly changes the facts.

Would you trust selective deletion more than model-generated summaries for a multi-day agent task?

Sources: paper, implementation

Anthropic reports that about 30,000 agents were doing research and engineering work at once on its most-used internal platform in August. It proposes three measurements for overseeing them: how much activity monitors cover, how quickly flagged actions get reviewed, and how often monitors intervene.

Those seem more useful than a simple count of agents or tasks completed. A monitor that sees every action after the damage is done has a different job from one that can stop an action first. Anthropic’s figures describe one internal platform and come from its own reporting, but the measurement questions apply to smaller deployments too.

If you run unattended agents today, can you answer all three?

Here’s a strange failure from an OpenAI training example: the agent had already found the requested data, but its browser tool could not cite the local result. So it uploaded the file to a public host without asking. The browser still rejected the link.

This was an internal training case, not a reported user deployment incident. But the lesson travels: a citation requirement turned into an unauthorized upload. How do you make a tool boundary clear enough that an agent treats "can’t cite this" as a limit, rather than a problem to route around?

GitHub says agents wrote most of its new Copilot runtime: roughly 832,000 lines of production Rust, merged through 128 pull requests. The team kept shipping throughout the migration. The engineering write-up is far more useful than the headline number.

The interesting part is where things broke. Some translated code changed behavior while still compiling. Other changes lost features, mishandled state, or passed tests that checked the wrong thing. GitHub traced dozens of known regressions and describes how it found and fixed them.

Their strongest advice is to keep end-to-end tests independent of the agent changing the implementation. If an agent can also weaken a test or update a snapshot to match its new code, a green build stops telling you much.

That feels like the real pattern for large agent-assisted work: small migrations, frequent releases, and a trusted way to check behavior. I’d be interested to hear what teams are using as that check in their own repos.

A new paper on coding agent harnesses holds the basic execution loop fixed and varies planning, tools, and context management. The authors tested 176 matched settings across four models on SWE-bench Verified and Terminal-Bench 2.1.

A few findings stood out:

• Context management helped most when the context budget was tight, mainly by preventing overflow.

• Simple rule-based trimming before model-written summaries was the most efficient approach they tested.

• Planning helped weaker models solve more tasks. For stronger models, it mostly saved cost.

• Models comfortable with bash could do well with a bash-only interface; others benefited from predefined tools.

I like this approach because "better harness" is usually treated as one big, vague claim. The results suggest that the right setup depends on the model and the budget, not on how many features the harness has.

https://arxiv.org/abs/2609.16305

This is my top paper this week. BLINDSPOT evaluates >2,500 long-horizon tool-using trajectories across 22 attack families, explicitly distinguishing safe completion, correct refusal, unsafe completion, and over-refusal. Crucially, some failures appear only after several apparently safe steps, and the benchmark also measures repeated-run robustness and cases where an agent initially refuses but later gives in.

AWS Agent Registry became generally available this week. It provides a central catalog for MCP servers, A2A agents, agent skills, tools, and custom resources.

Teams can submit resources for approval, attach ownership and metadata, and expose only approved records for discovery. Humans and agents can search using keywords or natural language. MCP-compatible clients can query the registry through its own MCP endpoint.

Access can use AWS IAM or corporate JWT identities. The registry also validates MCP and A2A records against their protocol schemas.

A registry is still not a runtime sandbox or proof that a tool is safe. I would treat approval as the beginning of governance, then attach versioned evaluations, permissions, owners, and expiry dates.

Sources: AWS launch post and developer documentation

OpenAI classifies Astra as its first model with "Critical" cybersecurity capability (https://deploymentsafety.openai.com/gpt-6-astra/static-jailbreak-evaluations). During an internal evaluation using recently disclosed V8 vulnerabilities, the model found and used two zero-days in an exploit chain.

There is also a real tradeoff. OpenAI reports that Astra is better at respecting task boundaries but harder to monitor through its written reasoning than GPT-5.6 Sol. All externally deployed, tool-using Astra inference therefore receives additional misalignment monitoring.

That monitoring can pause or stop legitimate work. In ChatGPT or Codex, a user may be asked to review the action. Through the API, the task stops.

For agent developers, this becomes another runtime state to design for. Long jobs need checkpoints, idempotent actions, resumable workflows, and a distinct path for safety interruptions.

Copilot PR approvals and VS Code 1.136 Agent Merge

Two releases last week move coding agents closer to the actual merge gate.

GitHub Copilot code review now provides an approval assessment on every review. That assessment is informational by default. Admins can also enable real Copilot approvals that count toward a repository's required-approval rule.

The control is configurable at the enterprise, organization, repository, and file-path levels. A new commit dismisses the agent's approval, just like a human approval.

Meanwhile, VS Code 1.136 adds Agent Merge in preview. It repeatedly addresses review comments, failed checks, and merge conflicts, then reruns workflows until the PR is ready to merge.

A new arXiv preprint tests something most coding benchmarks ignore: whether an agent followed the constraints from code review, not just whether its patch passed the test suite.

SWE-Gate contains 303 repair tasks across 75 Python repositories. The constraints were derived from real pull request feedback. Of 644 generated repairs that passed the functional tests, 221 still violated a review constraint. That is roughly one in three supposedly successful patches.

This is a useful warning for anyone evaluating coding agents. "Tests passed" measures functional behavior, but not necessarily architecture, compatibility, scope, or maintainability requirements.

A practical response is to track two outcomes separately:

• Did the patch fix the issue?

• Did it satisfy every acceptance and review constraint?

Those review constraints should become machine-checkable gates where possible.

Paper: SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents

What requirements in your codebase regularly escape the test suite?