I Built a Virtual AI Team That Actually Works Like a Real One.
Most people use AI assistants the same way they use a search engine — one question, one answer, repeat. What if you could use AI the way you use a team?
That's the idea behind AI personas, and after building and working with a virtual six-person team inside Claude Code, I want to share what I found.
The Trap I Didn't Know I Was In
Like most engineers, when AI assistance arrived I did what engineers do: I made it deterministic. I wrote instruction files — skills — that told the AI exactly what to do. Which tool to use. Which flags to pass. Which command to run for which purpose.
The structure changed. The thinking didn't.
I was writing markdown instead of code files. Building skill libraries instead of code libraries. And calling it AI-assisted development. In reality, I had replaced code with markdown that described code — and I was starting to see all the same problems code had, just harder to debug.
Skill rot. Skills have a shelf life. Directory structures change. SDKs get deprecated. Conventions shift. The AI would follow the skill faithfully and produce broken results — not because it was wrong, but because the instructions it was given had quietly stopped being true. There was no mechanism to know when a skill aged out. It just happened.
Scope bleed. Skills I'd written for one project's conventions would show up and constrain work on an entirely different project. Azure DevOps and GitHub overlap. Code and CI/CD overlap. A skill written for one context would bleed into another where it didn't belong — or actively worked against me.
Context dilution. Research from Stanford, Google, Anthropic, and Meta has documented this: LLMs degrade predictably as context grows. Attention is zero-sum. Every stale or irrelevant token competes with what actually matters. I wasn't just dealing with outdated skills — I was poisoning my own context window with them.
Session chaos. Parallel work meant multiple sessions open simultaneously, all unlabeled, all looking the same. Which session had the DevOps context loaded? Which one was mid-way through a QA task? The more I parallelized, the more mental energy went into tracking what was where instead of doing the actual work.
Framework opacity. Pre-built frameworks helped — until they didn't. Stack a few together and you get multiple memory subsystems running in parallel, session hooks firing at unexpected times, documentation written in formats you didn't choose. The more I added, the more the system did things I hadn't asked for and couldn't trace back to a cause. I'd traded one set of problems for a different, murkier one.
And the deepest problem of all: I was taking the AI out of AI. LLMs are reasoning engines trained on an enormous breadth of knowledge — Microsoft, Oracle, every major vendor. That training is the value. When you over-specify, you bypass it. You're not leveraging what the model knows; you're overriding it with what you know, which is narrower, more brittle, and goes stale faster. I was turning a reasoning system into a lookup table.
The Shift: People, Not Configs
The solution I landed on wasn't a better skill system. It was a different mental model entirely.
I built a team.
Not an agent swarm. Not an orchestration framework. A small group of personas — each one a defined role, a defined scope, a defined way of seeing the work. Brad, my developer. Sam, my DBA. Jay, my project manager. Claire, my librarian who held the reference information everything else depended on. Destiny, my skills administrator. A QA persona whose only job was verification.
The first thing I noticed: I could look at a row of open windows and instantly know what each one was doing. Not because of a label I'd written — because I knew who was in it. People carry implicit domain knowledge in a way that labels don't. A window titled "Session 4" tells you nothing. A window associated with Brad tells you it's development work, it has engineering context loaded, and it's not the place to ask about project tracking.
Switching between tasks stopped being an act of reconstruction. It became recognition.
Destiny: The Part That Changed Everything
Of all the outcomes, this one had the most day-to-day impact.
Destiny was a persona with one job: maintain the team. Keep the skills current. Track what changed and when. Manage the backlog of things worth improving.
What made her work wasn't just the defined role. It was that the team structure gave her the context to do that role without being hand-held. Every persona had a known location, a known domain, a known set of skills. Destiny didn't need to be told where to look. The roster told her.
When a bad flag kept showing up on SQL commands, I'd describe the problem to Destiny and she'd go to Sam's folder, find the relevant skill, identify where the flag was defined, and fix it. Without me navigating the directory structure. Without me remembering the file name. Without me context-switching out of whatever I was actually working on.
When something broke, I could ask: "Brad was working great before we did this. Where do you think it went wrong?" She'd trace the timeline, identify what had changed, and suggest exactly where to look. Not a guess — an informed diagnosis from someone who'd been keeping track.
When I hit a problem mid-task that wasn't urgent enough to stop for, I'd surface it to Destiny and get back to work. She'd hold it, think about it in relation to everything else she knew, and when I was ready: "What's been accumulating?" The backlog existed — I just didn't have to manage it.
I was no longer a file path custodian or a markdown janitor. The system had someone for that.
The Idea That Ties It Together
A persona is a frame, not a script.
Scripts specify tools, flags, commands — they replace reasoning with execution. Frames define what a role sees and cares about — they invite reasoning from training.
When you over-specify, you bypass the model's knowledge with your own. Your knowledge is narrower, more brittle, and goes stale. The model's doesn't.
Frames are durable — they survive tool changes and path changes because they were never tied to those specifics. Frames compose cleanly — when two personas interact, they meet at conceptual edges, not conflicting instructions. Frames scale with the model — as the underlying model improves, a frame-based persona gets better automatically. A script stays exactly as capable as the day it was written.
The team mental model works because it stops trying to control the AI and starts trying to give it something worth reasoning about.
A Few Things This Is Not
This approach is personal — it encodes how you work. The moment it gets packaged and shared, it becomes another marketplace skill with a 10% gap. It's not meant to be a repository asset or a company-wide plugin. It uses those things. It doesn't become one.
It's not autonomous. The human scopes, tests, experiments, refactors, and evolves the team. The team amplifies human judgment. It doesn't replace it.
It's not a replacement for skills or agents. It sits on top of them — organizing them, improving them, giving them a home. Scripts still have tremendous value for deterministic, repeatable work. The team handles the reasoning layer. The two aren't in competition.
And it's not novel. Role-based AI patterns are well-established — Paperclip, CrewAI, LangGraph, AutoGen all explore similar territory in different ways. What this is, is a personal, lightweight, human-centered expression of a known pattern. The fact that others have arrived at similar conclusions independently is evidence that the pattern is sound.
The Two Questions
The engineer's instinct asks: "How can I write a skill to make something great happen?"
The team mental model asks: "How can I make something great happen?"
One leads to a better script. The other leads somewhere the script could never go.
There's No Magic Here — Just Text Files
Before going further, I want to be direct about something: personas are not a special AI feature. There's no secret sauce. A persona is just a markdown file that gets loaded into context before you start working.
Three files. That's it:
- A persona file that defines role, tone, and behavior
- A skills file that tells the assistant what it can do
- A context file that carries background and goals
That's the whole picture. The reason this works so well isn't because the AI is doing something clever. It's because we're organizing information the same way we already organize people — by role, by responsibility, by domain. We've been doing that in organizations our entire lives. We already know how to think that way.
Meet the Team
For this demonstration, I built a six-person virtual IT team:
- Nichole — Administrative Assistant. Todo lists, scheduling, reminders, intake. The front door for anything organizational.
- Brad — Senior Software Engineer. Architecture, infrastructure, code, security. The technical backbone.
- Sam — Data Engineer. Databases, queries, schema design, reporting. If it involves data, Sam owns it.
- Destiny — Skills Administrator. This one is unique to an AI team. Destiny is responsible for the continuous improvement of the AI tooling itself — skills, personas, commands. She keeps the team sharp.
- Clair — Records Manager. The single source of truth. Documentation, business knowledge, project history, anything that needs to be remembered across sessions.
- Jay — Project Manager. Backlogs, sprint planning, work items, prioritization. Jay keeps everything moving.
Six people. Six clear lanes.
This Isn't Just for Software Teams
Everything I've described applies equally to marketing, sales, HR, operations, or any domain where you coordinate work across roles.
A project manager could have a persona that knows your inventory, can draft marketing copy for new products, and coordinates with the rest of your team to get things ready for launch. The roles you define are entirely up to you. You know your domain better than any template does.
The Takeaway
Personas work because they map to something we already understand: the structure of a team. By organizing your AI context around roles and responsibilities, you get something more focused, more predictable, and more natural to interact with.
You're not memorizing commands. You're not managing a process. You're delegating to people you know — people whose strengths, limitations, and working styles you've defined yourself.
The files are just text. The difference is how you organize them.
This article also includes a full video walkthrough:
