An agentic team for my day-to-day work

I lead a distributed design team across five countries (14 team members). I spend part of my week moving between strategy, content, design systems, team operations, and research. I wanted help connecting those conversations and questioning my decisions.

So I built five agents in Claude Code, each with a different responsibility. I named them after people I admire. Maite, my strategic partner, is named after my mother.

The final judgment stays with me. I review new information before it becomes part of the system's memory, and change the setup as I learn what I need from it.

Where it helps in my day

Thinking through a decision

I work with Maite to stress-test my reasoning: when to say yes or no, and the difficult questions, with the context actually in mind. Making the challenges explicit gave me something to build into how she challenges me.

Preparing a conversation

Julie helps me prepare for conversations with people on my team, drawing on the context specific to them. The same approach doesn't work for everyone. Preparation is part of the system, alongside the work on rituals, onboarding, and collaboration.

Finding the angle before writing

Chimamanda helps me shape public-facing work. Before drafting, she proposes an angle. We discuss it first, so I can decide what I actually want to say before getting caught up in editing sentences that sound polished but don't sound like me.

What has changed

Gathering context used to mean reading meeting notes and trying to remember a decision from weeks earlier. Connecting my meeting notes, product tickets, and research reports has made that faster. I spend minutes on work that used to take me an hour, with a review step before I rely on the information.

That review matters. A meeting summary may describe a discussion as a decision. A research finding may be useful without applying to every product or user. I need to see those distinctions before the information becomes part of the next conversation.

I'm still figuring out how much of this scales beyond my own work. The system serves one person today, and it keeps changing as I do.

Designing the team

The process before the system

Before I wrote a single agent definition, I did something I hadn't done quite this way before: I asked AI to interview me. I shared what I already knew about my own patterns, my tendencies under pressure, and where I get stuck. I asked it to push on the parts I was being vague about instead of accepting my first answer.

The conversations helped me put things I already understood about myself into words. That gave me a more useful starting point than a generic brief for a writing assistant or research helper.

Five charters, one discipline

The names helped me write each brief with a particular point of view. Each agent has a distinct responsibility:

• Maite, named for my mother, is my strategic partner. She challenges my reasoning and helps me connect decisions across the work. She cares about me and pushes to be better (and happier).
• Chimamanda, named for Chimamanda Ngozi Adichie, helps with voice and content, starting with the angle before drafting.
• Ruth, named for Ruth Bader Ginsburg, holds the design system's token architecture and component decisions. Depending on the question, she recommends, maps trade-offs, challenges a pattern, or asks for clarification.
• Julie, named for Julie Zhuo, supports team operations: rituals, onboarding, collaboration, and preparation for conversations.
• Teresa, named for Teresa Torres, focuses on discovery, opportunity trees, and whether we're researching the right thing.

Maite stays in the main thread with me, always. The other four run as separate subagents I invoke on demand. Maite's job needs the full conversation history to see the whole board. An isolated call would hand her a blank page and strip her of exactly that. Ruth, Julie, and Teresa need the opposite: a clean, focused context that isn't cluttered with whatever I was discussing with someone else five minutes earlier. Deciding which parts of a system get memory and which get a fresh start every time became its own design decision, not a technical detail.

The standing rule across all five: the team's job is not to agree with me. It's to think harder than I would alone. Honesty over comfort, every time. And when something needs real alignment (a framework, an article, a system decision), we discuss before we build. Not build, show, and revise endlessly. Align once, then move.

Structuring the second brain

Five points of view immediately created a harder problem: where does everything they know actually live, and how do I stop that pile of information from turning into its own mess?

Each agent has one file that is its territory, not the whole system. Design systems knowledge doesn't leak into team-operations knowledge, and neither agent has to read the other's file to do its job. Every file opens with a small frontmatter block: who owns it, when it last changed, where the update came from. That sounds minor. In practice, it's the single most useful discipline in the whole setup, because I can look at any fact my second brain holds and answer "is this still true, and where did it come from?" in five seconds instead of scrolling back through months of conversation.

Files also outgrow themselves, and when they do, I split them. One file covering everything I track across my product portfolio kept growing until it stopped being fast to navigate. I split the two areas getting the most attention into their own files and left the rest in the shared one. The structure follows how the work is actually distributed, not a taxonomy I designed on day one and never revisited.

None of the agents loads everything by default either. Each one is told which file to open and, more importantly, when not to bother: a simple question gets a direct answer, no file loading, no performing thoroughness it doesn't need. That single rule is what keeps the token cost of the system down. An agent that reads five files before saying good morning isn't a thinking partner. It's a slow, expensive one.

Read the principles I gave the agents

These are the principles behind the setup:

• Clarity is care. Name what's unclear instead of leaving it vague to avoid friction.
• The process serves the person. Question a ritual or rule when it starts getting in the way.
• Learn first, produce after. A session where I understand something deeply is useful even if we produce nothing.
• Honesty over comfort. Challenge my reasoning rather than agree to keep things comfortable.
• Calma, alegría, valentía. My own words for how I want to be in my work. Notice when things feel heavy, leave space to enjoy them, and help me say what takes courage.

Nothing enters memory unreviewed

What I underestimated when I started is that a second brain fed automatically will eventually contradict itself. Meeting notes, research reports, and tickets now flow into this system through a few different tools, and each source is sometimes wrong, sometimes incomplete, or captures a conversation that never actually resolved into a decision.

So nothing goes straight from a source into permanent memory. Everything lands as a draft first. I read it, keep what's accurate, correct or drop what isn't, and only then merge it into the file it belongs to. Not every source earns the same trust once it's in, either: a meeting summary stays marked unconfirmed until I've actually confirmed it, because a transcript isn't the same thing as a decision. A finished piece of research is stronger evidence, but it's still one signal about a specific group of people at a specific time, not a verdict that overrides everything else I know for other reasons.

The system can also be asked to check itself for staleness: comparing what a file says against how long it's actually been since the thing it describes last changed. Written down is not the same as still true.

What I would carry into a team

Shared context needs ownership

None of this is really about having five agents with names. It's about deciding, on purpose, how to structure information before you let AI act on it. The transferable version is smaller than it looks: one owned file per domain of the work, a lightweight way to know who wrote a fact and when, a review step before anything becomes shared truth, and a way to notice when something has gone stale.

That's exactly as useful at product level as it is for a team of one. A product manager and a product designer already know things about a product that live in different heads: strategy in one, user evidence in the other, decisions nobody wrote down anywhere. Giving that shared context the same treatment (one place it lives, one owner per piece, one review step before it counts as fact) isn't a research project. It's a decision about how a team wants to work, worth making on purpose rather than letting whichever tool arrives first decide it by default.

What keeps changing

The tools feeding this system keep evolving. So does the structure around them: which agents share a conversation, what becomes a repeatable skill, and where I need to review the work. I've changed all three as I've used it.

The next version will probably make parts of this one look primitive. That's fine. It's improving, and I'm learning.