When you chat with an LLM, you’re talking with an agent, an instance of the LLM that begins a new thread of conversation with you. For many use cases that’s just what we need, but what can we do with agents beyond just chatting? I’ve been working with Claude Code a lot and want to walk you through a few concepts that might help when working with Claude, and no doubt other code-generating LLMs.

Despite best efforts with context files and the like, I wanted to get the code closer to production quality. An aspect that’s missing from a conversation that generates code is the peer review you might get with colleagues. Working with Claude Code in my terminal, I found that opening a new tab, and therefore a new context window, enabled me to ask the code to be reviewed from the perspective of a Tech Lead. That experiment gave great results and leads us to a couple of different instances where this can be useful: orchestration and personas.

Personas

At this point, Anthropic hadn’t released their /agents ability (which I’ll go into later), so building on this experiment, I latched on to the method of context files and created a directory of personas. These are markdown files where I described the role the LLM should assume, along with any notable traits.

What started as describing the Tech Lead role, the things this role should look for, and the kinds of responses that would be helpful, quickly evolved into a virtual team, defining personas for a number of different roles.

This worked really well in having focused conversations about something like technical architecture to front-end standards or UX concerns and QA/Testing. Each was clear on the scope of the conversation and what outcomes they should aim for.

And yes,these are tools, albeit very, very clever language models…but I got curious and added a little more to these personas, giving them a place they were from and that they could lean into using regional dialect/slang,etc. So this meant my QA Lead person was from Liverpool, the UX Lead was from the valleys in Wales and so on. It was funny seeing not only the responses with a stereotypical regional accent, but in italics adding movement cues.

The more surprising part of these personas wasn’t just the character in the response but some of the other properties it assumed. The UX Lead that was from the valleys in Wales relayed things in a very community minded way and used ‘his Mam’ as a benchmark of whether something was usable. These things weren’t mentioned in the persona file.

Realising that each of these personas running in a different terminal tab were sandboxed, I thought, as they were a team, why not give them a way to communicate? Again, using a simple markdown format, I created a directory structure that worked like channels in Slack as well as inboxes for each persona. I know none of it is “real”, but seeing them write messages to each other was funny…but also proved to be a valuable method of collating knowledge in a reusable way for longer-term reference. When a piece of work was complete, I’d ask the persona to leave a message in a channel or to a specific inbox to detail what had been done and what should happen next. While superficially this could be seen as a dumb gimmick, it actually became a useful history for the project.

Agents managing agents

After finding this persona method fun and rewarding through my own experimentation, Anthropic announced sub-agents. These are run but your initial Claude Code instance but have their own context window, so not distracted by the conversation you’ve had so far. The main difference is notable if I walk through a code review. In a persona method, it’s a whole Claude Code instance so the conversation can go on as long as you like after asking for the review. With a sub-agent, the prompt for the view is generated by Claude and passed to the named sub-agent. This agent then conducts the review and passes the result back to the original Claude Code instance to relay to you. In this way it’s like the developer you’re working with (the original Claude Code instance) has gone off to the Tech Lead’s desk, they’ve done the review then it’s come back to your desk to tell you what was said. You don’t directly work with the sub-agent. In this way, we’re experiencing Agent Orchestration; the main agent managing other agents on your behalf. The difference being that in the persona scenario, you’ve gone to see the tech lead, looked through the code together, talked about and concerns and maybe planned out a couple of tasks off the back of it

With the addition of sub-agents, they’ve provided the ability for you to define what tools and skills each agent has, so you’re clear on role and responsibilities and what each has access to. It’s powerful stuff as they can be run in parallel - so a review could potentially use multiple agents each with different concerns.

Hybrid working

With the sub-agent functionality now in place we’ve got two options: either lean on sub-agents to do the work, or through personas, talk with them to discuss a niche and have those richer, focused conversations. One method gives you detailed feedback for a one-off task, the other gives the chance for discussion and debate. So I’ve found myself using both methods from the same source files - as a sub-agent, they don’t need to consider communication style, whereas as with a persona (aside from the regional accent stuff) you might want a certain quality of response to engage with.