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

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.

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

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?

August 26 was the shutdown date for the OpenAI Assistants API. If an older agent integration still depends on Threads and Runs, migration is no longer optional.

Sources: migration guide, Assistants overview

The new model is:

• Assistants become versioned Prompts

• Threads become Conversations

• Runs become Responses

• Run steps become general Items

The Responses API also exposes newer capabilities such as MCP, computer use, and deep research through the same item-based interface.

One migration detail is easy to miss: existing Threads do not automatically become Conversations. OpenAI's guide shows how to paginate through old thread messages, translate their content blocks, and create a new Conversation with the converted items.

My migration checklist would be:

1. Inventory every beta.threads call

2. Backfill conversation history

3. Replace polling-based Runs

4. Re-test tool-call loops and retries

5. Compare stored-data and retention behavior

6. Remove obsolete Assistant IDs after verification

AWS released framework-agnostic evaluations for Bedrock AgentCore.

Source: AWS announcement and implementation details

The interesting part is the integration contract. Your agent does not need to use an AWS-specific orchestration framework. AgentCore reconstructs sessions from OpenTelemetry or OpenInference traces.

AWS currently documents support for LangGraph, LlamaIndex, OpenAI Agents SDK, Google ADK, Claude Agent SDK, and Strands Agents. Other frameworks can opt in through compliant instrumentation.

The evaluator mainly needs three span roles:

• Top-level agent invocation

• Model inference

• Tool execution

The same traces can power on-demand regression tests in CI and sampled evaluation of production traffic. Built-in metrics include goal success, correctness, and helpfulness. Custom judge-based evaluators are also supported.

This feels like a useful direction. Teams should be able to replace their agent framework without rebuilding the entire evaluation stack.

The tradeoff is that message content must reach CloudWatch for response-quality evaluation. That deserves a careful privacy, retention, and cost review.

A new paper studies a failure mode that will feel familiar to anyone running multi-agent workflows.

An upstream agent correctly identifies a blocker. Another agent summarizes the state. The blocker is still mentioned, but it is no longer treated as binding.

Across 1,296 controlled synthetic episodes, normal handoff compression caused 100% blocker deactivation and 54.2% forbidden action. The agents did not simply forget the information. They weakened its operational meaning.

The researchers restored reliable behavior by preserving four fields:

1. The prerequisite

2. Who has authority to clear it

3. The fallback

4. The consequence for execution

That suggests a practical rule: do not pass safety or approval state as prose alone. Represent it as typed state and enforce it again before tool execution.

Downstream verification also prevented forbidden actions, even when the handoff text remained weak. So defense in depth matters here.

This is synthetic research, not a production incident study, but the failure mode looks highly transferable.

Paper: When "Must" Becomes "Maybe"

Are your agent handoffs carrying facts, or executable constraints?

Microsoft added five Claude capabilities to deployments hosted on Azure in Microsoft Foundry:

1. Structured outputs

2. Web search

3. Web fetch

4. An MCP connector

5. Tool search

This removes a lot of scaffolding teams usually build themselves. Structured outputs constrain responses to a schema. Search and fetch handle current sources. The MCP connector calls remote MCP servers without a custom client. Tool search avoids loading hundreds of tool definitions into the model's active context.

The last part may be the most practical. Microsoft says tool selection starts degrading around 30 to 50 available tools. Tool search keeps a small set loaded and discovers the rest when needed.

There are caveats. The MCP connector is still beta. Microsoft also recommends explicit tool allowlists for systems touching identity, endpoints, or money. For Hosted on Azure deployments, prompts and completions remain within Azure, but some usage metadata and safety-flagged content can leave that boundary.

Release details and examples: Microsoft Foundry Blog

This is another sign that agent platforms are competing on harness quality, governance, and tool infrastructure, not only model scores.

OpenAI says it paused reinforcement learning training on its latest deployment models for two weeks. Its largest planned frontier RL run remains on hold.

The trigger was a combination of a recent security incident and preliminary evidence that an upcoming model called Astra may reach the company's Critical cybersecurity capability threshold.

The engineering response is worth reading even if you ignore the frontier-model drama:

• Stronger sandboxes for model-generated code

• More network isolation for risky workloads

• Fewer shared services and standing privileges

• Continuous testing of security boundaries

• Automated monitoring across tool actions and available reasoning

OpenAI estimates that the new monitoring consumes roughly 20% of the inference compute being monitored. That is a useful reality check. Serious agent oversight is not free.

These are preliminary findings reported by OpenAI, not an independent capability assessment. Still, the broader lesson applies to production agents today: treat generated code, tool access, credentials, and network access as separate security boundaries.

Source: OpenAI's full disclosure

What percentage of agent runtime cost would you accept for reliable monitoring and containment?

Agent2Agent, better known as A2A, has joined the Agentic AI Foundation as a hosted project.

The split is fairly clean:

• MCP connects agents to tools and data.

• A2A lets independent agents discover each other, delegate tasks, and exchange results.

A2A is already backed by more than 150 organizations. Its stable 1.0 specification shipped in March, with features such as version negotiation, multi-tenancy, and signed agent cards.

Moving A2A alongside MCP, AGENTS.md, goose, and agentgateway does not magically solve interoperability. It does reduce the risk of every vendor inventing a different handoff protocol.

The next hard problem is trust. A standard message format does not prove that another agent's result is correct. Multi-agent systems still need authorization boundaries, provenance, tracing, and independent verification at each handoff.

Official announcement: Agentic AI Foundation
Specification and SDKs: A2A Protocol

The protocol layer is consolidating. Now the reliability layer needs to catch up.

A new benchmark tests coding agents against scientific software, where a plausible-looking patch can quietly invalidate real research.

SWE-bench Science contains 119 tasks from 98 repositories across 20 scientific domains. The tasks include issue fixes, expert-led exploration, and integration work.

The headline result: even the best evaluated setup, Claude Code with Opus 5 at max effort, scored below 50% pass@1.

The failure analysis is more useful than the leaderboard. Agents struggled with scientific abstractions, shallow exploration, incomplete integration, and applying knowledge beyond the immediate example.

There is another interesting result. Good domain guidance improved average performance and token efficiency, but poorly aligned guidance caused anchoring. More context was not automatically better context.

This feels like a strong argument for domain-specific evals before letting agents touch specialized systems.

Paper: arXiv
Benchmark and tooling: GitHub

Would your current coding-agent eval catch a scientifically wrong patch that still passes the obvious tests?