Agents are your new employees

Your Moat Is Currently a .MD File

Here's the call for any exec running an AI strategy right now. Agents are also the new employee. And most leadership teams are still pouring all their training and process budget into people working with people, when the teams pulling ahead are training their people to work with people AND agents. The way you do the second part is by writing down what your best operators know so the agents can read it. The library of skill files your team builds is the new employee handbook. Without it, every agent you deploy shows up like a brilliant new hire who never got onboarded, makes preventable mistakes, and burns weeks of trust before anyone realizes what's missing.

The format started as markdown (the plain-text file format you've used in every Notion doc and README), and it's already evolving: an engineer on the Claude Code team is shifting his default output from .md to .html because the richer canvas (tables, SVG diagrams, interactive sliders that export their settings back into prompts) surfaces information his colleagues will actually read. Tomorrow it'll be something else. The format is liquid; the artifact is the asset.

The real moat is the framework around the artifacts. Every interesting team building agent systems is converging on the same shape: atomic units of work (one skill, one job, no dependencies on each other) plus a routing layer that picks which one to run when. Browserbase's Autobrowse graduates each successful browser-agent task into a reusable skill the next agent loads instead of re-deriving: cost and time on a Craigslist task dropped roughly in half by iteration four. Matt Van Horn shipped 30+ atomic, agent-native CLIs (Linear, Flight GOAT, ESPN) plus a factory that mints new ones for any service. And our own plugin work over the last six weeks landed on the same shape: atomic skills, commands that chain them, and an orchestrator that routes natural-language requests to the right command and never does the work itself. Three teams, three problem spaces, one architecture; everything else (model, file format, vendor) is packaging your team will swap five times in the next two years.

Here's the part most execs don't want to hear. You wouldn't hire a new human employee with zero onboarding doc and be surprised when they made mistakes for six months. That's exactly what most companies are doing with their agents right now. The catch-up move is simpler than it sounds: pick one workflow your team runs constantly (the one where everyone keeps saying “I wish AI could just do this”), have the person who runs it best spend a Friday afternoon writing down in plain English what they do and the edge cases that matter, and you've written your first skill. Do that five times across five workflows over a month and you have a starter library any of the major AI platforms can load tomorrow. Hand it to engineering to wrap in a routing layer. You're now onboarding your agents the way you'd onboard your humans, and you're ahead of 90% of companies whose AI strategy is still a vendor RFP and a model preference.

How To Build A Plugin That Doesn't Suck

You don't have to write a single line of code to use this section. But if you're an exec figuring out how to operationalize agents on your team, what to staff, how to structure the work, how to delegate to AI without ending up with one bloated chatbot that nobody can explain, the architecture below is the cheat code. We've watched teams burn six months trying to scale a single mega-prompt before someone figures this out. Here's the shortcut.

The principle: any system you hand to a team of agents should have three layers, not one. Skills do the actual work, commands chain those skills into recipes, and an orchestrator routes the user's natural-language request to the right recipe. Each layer has one job and never does the others' jobs.

1. Skills are the atomic units of work. A skill is a single, well-named job: “draft a payroll forecast,” “chase an overdue invoice,” “summarize last week's customer tickets.” One skill, one job, no dependencies on other skills. If you can't describe what it does in seven words without using “and then,” it's actually two skills. Build and test each one independently; the whole point of atomic is that they compose later.
2. Commands are the recipes that chain skills. A command stitches one to three skills into a workflow with an approval gate between each step. /plan-payroll might run the cash forecast skill, then the invoice-triage skill, then draft the actual payroll moves, with a human approving at every handoff. Don't chain more than three skills per command. Past four you get latency, context drift, and the unmistakable feeling that the agent is wandering.
3. The orchestrator is the front door. This is the layer most teams skip, and it's the most important one. The orchestrator listens to natural language (“I'm stressed about making payroll next week”), matches it to the right command, explains in one sentence what it's about to do, and runs the command on confirmation. Critically, the orchestrator never does the work itself. It only routes. The moment it starts pulling data or drafting emails on its own, the separation collapses and you're back to a single bloated agent that everyone is afraid to touch.

Why this matters for execs: The teams whose AI work scales are the ones whose people can answer three questions: what atomic jobs do our agents do, who owns each one, and what's the routing layer that picks between them. The teams whose AI work plateaus built a single mega-prompt that handles “everything,” and three months later nobody can explain what it does or how to extend it. Ask any vendor pitching you an “AI agent” right now what their orchestrator routes between and what each underlying skill does. If they look confused, that's your answer.

What to do Monday morning: Have your team list the 10 most common requests their humans-plus-AI workflow handles today. Each one is a candidate skill. Group them into 3-5 workflows. Each workflow is a candidate command. Then figure out who owns the routing layer that decides what to run when. That's the framework. The plugin format, the model, and the file extension all flow from there.

Also worth your time

A designer's blueprint for the rest of us

Mang Tomas (founder of Design Code) breaks down design.md, the open-source spec for porting design systems into agent-readable markdown. The pitch: stop one-shotting beautiful landing pages and start carrying the same design DNA across web, mobile, slides, and motion. A master class in design taste as a moat for non-designers.

A virality scorer for video clips

Higgsfield shipped a Virality Predictor that takes any 15-second clip and returns a hook score, hold rate, and a heatmap of which brain regions activate while watching it. Available via MCP and CLI. Useful for anyone running paid creative, podcast clips, or social content.

The bimodal engineer is here

The Claude Code team's engineering lead said this week they're hiring exactly two profiles right now: creative builders with strong product sense, and deep systems experts for the hard parts. The general-purpose senior engineer in the middle is the squeezed role. If you're staffing an AI-native team, the hiring shape probably doesn't look like what you have today.

The first robotic Buddhist monk

A humanoid named “Gabi,” about four feet tall, took robes in South Korea last week, clasped its palms in prayer, and bowed. Yes, this is real. Worth ten seconds for the photos, and worth a minute of thinking about which white-collar professions stop being human before you'd expect.

See you next Tuesday. Sven