How I Learned to Create Subagents—and Why I Cannot Go Back
The first time I tried to “create subagent” behavior without naming it, I was just desperate. One big chat, one giant context dump, one friendly model trying to be my architect, my copy editor, my debugger, and my therapist about the merge conflict. It worked until it did not. The turning point was not a clever framework diagram. It was the quiet realization that my brain already runs in sub-tasks—and pretending otherwise was costing me clarity. This post is about AI subagent creation in that human sense first: why the split matters, how I stumbled into it, and what I keep doing now that I have better language for the pattern.What I mean when I say subagent
I am not going to hand you a taxonomy that will age like milk. In my daily life, a subagent is any slice of work with a tighter job description than “help me with everything.” Sometimes that slice is literally a second conversation. Sometimes it is a smaller prompt inside the same thread with a header that reads like a contract: you are the linter-brain, you are only allowed to nitpick tests. The product names change; the shape does not. When I talk about AI subagent creation, I am usually talking about carving reality into those slices on purpose instead of letting the model improvise a personality that does too much at once.If that sounds like orchestration, good—that is the word I reach for when I am being polite to engineers. If it sounds like parenting a team of very fast interns who never sleep, that is also accurate. The emotional reason I need it is simpler: I get overwhelmed when a single assistant tries to optimize for every objective at the same time. I want one voice to be narrow on purpose.Why I need subagents more than I need a bigger model
There is a seductive story in our field: scale fixes everything. I have felt the pull. A larger context window feels like a wider desk, and who would not want that? But my mistakes were rarely “the model is too small.” They were almost always “I mixed intentions in one place and then I could not tell which failure mode I was looking at.” Did the answer sound wrong because the model hallucinated, because I implied the wrong constraints, or because I was secretly asking for three incompatible things in one breath? When I create subagent-style boundaries, I am buying myself legibility. I can blame the right layer. I can iterate on the right layer. That sounds cold, but it is also how I stay kind to myself when the output is messy.Another reason is cognitive: I do not hold a whole system in working memory any more than I hold a whole city map. I hold a neighborhood and a direction. Subagents are my way of mirroring that limitation instead of fighting it. One thread for design talk, another for implementation details, another for ruthless review. The handoff between them is where the real work lives, and yes, sometimes I botch the handoff. That is still better than trying to keep every door open in a single mind at once.Claude subagent: the long, patient specialist in my head
When I lean on a Claude subagent pattern, I am usually asking for a voice that can sit with ambiguity. Not every job needs that, but the ones that matter to me often do: writing I care about, architecture where the tradeoffs are human, decisions where the spec is still a sketch. I do not treat “Claude subagent” as a magical incantation. I treat it as a reminder to give the model a role that matches the tone I need—patient, explicit, willing to say “here are three ways this could go wrong” before it offers a clever shortcut.The failure mode I watch for here is softness. A careful voice can smooth errors into confident sentences. That is why my subagent split often includes a sibling role whose only job is to be annoying in the right way: question assumptions, demand citations, rewrite the same paragraph colder. I do not think of that as negativity. I think of it as tension. If I wanted pure comfort, I would not be building software.Cursor and Codex: where the keyboard makes the rules
The story changes the moment my hands are on the keys. Cursor and Codex belong in the same sentence for me because they live in the editor, and the editor is not a chatroom. It is a place where mistakes have diffs, where the computer can show me exactly what I am about to ship, where the cost of a “small” helper decision is visible in red and green. When I create subagent-style separation here, it is less about personas and more about scope: a pass that only touches types, a pass that only refactors names, a pass that only writes tests for the edge case I keep avoiding.I am slower than the tool. That used to embarrass me. Now I treat it as a feature. If Codex can propose three refactors in the time it takes me to drink coffee, the subagent move is to refuse the grab-bag. I want one proposal, one rationale, one review. The interface rewards speed, but my job is to choose a safe shape for that speed. The word people keep reaching for is agentic; the feeling I have is just responsibility with better autocomplete.How I create subagent boundaries without a perfect toolkit
I wish I could tell you I have a clean system with folders and scripts and a dashboard. Mostly I have habits. I name the job in the first line. I list non-goals, because nothing derails a session like an unstated second objective. I separate tool use mentally: this slice can browse, this slice cannot, this slice may only quote what it sees. I keep context isolation wherever the product lets me, and when it does not, I fake it with blunt section headers. It is not elegant. It is survivable.I also keep a private rule: every subagent has an exit. If a slice of work cannot produce an artifact I can hand to another slice—a checklist, a diff, a list of open questions—then I have not really created a subagent. I have just vented into a very smart void. I am not judging venting. I am just honest about what I need when I am trying to ship. AI subagent creation, for me, is less about spinning up an army and more about making handoffs real enough that future-me recognizes them.The part nobody puts in the marketing: shame and overreach
I have asked an assistant to do something morally adjacent to “be omniscient” and then felt a weird shame when the answer was mid. That shame is a signal. It usually means I collapsed roles. Subagents do not fix ethics by themselves, but they help me see where I am smuggling a shortcut—like asking for certainty when I only have a rough guess, or asking for a verdict when I need a list of options. I am still the person who has to own the final message to another human. The model can help me draft, challenge, or compress; it cannot be my conscience on retainer.I also need subagents when I am excited. Enthusiasm is a beautiful thing in life and a dangerous thing in automation. A narrow role is a brake. It keeps the system from “helpfully” doing too much in one burst—another way of saying: I want to create subagent constraints because my own taste needs guardrails, not because I think the model is evil.What I would tell last-year me about the whole arc
I would say: you are not late, and you are not bad at this if your first agents felt chaotic. I would say: start with one extra hat, not twelve. I would say: notice where you are already doing handoffs between humans, because those seams are the honest map. And I would say: write the boring lines—goals, non-goals, who owns the output—before you chase novelty. The fancy multi-agent future still runs on the same old skill: being clear.I keep rough notes in public partly because I want a paper trail I can trust later. A corner of that trail lives on MachineLearningX because I like the idea of a site that stays a little imperfect and still useful—essays, fragments, reminders that you can play with how you create a subagent without pretending you have solved intelligence. If you are building something similar in your own notes, I am quietly rooting for you. We are all learning how to share the work with tools that are too capable to use carelessly and too limited to use without hope.