I've been watching how other people structure their Claude Code setups, and gstack got me thinking. Gary Tan's framework assigns Claude agents to named roles — CEO, engineering manager, QA — and the idea is that giving each agent a persona shapes how it reasons. It's a thoughtful approach, and I get the appeal.
But after a few months of running multi-agent setups daily, I landed somewhere different.
The thing that actually changed behavior
When I tried giving agents distinct personas without changing anything else, the outputs looked... roughly the same. A "QA agent" that could still write and commit code thought like a writer. It suggested fixes, restructured things, went down implementation rabbit holes. The persona was decorative.
The change that stuck was making agents genuinely read-only. One reviewer agent: no file edits, no shell commands, no git access. Just read and comment.
That forced a different posture. It couldn't fix what it found, so it had to be precise about what it found. And because it couldn't touch the codebase, it wasn't tempted to paper over a bad decision with a quick patch. It surfaced disagreements that my main agent had glossed over — not because the main agent was careless, but because the agent that can fix things tends to fix things rather than question them.
The read-only reviewer catches a different class of problems. Tool constraints do what persona labels don't.
Why I think personas feel powerful but often aren't
A persona shapes tone. It might affect how a response is framed. But the actual reasoning — what gets checked, what gets skipped, what trade-offs get made — runs on what the agent can do, not what it's called.
If a "senior engineer" agent has the same tool access as a "junior engineer" agent, you've changed the label on the box. The contents are similar.
Tool-scoping is the actual separation of concerns. Read vs. read-write. File access scoped to a module vs. the full repo. Shell access vs. no shell access. These constraints don't just signal a role; they enforce it at the execution layer.
The same logic shows up in work-as-memory
I run something I think of as work-as-memory: frozen spec files where [] items only get marked [●] after something's verified, not just done. The state lives in the work, not in the model's context. The model can't just decide that something is done — it has to have actually done it and left an artifact.
That's the same idea. You're not trusting a persona to behave correctly. You're building the constraint into the structure so the behavior can't deviate.
Today's example
I pushed 33 PRs today using a sibling-leftover approach — one agent builds, a sibling picks up the next task in parallel. That throughput only works when agents have clean, enforced boundaries. If both agents could write to the same files, they'd collide. The scoping isn't a nice-to-have; it's what makes the whole setup not fall apart.
The lesson wasn't "give the first agent a builder persona and the second a reviewer persona." It was: make the reviewer agent literally incapable of writing.
What I'd say to gstack
Personas are useful for communication — they help you think about what a role should prioritize. I still name my agents and think about their intended function. But I treat the name as a comment and the tool permissions as the code.
If you're using personas without changing tool access, you're hoping the model acts differently. When you change tool access, you're guaranteeing it.
That's where I landed differently. Not sure it's the only right answer, but it's the one that made a measurable difference in how my setups actually run.
Top comments (0)