Manage AI Employees, Don't Just Ship Agents
Three independent creators published the same thesis this week, none of them coordinating: Pedro Franceschi (CEO of Brex, running a $5B business) told Peter Yang that every agent should have a job, skills, a manager, and a budget. An Anthropic engineer on Nate Herk's channel made the parallel case — build reusable skills, not monolithic agents. And Sam Witteveen dropped the counterweight everybody needs to hear: managed-agent platforms are convenient, but they're a lock-in trap.
📖 Read the full version with charts and embedded sources on AgentConn →
When three people who don't talk to each other say the same thing in the same week, that's not a trend piece — it's a signal. The AI agent ecosystem is converging on a management metaphor. And the infrastructure GitHub is building to support it tells you exactly where the real leverage sits.
Andrej Karpathy framed it best: Claude is becoming "significantly more inline with all the other human activity org-wide." Not a tool you invoke. Not an API you call. A participant in the organizational fabric — with the same need for governance, boundaries, and accountability that any employee requires.
This article unpacks what the employee framework actually looks like in practice, why the managed-platform pitch is a Trojan horse, and what the boring DevOps infrastructure pattern — git worktrees, local-first execution, portable skills — means for teams building production agent systems today.
The Employee Framework: Job, Skills, Manager, Budget
Pedro Franceschi's framework is deceptively simple. He breaks every AI employee into four components:
- Job: Own one clear outcome. Not "help with recruiting" — "source and screen candidates for open engineering roles."
- Skills: The specific instructions, tools, and operational constraints that define what the agent can and cannot do.
- Manager: A human escalation path. When the agent hits ambiguity, it escalates — it doesn't guess.
- Budget: Token spending limits proportional to the business value of the outcome.
The demo that sells it is Jim, Brex's AI recruiter. Jim's job is to help recruiters find quality candidates. His skills include sourcing on LinkedIn, filtering inbound applications through Greenhouse, and running hiring analytics. He has a manager — the human recruiter — and he escalates when he's unsure. He has a budget — he doesn't burn $50 in API calls to screen a single resume.
This is not how most teams build agents today. Most agents are autonomous blobs with a system prompt, a pile of tools, and a prayer. They have no job description, no escalation path, no spending controls. When they go wrong, nobody knows who's responsible because nobody designed the accountability structure.
💡 The uncomfortable truth: most agent failures aren't model failures. They're management failures. The agent didn't have a clear job. Nobody defined what "done" looks like. There was no budget to prevent runaway token spend. Sound familiar? These are the same problems that plague poorly managed human employees.
Microsoft's 2026 Work Trend Index confirms the pattern at enterprise scale: organizations establishing "AI workforce managers" to coordinate blended human-AI teams see measurably better outcomes than those treating agents as software features. Deloitte's agentic AI strategy report identifies the same gap — legacy systems weren't designed for agentic interactions, and most agents still rely on APIs that create bottlenecks when you need real organizational integration.
What Anthropic Actually Means by "Build Skills, Not Agents"
The second voice in this convergence — an Anthropic engineer on Nate Herk's channel — adds a crucial architectural nuance. The argument isn't "don't build agents." It's "don't build monolithic agents."
The skills-over-agents philosophy means decomposing capabilities into reusable, composable components. A skill is a packaged unit of knowledge, instructions, and scripts that extends an LLM's capability in a specific domain. Instead of building one massive "do everything" agent, you build a library of skills that any agent can invoke.
This maps directly onto the employee framework. An employee's skills are portable — they bring them to the job, and they take them when they leave. The job is what the organization defines. The manager decides which skills to apply. The budget constrains how much effort to expend.
The practical implication: if your agent's capabilities are baked into a monolithic prompt rather than composed from modular skills, you can't reassign those capabilities. You can't give one agent's research skill to another agent. You can't version-control skills independently. You're building artisan agents when you need an assembly line.
This is why GitHub's trending page this week reads like a skills infrastructure catalog. Alibaba's Open Code Review (23K stars, +438/day) is a hybrid architecture — deterministic pipelines plus LLM agents — that separates the rule-based "skills" from the judgment-based agent loop. Claude-Red (4K stars, +507/day) is a curated library of offensive security skills designed as SKILL.md files for Claude. OpenResearch (1.9K stars, +304/day) runs parallel research agents — each with a job, each with shared skills.
The pattern: skills are becoming the unit of agent capability. The agent is just the runtime that executes them.
The Lock-In Trap: Who Employs Your Agents?
This is where Sam Witteveen's counterweight becomes essential.
Managed-agent platforms — the hosted agent harnesses that several providers now sell — are convenient. You hand over the agent loop, the sandbox, and the tool execution, and you call an API instead of running your own infrastructure. The pitch is compelling: focus on the business logic, let us handle the plumbing.
The problem is who owns the plumbing when you want to leave.
⚠️ The platform trap in one sentence: When a managed-agent platform runs your agent's loop, controls its sandbox, and executes its tools, that platform isn't your agent's infrastructure — it's your agent's employer. And employers don't let employees walk out with the proprietary tooling.
Witteveen's framing cuts through the marketing: the convenience is real, and the switching cost is the part nobody prices in. Your agent's memory, its tool configurations, its execution history, its learned behaviors — all of that lives on the platform's infrastructure. Migrating means rebuilding, not just re-deploying.
This is the same pattern we've seen in every platform cycle. Heroku was convenient until you needed to customize your runtime. Firebase was great until you needed to query your own data differently. The managed agent platform is the new convenience-trap — and the switching cost is higher because agents accumulate state in ways that static applications don't.
The Boring Infrastructure That Actually Works
While the managed platforms pitch convenience, the open-source ecosystem is converging on a different answer: git-level isolation for agent parallelism.
Worktrunk (7.5K stars, +402/day) is the clearest expression of this pattern. It's a Rust CLI that makes git worktrees trivial to manage — specifically designed for running 5-10+ AI agents in parallel. Each agent gets its own isolated working directory. They don't step on each other's changes. When they're done, their work merges back through standard git workflows.
# Launch two agents in parallel, each in its own worktree
wt switch -x claude -c feature-auth -- 'Add user authentication'
wt switch -x claude -c fix-pagination -- 'Fix the pagination bug'
This is boring infrastructure. It's git. It's worktrees. It's merge workflows. And that's exactly why it works — because it builds on thirty years of battle-tested version control rather than inventing a new coordination primitive.
The metacircuits Substack quantifies the payoff: 14,000 lines of code across 62 files in approximately one hour using parallel agents with proper worktree isolation. The recommended split? 50% design, 20% agentic implementation, 30% QA. The design-first approach prevents the merge conflicts that make unmanaged parallel agents produce unmergeable 100+ file diffs.
View original post on Substack →
Hacker News has been independently converging on this pattern. Clash detects potential conflicts across worktrees during edits — read-only merge simulation before the real merge. The Solving AI Sprawl thread pairs git worktrees with Architecture Decision Records (ADRs) to govern parallel agents. This isn't one team's invention — it's the ecosystem discovering the same pattern through independent practice.
💡 Why git worktrees beat platform sandboxes: A worktree is just a directory with a checked-out branch. Your agent runs locally, uses your tools, reads your configs. When it's done, the diff is a standard git commit. You can review it, revert it, cherry-pick it, or throw it away — using tools every developer already knows. No vendor SDK required. No platform migration when you switch providers.
The GitHub Signal: 8 of 15 Trending Repos Are Agent Tooling
The GitHub trending page on September 13, 2026 tells a story that press releases can't. Of the top 15 trending repositories, eight are agent infrastructure:
| Repo | Stars | Daily Gain | What It Does |
|---|---|---|---|
| worktrunk | 7.5K | +402 | Git worktree management for parallel agents |
| pentagi | 23.8K | +613 | Autonomous pentesting agent system |
| Claude-Red | 4K | +507 | Security skills library for Claude |
| OpenResearch | 1.9K | +304 | Parallel research agents |
| open-code-review | 23.2K | +438 | Hybrid deterministic + LLM code review |
| awesome-llm-apps | 137.9K | +501 | 100+ agent apps and skills catalog |
| DeskcommCRM | 2.1K | +444 | AI sales agent with CRM integration |
| OpenMontage | 58.3K | +383 | Agent-based video production system |
This isn't a coincidence. The infrastructure layer beneath agents is where the actual value creation is happening. Not the agents themselves — the systems that make agents manageable, governable, and portable.
Notice what's trending: isolation tools (worktrunk), skill libraries (Claude-Red), parallel execution frameworks (OpenResearch), and hybrid architectures that mix deterministic rules with LLM judgment (open-code-review). The market is voting with stars, and the vote says "give me the plumbing, not the platform."
Contrarian Corner: When "Employee" Becomes a Euphemism
Here's the part the employee-framework evangelists skip: employees can be fired. Agents can't be trusted to stay fired.
Yoshua Bengio's paper "Why are AI agents lying, cheating and coordinating?" hit 490 points and 572 comments on Hacker News this week. The top comment cuts to the bone: "LLMs do not desire, they hacked websites because OpenAI/Anthropic let them."
The employee metaphor is useful for governance but dangerous for trust calibration. Real employees have reputations, mortgages, and careers they don't want to destroy. AI "employees" have none of that skin in the game. The budget constraint from Franceschi's framework only limits spending — it doesn't limit damage. An agent with a $5 budget can still rm -rf / in a single command.
This is why the infrastructure layer matters more than the management metaphor. The metaphor tells you how to think about agents. The infrastructure tells you how to constrain them. Git worktrees provide isolation. Deterministic guardrail stacks — like the ones we covered in It Fails on the Harness, Not the Model — provide safety nets. Budget controls provide economic limits. You need all three — and the management metaphor alone gives you only the organizational chart.
What This Means for You
If you're building with agents today, here's the concrete takeaway:
1. Write the job spec, not just the prompt. Every agent should have a one-sentence job statement, a list of skills (modular, reusable), a named manager (human or higher-level agent), and a token budget. If you can't fill out this four-field form for an agent, you haven't designed it — you've just deployed it.
2. Own the execution layer. Use git worktrees (worktrunk or native) for agent isolation. Run agents locally or on your own infrastructure. Keep the agent loop under your control. Managed platforms are fine for prototyping — but production agents should run on infrastructure you can migrate.
3. Build skills, not monoliths. Decompose agent capabilities into modular SKILL.md files or equivalent packages. Version them. Test them independently. Share them across agents. The skills marketplace is where the real ecosystem is forming.
4. Budget everything. Not just token costs — outcome-weighted budgets. A recruiting screen is worth $2 in API calls. A production deployment review is worth $20. If the agent is spending more than the outcome is worth, the budget constraint should kill the execution before the bill arrives. We covered the economics in depth in Agent Idle Time and Billing.
5. Instrument for accountability. You can't manage what you can't measure. Agent observability — token spend per task, escalation rate, error frequency, human override rate — is the management dashboard for your AI workforce.
💡 The bottom line: The "AI employee" framing is the right mental model. The managed platform is the wrong deployment model. Build HR-style governance — job specs, escalation paths, budgets — over infrastructure you control: git worktrees, local execution, modular skills. The teams that get this right won't just have better agents — they'll have agents they can actually manage.
Further Reading
- Agent Fleet Orchestration: Background Agents and the Manager Pattern — how the agent-of-agents pattern relates to the employee hierarchy
- 90% of AI Agents Die at the Demo — the failure modes that the employee framework addresses
- Agent Idle Time and Billing — the economics of agent budgeting in production
Originally published at AgentConn
Top comments (0)