Hi, it's Andreas here.
The most valuable skill you can learn in 2026? Building AI agents. On Wednesday, 17:00 CEST, I teach you how, live and for free: the core components, the mental model, your first working agents in about ten minutes, and at the end I show the 21 agents that run this business day to day. 1400+ people are already in. I hope to see you there.

And the enrollment for the Agentic AI Cohort closes Friday at 23:59 CEST and starts on 1 September. If you or your team should be building agents rather than reading about them, this is the week to decide (only a few slots left).

The new format stays, since it resonated very well. Please continue to share what works and what doesn't, as well as what you would like to see covered. Your feedback helps determine what receives more attention here.

In this issue:

OpenAI halts its biggest training run over cyber risk → An unreleased model, Astra, may have crossed the Critical cyber tier in OpenAI's own framework, so training paused for two weeks and the largest run stays on hold. Releases are unaffected. Interesting that a frontier lab is treating its own model as a threat actor. Worth one question to your CISO.

An anonymous frontier-class model is free on OpenRouter → Ox Alpha: 1M-token context, multimodal, near-unlimited free access for a week, no lab claiming it, fingerprints pointing at China. Early tests put its coding near the frontier at a fraction of the tokens. Frontier-adjacent capability at zero cost is now a recurring event.

Stripe buys OpenRouter, the switchboard for AI models → A reported $7.5 billion for the layer that routes requests across every major model, three years after founding. Routing and billing are consolidating into one company. If your teams or you reach models through OpenRouter, the router and the invoice now have the same owner. Watch the pricing.

Slack turns channels into places where agents build software → Tag Claude, Devin, Copilot or Vercel and it opens a code channel with diffs, live previews, human approval before deploy and an audit log of every agent action. On every plan, including free. Agent work is moving into the place your teams already talk, with review built in rather than bolted on.

Cursor launches Origin, a code host aimed at GitHub → Repos, pull requests and review with Cursor's agent built in, two-way GitHub sync, beta for paid plans. It shipped the same day GitHub was partially down for six hours. If agents write most of the code, whoever hosts the repo owns the workflow.

Last month I worked with a large German car manufacturer on improving their AI usage. The first thing we did was to analyze how many people had built their own private AI setup. We surveyed people across departments and looked at actual usage behavior. The answer was, roughly, everyone. Hundreds of smart people using AI every day, each with their own prompts, their own scripts, their own instruction files. The same workflow copied into a Claude Code directory here and a Copilot directory there, corrected in one place and stale in the other.

I am convinced this problem applies to most organizations. Knowledge and files that improve daily work reside in chat histories, personal configurations, and sent messages and are not available to everyone across the enterprise. This means they go on vacation when their owner does and leave the company when the employee does.

Most enterprises cannot see this, because "AI adoption" still gets measured by how many people logged into the chatbot this month, but a login tells you nothing about what happened after it. When you examine actual usage, the enterprises I have observed closely, ranging from 400 to 400,000 people, exhibit the same pattern: a barbell. Five to ten percent are power users: instruction files, connectors into Outlook and the CRM, agents running every day. They are the evangelists, usually the people who pushed for the tools in the first place, because they tinker with AI outside work and have seen first-hand what it does. Of the rest, roughly a third use AI a few times a day and get a fraction of the value. The others use it sporadically or not at all.

Closing that gap is hard, and I am not sure it is fully closable; if it is, it will take years. There is a quick win hidden within it, which helped the car manufacturer in just a few days to accelerate AI usage, which you can easily copy. Most of the power users at this company had already documented their processes for most of their recurring tasks. They had built dozens of skills and Markdown files for recurring workflows, from weekly supplier defect reports and monthly vehicle launch plans to end-to-end dealer and fleet outreach campaigns.

I have written many times here that I am convinced skills are the most underrated aspect in enterprise AI. A skill is the written version of how your team does a job. The steps, the sources, the output format, the exceptions, the things that are never allowed, saved as plain text files that an agent reads before doing the work. Anthropic published the SKILL.md format as an open standard in December; by this summer roughly 40 tools read it, Claude Code, Codex, Copilot, Cursor and Gemini CLI among them.

A prompt is one request, a skill is a procedure, a job an agent can repeat end to end. At the car manufacturer, a prompt is what a quality engineer types on a Tuesday morning: "Summarize last week's supplier defect reports and flag the outliers." It works for that engineer, that Tuesday, in whatever phrasing they happened to choose, with whatever the model decides an outlier is. The skill version of the same job is written down once: which two systems the reports come from, which plants to exclude because they report on a different cycle, that everything gets converted to defects per million before comparison, where the threshold sits and who set it, the exact table the department head reads, and the rule that supplier names never leave the department. Run the prompt and you get an answer. Run the skill and everyone gets the same one.

But here is why sharing fails when it is attempted casually. Someone writes a good skill and posts it in Slack. Five colleagues copy it into their own folders. Two weeks later the author fixes an edge case in their copy. The five colleagues do not. A month later there are six versions of "the" skill in circulation, all plausible, all slightly different. When two people run what they believe is the same process and get different results, nobody can say why, and the person debugging the wrong output has no way to know which version produced it.

Nobody is being careless here. The moment a skill exists in two places, drift is the default, because every correction now has to happen twice and never does. Copy-paste is how skill libraries die, quietly, while looking healthy.

The fix we landed on at the car manufacturer was boring, which is usually a good sign. One Git repository as the single source of truth for every shared skill. Each person installs it once, as a plugin, which means their tools pull from the repo instead of keeping a copy. Every agent-specific folder is a view of that repo, never a copy. When someone fixes a skill, everyone has the fix on their next run.

Once skills live in Git, you inherit twenty years of software discipline for free. Changes get reviewed like code changes, because that is what they are: shared operational assets that steer how the whole team works. You can see who changed what and why. You can pin a version when stability matters. You can diff a broken week against a working one. And a skill somebody found on the internet gets read before it gets installed, the same way you would (I hope) read a script before running it against production, because a skill file can instruct an agent to do almost anything.

This is the Harness Engineering argument from earlier issues: the model was never the bottleneck, the scaffolding around it was, and a shared skill library is one of its most load-bearing parts.

Before you build the repo, decide what belongs in it, because not every skill should be shared. In practice, every skill falls into one of three scopes, and naming the scope explicitly is most of the governance you will ever need.

Personal skills stay on your machine: your research helpers, your writing voice, the utilities you use in every project. Nobody reviews these, and nobody should have to.

Team skills are the ones the whole group runs: the weekly report, proposal reviews, incident write-ups, client onboarding. These live in the shared repo, get an owner, and get reviewed. This is where the compounding happens.

Project-local skills are tied to one system, one department, or one engagement: the deployment routine for a specific product, the formatting rules of a specific client. They live next to the repository they depend on and die with it.

The structure we settled on is small enough to fit on a slide. One repo with four ingredients:

The contract behind it: team/ holds the canonical team skills, one folder per job, with the SKILL.md carrying the task definition and constraints, and longer checklists or examples in files next to it (the agent loads those only when needed, which keeps context lean). project/ holds repository-specific skills. adapters/ holds the small amount of tool-specific glue, the install scripts that point each agent at the repo, so the canonical version still lives in exactly one place. And registry.yaml is the file that keeps the library honest. Per skill, four lines:

That registry looks bureaucratic and is the opposite. It is what lets you run a monthly sweep for anything not reviewed in a quarter, and it is what tells a new team member which folders they can trust. The exact format matters far less than the habit.

The structure is easy to setup. Whether the library is still trustworthy in six months comes down to five habits:

1. Keep one real example next to every skill. Save the inputs and the approved output of a real run in examples/. Before anyone changes the skill, they run it against that example. If the result no longer matches, the change waits.

2. Adding is easy, approving is not. Anyone can add a skill as a draft, no review needed. It only becomes active when it has an owner, someone other than the author has run it, and it has been used more than once. Drafts stay visible; only active skills get pushed to everyone.

3. Every skill has one owner, and the owner checks it monthly. Run the example, read the file against how the job is done today, update last_reviewed. Anything untouched for a quarter goes back to draft. When a process dies, delete its skill the same day.

4. No copies, and freeze what customers see. Nobody keeps a private copy of a team skill; the agent folders point at the repo. Skills that produce client-facing output, proposals, release notes, invoices, stay on a fixed version until the owner deliberately updates them.

5. Corrections go into the file, not into the chat. When someone fixes an output, the fix goes into the skill the same week, or it will be made again next month, by someone else, slightly differently. A correction that lives only in a thread is folklore regenerating itself.

The payoff compounds. Day one, the repo holds what your power users already had. A month in, it knows your standards, your formats, your exceptions, your escalation rules. A new hire inherits all of it immediately. And the barbell starts to move, because the ninety percent no longer have to become power users to get power-user output. They run what the power users wrote.

I suspect this becomes a real dividing line over the next year. Model access is now roughly equal everywhere; every company can buy the same intelligence. What differs is how much of the surrounding judgment has been written down and shared. Skills are one of the highest leverage things to share and move around to improve AI output across your enterprise.

Try: Hallmark, so your agents stop shipping ugly UIs → An open-source design skill for Claude Code, Cursor and Codex. One install (npx skills add nutlope/hallmark) and the agent stops producing the purple-gradient landing page every model defaults to: 22 themes, a library of page structures, and a slop test the output has to pass before it comes back. Twelve thousand GitHub stars in a month.

Try: Motion, an AI motion designer for launch videos, demos and ads → One sentence in, a finished video out: it handles the research, the design, the animation, the voiceover and the edit. Drop a product URL and it comes back scripted, voiced and rendered; say "make it shorter" and it re-cuts. It now also runs as a skill inside Claude.

Anthropic opened Claude Academy, the training it uses on its own staff → Free, self-paced courses on Claude, prompting, agents, MCP and the API, adapted from Anthropic's internal onboarding.

Google's playbook for agents that survive days-long jobs → Five patterns for long-horizon agents: durable state, checkpoint and resume, event-driven dormancy instead of polling, persistent sessions, delegation to sub-agents. Built on ADK, transfers to any stack.

I take on a small number of advisory engagements each quarter for AI programs that are stuck: reply to this email with the one initiative you would want a second pair of eyes on. And if your team is ready to build, the next Agentic AI Cohort runs September 1 to 24.

Reply with one line on what you are seeing in your own organization. I read every reply.

Liked this issue? Forward it to one person who would find it useful.

And if Human in the Loop has ever helped you rethink or make a decision, I’d love to hear about it. Tell me in 60 seconds.

— Andreas