Two AI Teams, Human-Gated: Running a Dev Team and a Content Team as Claude Code Subagents | by Sunny Park | Jul, 2026
A year of building AI into real business operations in public — assistants, an MCP server, multi-agent, a self-built ontology engine, an order-to-cash series. This isn’t a new build; it’s how I work: two teams of Claude Code subagents (dev and content) do the labor, and I keep every decision. Generation is the agents’; the decision is mine.
For the past year — July 2025 through June 2026, alongside a full-time job — I’ve been building AI into real business operations in public, and the shape of it kept changing: piecemeal assistants for helpdesk, meetings, and sales; then an enterprise-style MCP server; single-agent to multi-user (per-user CRM, email, and ChromaDB permissions) to multi-agent by domain; a transport migration from SSE to resumable/streamable HTTP; client-and-model A/B across Claude Desktop and Cursor, Claude, GPT, and local Llama, Google ADK and LangGraph; and finally a self-built ontology engine (OOSDK) that encodes each company’s policy as declarative rules. The order-to-cash series — live against Salesforce, Odoo, and Gmail — is the latest chapter of that arc, not the whole of it. The obvious question I get is “full-time job and all this — where did the time come from?” The honest answer isn’t that I found more hours. It’s that I changed how I work: I organized AI agents into a role-split team and moved most of the labor off myself. I run two teams of Claude Code subagents — a development team and a content team — that do the reading, drafting, and editing, and I spend my own time almost entirely on decisions, not keystrokes. That structure is the engine; it’s how a full-time job and a year of independent building coexist. This article shows what it actually looks like on one concrete session: not a new build, but my agent teams tidying up a repo I’d already built and made public.
One honest note on scale, once, so it’s out of the way: the session below is a three-file, +42 −6 documentation fix — deliberately chosen for what it lets me show, which I’ll explain in a moment. Read this as a method, not a milestone.
And the method is the point precisely because the autonomy narratives skip it. The stories that go viral are the ones where an agent swarm rewrites three-quarters of a million lines over a weekend. My first question watching those is never “how much did it write.” It’s “who decided, and where.” Because I ship a public repo other engineers clone, and the interesting problem in agentic development isn’t generation — models generate fine. It’s landing a change inside a real repository safely, which is a governance problem, not a throughput one. So I ran the smallest honest version of that problem on my own repo and watched exactly where the human belongs.
Why refactoring, and why now
Here’s the part I want to be straight about, because it’s the real reason this example is as small as it is. This “agent team behind a human gate” setup isn’t a demo I assembled for the article. It’s already how I do most of my day-to-day development — the reviewing, the refactoring, the deploying — and have for months. The problem is that I can’t show most of that work publicly. Point a camera at my actual daily workflow and you’re pointing it at closed systems, credentials, and internal architecture that are supposed to stay closed. Showing the whole thing would leak exactly what shouldn’t be shown.
So I picked the one slice I can show end to end without a single leak: refactoring a repo I had already sanitized and made public. The narrowness isn’t about making the diff look tidy or performing humility. It’s that this is the part of my real workflow I can open all the way up — a window onto the method with nothing behind it that needs to stay shut. The method is the product here; the public refactor is just the pane of glass you get to look through.
And a growing repo gives me something honest to point that glass at. As a repo grows over months, it does a predictable thing to a codebase: the executable parts stay correct because tests and daily use keep them honest, while the descriptive parts — counts in a docstring, a version header, a README’s setup steps — rot silently because nothing asserts on them. That gap is completely natural, and checking and repairing it with an agent team is genuinely useful work — which lets me show the method without exaggerating what AI did. Nobody has to take “the agent was brilliant” on faith. The diff is four documentation edits; the interesting content is entirely in the gates around them.
I’ve spent four Business Cases arguing one thesis: AI advises, a human approves. In the order-to-cash pipeline I let a model decide exactly two things — how to split a short shipment, and who to chase first on overdue invoices — and kept every dollar-touching step deterministic behind a human gate. What I hadn’t written up is that I run my own workflow the same way —including the pipeline behind the videos that ship alongside it.
Two teams, one folder of Markdown files
There’s a lot of explainer content right now on “what a Claude Code subagent is.” I’ll skip the tutorial and show what actually matters for governance: every agent I run is a Markdown file under .claude/agents/, and the file’s frontmatter declares a name, a role description, and — the load-bearing field — the exact tools that agent is allowed to touch.
That folder holds two teams. The dev team is the dev-* agents — dev-reviewer, dev-refactorer, dev-developer, dev-deployer, plus an architect, a debugger, an explorer, and a migrator. The content team is the rest — content-strategist, content-youtube-scripter, content-youtube-thumbnail-designer. Both teams are governed the same way: the tools line, not a prompt, decides what each member can do.
That tools line is not documentation. It’s a capability boundary. Read the reviewer’s card:
# .claude/agents/dev-reviewer.md (frontmatter; description translated from the original)
name: dev-reviewer
description: Pre-merge code-quality reviewer. Flags bugs, security, and
quality issues by severity. Points them out — performs no edits.
tools: Read, Glob, Grep, Bash, WebSearch, WebFetch
model: opus
Notice what is not in that tools list: Write and Edit. The reviewer cannot modify a single file, because the harness never hands it the tools to do so. Its own card states the consequence plainly — it “has no Write/Edit tools, so it is structurally incapable of modifying code.” This is the same move I make in the ERP pipeline, where a model’s recommendation is held and only deterministic code can execute it. Here the separation isn’t a runtime flag; it’s the tool grant itself. A reviewer that physically cannot write is a reviewer you can trust to review.
The dev team splits along that line. Two agents can write:
# .claude/agents/dev-refactorer.md — can edit, but only structure
tools: Read, Glob, Grep, Write, Edit, Bash
# core rule: behavior must never change — same input, output, and side effects.
# refuses to start if no tests exist for the target.
And the one that reaches the outside world — the deployer — is deliberately kept away from the code entirely:
# .claude/agents/dev-deployer.md — can push and dispatch, cannot author code
tools: Read, Glob, Grep, Bash, PowerShell, WebSearch
# no Write/Edit. every `gh workflow run` requires explicit human approval.
So the dev roster reads like a separation-of-duties chart: dev-reviewer finds problems but can’t touch them; dev-refactorer restructures but can’t change behavior and won’t run without tests; dev-developer adds new code; dev-deployer ships but can’t author. No single agent can see a problem, rewrite it, and push it. That asymmetry is the governance, and it’s declared before any model runs a token.
The content team runs on the same rule — including the videos that ship with it
And this isn’t only about development. The YouTube content that shows these systems — the demo videos — gets drafted with the same content team’s help.
A strategist, a scripter, and a thumbnail-designer agent draft the video’s title, description, keywords, and even the thumbnail design prompt. These agents can read, write, and edit files — but they can’t run or publish anything. They draft, and I decide.
I don’t write the YouTube video’s title from a blank page. The strategist proposes a slate of angles and titles, and I pick, cut, and rewrite. Development or content, it’s the same contract: generation is the agents’; the decision is mine.
None of that should be read as “AI made the content.” A draft is not a decision. Every title that actually ships, every line I’m willing to put my name on — I chose it or rewrote it. The agents give me options at speed; I give them judgment.
Time is the real subject
That’s the answer to the “full-time job, how?” question, stated plainly so it isn’t just implied. I did not get more hours this year. I moved the labor — reading a large codebase, drafting edits, auditing for drift, producing first-pass titles and scripts — onto two teams that work in parallel and never get tired, and I concentrated my own limited time on the handful of points where a decision actually matters. The leverage isn’t that AI is fast. It’s that delegation lets a person with a day job spend their scarce hour deciding instead of typing. Take that framing into the session below: watch how little of it is me producing, and how much of it is me choosing.
The workflow, drawn as gates
The dev session followed a fixed spine, and every arrow between roles is a place I said “yes” before the next agent moved:
