Here's a question I keep coming back to. When humans and agents are both contributing to the same operation — how do you bring a new one up to speed?
Not “give an agent one task and let it run.” The full thing. Onboarding a new contributor — human or agent — to a live operation where five people already have their hands in the work, decisions were made yesterday, more are pending tomorrow, and three drafts are in flight at this very moment.
It's the question every team trying to run real work with agents is bumping into. And it turns out it's a question I've been bumping into for years — long before agents were anywhere near the picture.
Couldn't Skills Solve This?
The answer most people in the AI agent world are reaching for right now is Skills.
Anthropic introduced the concept carefully — a skill is “an organized folder of instructions, scripts, and resources that agents can discover and load dynamically.” Folders. Not single files. Scripts. References. Progressive disclosure. They compared building a skill to “putting together an onboarding guide for a new hire.”
It's a real, well-designed primitive. And the instinct is right — if you want to give an agent procedural knowledge it can pull from a filesystem and apply to a task, Skills are exactly how you do it. By design, a properly-built skill already carries the brand context, the references, the asset pointers, the templates. The popular version has flattened a bit in the wild — the conversation has collapsed into “write a SKILL.md and you're done,” when Anthropic's own framing is broader — but even when you give Skills their proper, fuller definition, they don't get you all the way to running an actual operation.
Here's why.
A skill is, at its core, a playbook for a capability. The PDF skill teaches an agent how to fill out a PDF. The video-editing skill teaches it how to cut a clip. It's a self-contained onboarding artifact for doing one thing well.
But onboarding a new contributor to real work isn't handing them a playbook. It's plugging them into a live operation. What's in flight right now. What was just shipped this morning. What's pending approval. What everyone else is currently working on, which branches are open, what got decided last week and why. The playbook is part of it. The state of the operation is the rest of it — and the rest of it is most of it.
Skills weren't built to carry that. They couldn't be — a skill is by definition a self-contained capability package. An operation is a living, multi-contributor process. Different things.
A skill is the chisel. We need the whole workshop.
The good news: we don't have to invent the workshop. Engineers have been using it for two decades. It's the repo.
I've Lived This Problem for Years
To be clear, this isn't a new problem the agent era introduced. The agent era just made it more obvious and more urgent. I've been living the same problem for years — long before any of this.
I came from a non-technical background. For years I worked inside the standard knowledge-work stack — Google Docs, Drive, Notion, Slack, a handful of SaaS tools held together with tabs and goodwill. On the surface, it was fine.
If I'm being honest? It wasn't.
Context for every project was scattered across five tools and three people's heads. Onboarding a new teammate took a week of “oh, there's also this doc, and this folder, and this thread, and the thing only Sarah remembers.” Multiple people on the same doc meant Suggesting Mode in Google Docs, which is barely functional. Version control didn't really exist — Notion auto-saves, but there's no way to formally register a checkpoint that says this is the version we agreed on. History was noisy, lossy, and impossible to reason about.
I didn't have words for what was missing. I just knew the whole thing felt clunky.
Then I moved into tech.
Engineers Already Built the Workshop
The first thing that struck me about how engineers work — onboarding a new developer to a project today is essentially one command. Clone the repo. Point an AI agent at it. Within an hour, the new dev understands the project, its history, its conventions, the open branches, who's working on what, what's been merged, what's pending review.
Try doing that for a non-technical role.
There's no clone command. There's no equivalent thing to point an agent at. The “project” lives across Drive folders, Notion pages, Slack threads, three SaaS tools, and four colleagues' heads. The week-long onboarding I described earlier isn't a quirk of bad organization — it's structural. There's no environment to clone.
What engineers have is git. The repo. Two decades of refinement. Every change has an author, a message, a parent. You can branch. You can merge. You can revert to any moment with one command. The entire history of a project is sitting right there — inspectable, attributable, replayable. Single source of truth, with rich state and rich history baked in.
Then AI agents showed up, and the picture got 10x more interesting.
With agents in the loop, the repo isn't just a record. It becomes a live environment. Humans and agents can both contribute to the same workspace, with clean conflict resolution that already exists. You can spin up an agent on a branch, let it run, and review what it did before anything merges in. Want to onboard a new agent — Codex, Claude, OpenClaw, Hermes, whatever ships next month? Same one command. Same as onboarding a human dev. Connect to the workspace.
That's when the question started bugging me: why is this paradigm locked to people writing code?
Most knowledge work isn't code. It's marketing, sales outreach, customer support, ops, research, design. If anything can be represented as files — and I think it can — then the coding-agent paradigm should work for the rest of the work too.
So I decided to actually try it.
I've Been Running My Marketing Out of GitHub
For the past two months, my video marketing and cold email outreach have lived in GitHub repos. Real work. Real output. Real commits.
Branches. PRs. Reviews. Rollbacks. Applied to things that have nothing to do with code. And the wild part — it works better than the SaaS stack it replaced. Faster handoffs. Cleaner history. Real collaboration between me, my team, and a small army of agents. Onboarding someone new — human or agent — actually feels like onboarding now, not archaeology.
The lessons from doing this are more interesting than the setup.
Why This Actually Works
AI models are natively good at filesystems
This is the direction the frontier is already moving. AGENTS.md, MCP config files, skill files, repo-native agent work — every serious agent harness treats the filesystem as home base. You're not bolting AI onto a workflow it doesn't understand. You're meeting it where it already lives.
Anything can be represented as files
This sounds abstract until you actually do it. Then it becomes obvious.
- Context — persistent context is a file. Dynamic context is instructions for fetching it.
- Knowhow — a SKILL.md file plus the scripts it runs and the references it points to. (Skills live inside this. They just don't make up all of it.)
- Capabilities — instructions for using external services.
- Working state — folders that hold progress in flight.
- History — every commit is a checkpoint with an author and a reason.
Once you accept this, the question stops being can my work fit in a repo? and starts being what would my repo look like?
The repo solves the context problem for agents
Agents can navigate to what they need, when they need it, the same way an engineer browses a codebase. You don't have to dump the whole company into a prompt. Progressive discovery does its job — the same principle that makes Skills work, scaled up from a capability to an entire operation.
Agents write code on the fly. You don't have to pre-build the HOW.
This is the part most people are still sleeping on.
In the SaaS era, every new capability needed engineers to ship a feature. With agents, you give them context, capabilities, and docs — and they write the code in the moment.
Concrete example. I used to assume “recording product-screen tutorials with realistic, human-like cursor movement” couldn't be automated. Wrong. My agent spins up Playwright, signs into the product with a dev account, navigates as instructed with non-linear cursor motion, overlays a Mac cursor SVG, and records the screen. I have a folder full of stories like this now — capabilities I assumed didn't exist, that turned out to be a thirty-minute conversation away.
At this point I don't assume I know what AI can't do. I just ask it and test.
Filesystems naturally carry organizational boundaries
A company is hierarchical. A marketing launch project should contain its own ad-account integration file, approval policy, creative tracker, campaign skill, and run ledger — all inline, where the work happens.
Relationships are inferred from folder structure, file location, links, references, permissions, metadata. Hierarchy carries meaning. Access control becomes native to the structure — people and agents see only what they're authorized to see, and agents act only within scoped capabilities, budgets, departments, and approval rules. You don't bolt governance on after the fact. It's already there.
Approvals are baked in
Treat the filesystem as the single source of truth and every modification flows through whatever approval layer you define. An exec records a video → brand manager reviews the PR → it merges into the working tree. No more “did this get approved?” Slack threads. The approval is the merge.
The Hard Parts
I don't want to pretend this is easy. It's not.
Setting up the environment correctly is hard
This is new territory. Most people don't yet know how to structure these well, and a badly-structured repo will quietly poison everything downstream. The path forward is templates for common use cases — video production, performance marketing, cold outreach — plus forward-deployed engineers who help bring the concept to life inside a specific team. You can't just hand someone a blank repo and say “good luck.”
Extracting tacit knowhow is hard
A lot of expertise lives in people's heads as muscle memory. Most people can't sit down and write it out cleanly in one session. The right tooling has to extract knowhow from doing the work, not from interviewing about it.
What I'm Building
The bet: you can apply the coding-agent paradigm to all knowledge work — if you give it the environment to live in.
That's what I'm working on now. Three things, specifically:
- A way to spin up persistent, isolated environments for non-code work — with the safety and security of a dedicated machine, without having to buy a Mac mini for every workspace. One single source of truth per operation.
- A way to plug that environment into any agent harness — Claude, Codex, Hermes, OpenClaw, whatever ships next month. Pick your agents. Pick your tools. The environment is the constant.
- A way to review contributions from many agents and many humans — with the right people approving the right things, the way PRs already work in code, applied to marketing creative, sales sequences, customer responses, anything.
Skills live inside it. So does everything else.
If that's interesting to you, follow me. I'll post when it's live.