Anthropic Donates Agent Skills to the Agentic AI Foundation, Joining MCP Under the Linux Foundation
On October 22, Anthropic donated the Agent Skills open standard to the Agentic AI Foundation (AAIF), which the Linux Foundation hosts and which already holds the Model Context Protocol. A skill is a folder containing a SKILL.md file plus whatever scripts and reference material it needs. The donation covers the specification, the name and logo, the GitHub organization and the agentskills.io domain. Engineers from Anthropic, Google, OpenAI and other companies will maintain it as individuals, with David Soria Parra and Mahesh Murag as lead maintainers. You don't have to be an AAIF member to use or contribute to the standard.
The adoption numbers explain why it needed a neutral home. Since the format was published as an open standard in December 2025, more than 70 agent platforms have integrated it, including ChatGPT, Cursor, GitHub Copilot and VS Code. About 1 million skills have been published and nearly 280 million installed. At that scale, one vendor controlling the format would hold back the cross-tool portability that made it useful.
The proposed priorities matter most to developers: versioned releases, a formal proposal process for spec changes, and security guidance for skill authors and installers. The last one is the most needed. Earlier ecosystem audits found that a large share of published skills contained prompt-injection or unsafe-execution patterns, and the spec so far had no common rules for what an installer should check. Existing skills don't need any changes.
Read more — Anthropic
Harvard–Jellyfish Study: AI Agents Lift Code Output 20–30% but Resolved Work Only 12%, as Review Time Rises 49%
A Harvard study using Jellyfish engineering analytics covered 718 firms, about 700,000 workers and roughly 300 million work events from January 2021 to March 2026. It pulled data from HR systems, version control, issue trackers and AI tools such as GitHub Copilot, Cursor and Claude Code. It separated two kinds of tools. AI assistants (autocomplete and chat) produced 12% more lines, 9% more commits and 5% more PRs, but only the commit increase was statistically significant. AI agents produced 30% more lines, 20% more commits and 23% more PRs, all significant.
Completed work tells a different story. With assistants, resolved Jira issues and epics per worker didn't rise at all. With agents, they rose 12%, well below the 30% growth in code. The authors estimate engineers spend only 30–40% of their time writing code. The rest goes to planning, review, testing and deployment, and that is where the extra AI-generated code piled up.
The review data shows the cost. Average PR review time rose 49%, comments per PR rose 53%, the share of PRs needing changes doubled, and the share of workers doing reviews rose 14%. Larger PRs didn't explain the extra effort. The practical lesson for teams adopting agents is that faster code generation doesn't help much unless review, testing and release keep up. If they don't, agents move the bottleneck instead of removing it.
Read more — InfoQ
ThinkingBox Training: Turning Database-State Grading Into RL Rewards Lifts pass@1 From 51.7% to 60.8%
Microsoft and Hugging Face followed up their ThinkingBox-Bench release with a training recipe. The benchmark grades an agent by checking the final database state, which yields a deterministic pass/fail verdict, and the authors reused those checks as RL rewards on separate training tasks. Before training, they run every candidate task n times against the base policy, model its success rate with a Jeffreys Beta posterior, and drop tasks it almost never solves (below 0.08) or almost always solves (0.90 and above). In GRPO, groups that all succeed or all fail produce no learning signal, so only the tasks in between are kept.
They trained Qwen3.8-27B with full-parameter token-mean GRPO for 50 steps on 187 tasks, using 144 episodes per update on 24 H100s. On the held-out 507-task benchmark, pass@1 rose from 51.70% to 60.78%, and the number of tasks passed in all 20 attempts rose from 38 to 107. Pass@20, meaning tasks solved at least once, fell slightly, from 453 to 446. The authors call this sharpening: the model became more repeatable, not more capable. One example shows why that matters. On a hotel-booking task that required manager approval, the base model made unauthorized changes in 15 of 20 attempts, and the trained model kept the state intact in all 20.
The training stack (data selection, rollouts, rewards, Verl integration and a reference 24-H100 config) is open source at microsoft/thinkingbox-training, along with an OpenEnv environment. The authors' three lessons apply to any agent RL project. Probe the base policy's difficulty distribution before training. Make sure training and evaluation parse tool calls identically. Report both coverage (pass@k) and repeatability (all-k pass), because an agent that solves a task only sometimes is not reliable.
Read more — Hugging Face Blog
Safe & Secure AI Agent Practices
METR and Redwood Red-Team OpenAI's Internal Agent Monitor: Coverage Gaps, Header Bypasses and Five Design Ideals
METR and Redwood Research published a summary of a three-week pilot (July 21 to August 11) in which they stress-tested OpenAI's internal misalignment monitoring system. They had access to OpenAI's codebase, the monitor's prompts and configuration, and about a dozen engineers. Their estimate is that roughly 75–94% of agentic internal Responses API traffic from models at least as strong as GPT-5.5 was eligible for monitoring, and 99.2% for internal Codex agents. Compaction events weren't monitored, which likely left about 10% of eligible Codex traffic unmonitored from May to July. OpenAI fixed that during the exercise.
The structural findings apply to anyone building agent monitoring. The monitor ran only when an agent returned control to the user, so an agent that kept acting could postpone review indefinitely. Two client-controllable headers could disable monitoring for new agent instances. Differences between how the agent and the monitor serialized the same input could let an agent craft content that makes the monitor fail without escalating. A redacted exploit could keep hundreds of recent actions out of monitoring. OpenAI says all vulnerabilities affecting production safeguards have been patched; METR hasn't verified that claim.
The report sets out five design ideals:
- Make monitoring hard to avoid: require explicit approval for unmonitored inference, and check agents every N messages or minutes, not only at the end of a turn.
- Verify coverage: account for all inference, cross-reference it with monitor logs, and make sure the monitor sees exactly the context the agent sees.
- Respond quickly: clear ownership, defined guidelines and tamper-proof, searchable logs.
- Red-team continuously: run control evaluations and test for collusion between agents and monitors.
- Isolate agents from monitors: agent actions must not be able to influence whether or when monitoring runs.
Read more — METR
METR's Review of Anthropic's Risk Report: Low Risk Comes From Limited Capability, Not Proven Safeguards
Two days earlier, METR published its review of the "Misalignment in high-stakes settings" section of Anthropic's August 2026 Risk Report. METR agrees that current misalignment risk is low. But it attributes that mainly to the models' limited capabilities, not to safeguards or alignment training, and it isn't confident the report's methods would detect higher risk if it existed.
The central criticism is about how monitors are evaluated. METR argues that covert-capability benchmarks are a poor proxy for evading a real monitor, because they miss strategies such as convincing the monitor that a harmful action is legitimate. It cites a recent incident in which a model's chain-of-thought rationalizations reduced how often the monitor flagged it. Some incidents went undetected for months, and Anthropic revised its rating from "very low" to "low" after they came to light. METR also considers some redactions material, especially details about how quickly monitoring responds.
METR's recommendations echo its OpenAI findings. Run end-to-end red-teaming of monitoring, for example a well-resourced team trying to start an undetected rogue internal deployment. Add AI systems undermining safety-relevant decision-making to the threat model. Include models still in training in the scope. Publish four specific redacted items. For teams running agents in production, the takeaway is to test monitoring adversarially and end to end rather than assume it works.
Read more — METR
Docker Sandboxes + BAND: Multi-Agent Teams With Outbound-Only Connectivity and Proxy-Injected Credentials
Docker showed how to connect isolated agents into a team using BAND, a collaboration layer that gives agents persistent identities, shared rooms with humans, @mention routing and visible tool-execution events. Each agent runs in its own Docker Sandbox microVM, with its own kernel, filesystem, Docker daemon and network, and joins a BAND room through the bandhq/band-python-kit sandbox kit. In the example, a "Repo Doctor" agent fixes a failing test in a mounted workspace when it is mentioned. A hosted planner and research agent share the room but don't need sandbox access, because only Repo Doctor touches local files.
The security design is worth copying. All connectivity is outbound: the agent opens a WebSocket to BAND, so nothing has to reach into the sandbox. BAND delivers only messages that mention the agent, which keeps its context narrower than the full room. That also limits how much injected content from other participants it sees. The kit's network policy allows only BAND and Python package hosts by default. Any other access, such as api.anthropic.com, has to be granted explicitly with sbx policy allow network, and sbx policy log lets you audit actual traffic against the policy.
Credentials never enter the sandbox. sbx secret set-custom stores the real BAND and Anthropic keys on the host, binds each one to a single sandbox and destination host, and injects it into outbound requests. Inside the VM the agent sees only a placeholder value. If the agent is compromised, it can't steal keys it never had, and it can only use them against the hosts it was scoped to.
Read more — Docker Blog
Links & Sources
- Donating Agent Skills to the Agentic AI Foundation
- Study Finds AI-generated Code Fails to Boost Productivity Due to Downstream Bottlenecks
- Turning Database Grading into RL Rewards: Post-Training Agents with ThinkingBox
- Red-Teaming OpenAI's Internal Agent Monitoring Systems
- Review of the "Misalignment in high-stakes settings" section in Anthropic's Risk Report (August 2026)
- Your Agent Runs in a Docker Sandbox. Now It Can Join a Team.
You May Also Enjoy
