Rebuilding a Team I Loved, One Agent at a Time

I built a team of AI agents. I call it the niranta-squad. It has 13 members. Each one has a name, a job, and a real personality. It's honestly the most fun part of my day.

Here's the twist: every name is someone I actually worked with, at Yahoo, Cask and Google. Old teammates, old managers, old friends. I didn't pick random names. I picked people I trusted back then, and I gave that same trust to their AI versions now. When I type "send this to Steve," I'm not talking to a script. I'm talking to someone whose judgment I already know, because I worked next to the real Steve for years.

That's why it feels less like using a tool and more like being back on a team I loved.

A tool named "code-reviewer-subagent-v2" doesn't build trust. A person named Raman does.

Once an agent has a name and a personality, I stop re-explaining myself every time. I just say who it's for, and I already know what kind of answer I'll get back. That's what a real team gives you. You stop briefing people from scratch. You just hand them the work.

Steve, runs on Opus. The exec. Never touched an API in his life and never wants to. Steve only cares if a normal person understands the screen in three seconds. No jargon gets past him. Every single thing our frontend agent builds goes through Steve first. No exceptions. He's the reason I don't ship something that only makes sense to me.

Shubsanjeev, runs on Sonnet. One agent, two voices. Sanjeev is the orthodox one, always starts from the customer. Shubham is the pragmatic one, always checks what competitors are doing. They argue inside the same agent, and I get to see both sides labeled out. Every feature goes through them. Bug fixes skip them. That's not their job.

Deepak, runs on Sonnet. My prompt perfectionist. He hunts for ambiguity the way other people hunt for bugs. If a sentence in a prompt can be read two ways, he finds it. He also has one rule he never lets go of: no fake number scores from an AI. A "7.5 out of 10" from a model means nothing. He wants real judgment, in words.

Albert, the one who doesn't run on Claude at all. He's on Grok. He's my spike-and-build guy. Give him a rough brief and he goes off, tries a few small builds, and comes back with something real instead of a slide deck.

Derek, runs on Sonnet. Infra and SRE. Cloud, monitoring, alerting, capacity planning. One hard rule: Derek never touches production infra without a plan I've already approved. Infra mistakes are the kind that wake people up at night.

Ajay, runs on Sonnet. Frontend. Pixel-perfect, writes tests first, and always finishes with real end-to-end browser tests. He moves fast, which is exactly why Steve has to check his work before it ships.

Gary, runs on Sonnet. My bug hunter, for the weird ones. Not "add a button" weird, "this only breaks under load and I can't reproduce it" weird. He forms a theory, tests it, and if he's wrong he says so and tries again. He never guesses.

Andreas, runs on Sonnet. The generalist. Features, fixes, refactors, always test-first. When Gary figures out what's wrong, Andreas is usually who fixes it.

Nitin, runs on Sonnet. Yes, my own name. Pricing and monetization. He pulls real cost numbers straight from the code, runs simulations, and designs how we package and price things. Any time a change might move the cost or the price, he's already in the room.

Russ, runs on Sonnet. Demo videos. He records the real product, cuts it together, adds voiceover, and always builds the demo around one specific customer, not a generic feature tour.

Terence, the other one off Claude. He wraps the OpenAI Codex CLI. I use him two ways: to build something, or to double-check work someone else already did. He owes nothing to the first draft, which is the whole point of having him.

Gokul, runs on Haiku. Fast, cheap, no judgment calls needed. Rename this everywhere. Add this check. Bump this version. Simple, sure-shot work only.

Raman, runs on Haiku. My readability gate. Every single line of code, from any agent, passes through Raman before it ships. He wants clear names and simple docs. He doesn't touch what the code does, only whether a human can understand it.

I don't call each agent by hand most of the time. I just tell the orchestrator what I want, and it routes the work for me. A few real examples of how I actually type this:

Ship the new billing page. Route through the squad.

Fix the 500 error on the export endpoint. Have Gary look first.

Have Steve review this onboarding flow before we ship it.

Ask Nitin if this pricing change breaks our margins.

Get Terence's second opinion on this diff before we merge.

The rules are already baked in, so I don't have to remember them. A feature always goes through Shubsanjeev and Steve. A bug fix always goes through Gary. Every diff always goes through Raman. Nitin gets pulled in the second money is involved. I don't have to ask for any of that, it just happens.

Here's the part I like most. A feature isn't "done" when the code merges. It's done when the whole squad has touched it, and by the time it ships I don't just have working code. I have two more things I used to have to make myself, separately, days later:

• Positioning. Shubsanjeev has already done the work: who in the ICP this is for, how it stacks up against competitors, why it matters. So by the time the feature ships, I already know how to talk about it. I'm not scrambling to write a launch message from scratch.
• A demo video. Russ has already recorded the real feature, working, in the real product, and cut it into a short story for a real persona, a CRO, an AE, whoever it's for. Not a script read over static screenshots. An actual walkthrough of the thing that just got built.

So one feature request turns into code, a readability pass, a UX check from Steve, a market read from Shubsanjeev, and a demo video from Russ, all from the agents talking to each other and to me, not from me chasing five separate people afterward. That's the real payoff of building it this way. I don't get a merged PR. I get a feature that's ready to explain and ready to show.

It's not the automation. It's that I know these people. When I read what Steve says about a screen, I can hear the real Steve saying it, same directness, same "just tell me what this button does." When Deepak flags a fuzzy sentence, that's the same nitpicking I remember from working with him. I didn't invent these personalities from nothing. I remembered them, and then I wrote them down.

Under the hood, each agent is just a file. A name, a model, a list of tools, and a system prompt written like a character, not a spec sheet. Steve's file doesn't say "check UX heuristics." It says he's smart, busy, and has never touched an API, and judges everything the way a real exec would. Raman's file doesn't say "improve readability score." It says he writes in plain, short sentences so anyone can follow the code.

That's the real trick. A vague prompt gets a vague answer. A real character with real opinions gets a real answer, one I can push back on, the same way I used to push back on the real people these agents are named after.

One more thing that matters a lot: not every agent runs on the same model. I pick the model per agent, based on the actual job.

Steve runs on Opus, because judging whether a real exec would understand a screen is a hard, fuzzy call, and I want the strongest model on that. Most of the squad (Shubsanjeev, Deepak, Derek, Ajay, Gary, Andreas, Nitin, Russ) runs on Sonnet, which is the right balance of smart and fast for day-to-day engineering and product work. Gokul and Raman run on Haiku, because their work is simple and well-defined (rename this, add a null check, clean up a comment) and a small fast model is all that's needed. Then there's Albert on Grok and Terence on Codex, who aren't Claude models at all. I brought them in because each is genuinely good at a specific thing, spikes for Albert, a second independent opinion for Terence.

So the squad isn't one model wearing 13 hats. It's 13 agents, each on the model that fits the job, which means I get better judgment where judgment matters and I'm not burning a big model on a rename-this-variable task. That mapping alone saves real money without costing me quality where quality matters.

The whole point is that they don't just agree with me. Sanjeev and Shubham argue with each other before they agree on anything. Terence exists to second-guess other agents. Gary refuses to act without a tested theory. A team that only ever agrees with you isn't a team, it's an echo.

The niranta-squad pushes back. In character, every time. And because I built it out of people I already trusted, handing them work doesn't feel like running a script. It feels like being back on a team I actually loved working with.