What defines an agent's role in a multi-agent system beyond its persona prompt?
answer
- a role is more than a prompt
- three parts, one of them enforced
- soft prose versus hard enforcement
- allowlist plus stop condition plus return shape
basics
~20 sA role is three things: a persona stating the job, a tool allowlist bounding what the agent can actually do, and behavioural constraints covering when it stops and what it returns. The allowlist does most of the real work.
solid answer
~50 sI treat a role as persona plus tool allowlist plus behavioural constraints. The **persona** says what the job is and what done looks like. The **tool allowlist** says which capabilities the agent may invoke and at what scope — which repository, which directories, whether it has network access. The **behavioural constraints** are the stop condition and the return contract: what shape of result the caller will actually parse. The allowlist is the part that changes outcomes most, because it is enforced outside the model. Prose telling an agent "do not modify files" is a soft constraint that degrades with long context or an injected tool result; an agent that was never handed a write tool simply cannot write. A narrower action space also reduces wrong-tool selection. So when I design a crew, I spend more time on tool scoping and return contracts than on backstory prose.
code
yaml · 14 linesrole: exploitability-verifier
persona: >
Decide whether a reported vulnerability is reachable in this codebase.
Prefer "unknown" over an unsupported claim.
tools:
- repo.read
- sandbox.run
constraints:
max_tool_calls: 20
network: denied
file_writes: denied
returns:
verdict: [exploitable, not_exploitable, unknown]
evidence: { file: string, line: integer, note: string }go deeper
Be able to say a role is more than a prompt: name the tools it may call, what it returns, and when it stops. Do not describe roles purely as different personalities.
Explain the three components and why the allowlist is the enforced one. Show how scoping tools reduces wrong-tool selection, and give a concrete crew where the tool split is the actual design.
Demonstrate least-privilege role design on a real pipeline: which role may execute, which may write, which touches the network, and what each returns. Expect to justify every tool on every allowlist.
Own the governance angle — how role definitions are reviewed, versioned and reused across teams, and how effective authority is bounded when agents act on a user's behalf so a role cannot accumulate permissions nobody audits.
## The three parts of a role A role in a multi-agent system is not a paragraph of character description. In practice it decomposes into three separable things. 1. **Persona** — a short statement of what job this agent has, what it optimises for, and what "finished" looks like. This is the part people write first and over-invest in. 2. **Tool allowlist** — the exact set of capabilities the agent may invoke, and the scope each is bounded to: which repository or directory, whether it may write, whether it has network egress, whether it may spawn other agents. 3. **Behavioural constraints** — the operating envelope. When must it stop? How many tool calls or how much wall time may it burn? What must it never do? And, critically in a multi-agent setting, what exactly does it return to whoever called it? Frameworks encode these differently. CrewAI asks you to fill `role`, `goal` and `backstory` fields plus a list of tools; other stacks put the same information into a system prompt plus a tool registry, or into a named mode. The vocabulary varies across products; the decomposition does not, which is why it is worth thinking in these three parts rather than in one product's field names. ## Why the allowlist carries the weight Persona text is a *soft* constraint. It is instruction inside the context window, and it competes with everything else in that window: a long transcript, a large tool result, and possibly an injected instruction hidden inside content the agent fetched. Compliance with prose instructions degrades as context grows and as adversarial text arrives. The tool allowlist is a *hard* constraint, enforced by the harness outside the model. A remediation-writer role told in prose "do not run the scanner" may still call it on a bad step; a remediation writer that was never given the scanner cannot call it at all, no matter what the model decides. Two consequences follow. The first is security: an agent's effective authority is the intersection of what the calling user is permitted to do and what the role is permitted to do, and only the allowlist expresses the second half. The second is plain reliability: tool-selection accuracy falls as the number of available tools grows, so a role holding four relevant tools picks correctly more often than the same model holding forty. ## The return contract is part of the role The third component is the least glamorous and the most load-bearing. In a single-agent system, sloppy output is a formatting annoyance. In a multi-agent system, one role's output is another role's input, so the return shape is an interface. A useful role definition states it explicitly: *return a verdict of exploitable / not-exploitable / unknown, plus the file and line that justify it, in under 300 words; if you cannot decide, return unknown rather than guessing.* Stop conditions belong here too. A verifier role that keeps investigating because nothing told it when enough evidence is enough will burn its budget and return a sprawl the caller cannot use. ## A worked example An application-security triage crew makes the anatomy concrete. A **scanner** role gets repository read plus a static-analysis runner, no write access and no network; it returns a list of candidate findings. An **exploitability verifier** gets a sandboxed execution tool and repository read; it may run a candidate proof-of-concept inside the sandbox and returns a verdict per candidate with evidence. A **remediation writer** gets repository read and patch write, but no network and no scanner. Same base model, near-identical system-prompt skeleton. What actually differentiates these three agents is the tool set and the stop condition, not the adjectives in the backstory. Notice that the verifier is the only role permitted to execute code, and the writer is the only role permitted to modify files. That partition is the design. ## What personas are still good for None of this means persona text is useless. It sets vocabulary and priorities — a verifier told to care about reachability rather than severity will weigh evidence differently — and it shapes the register of the output. It is a real but weak lever. The failure mode is treating it as the *only* lever: three pages of character description across five agents that all hold the same tools and read the same context. ## Reviewing a role definition A short checklist works well in design review. Can I name every tool this role can call, and is anything on the list there only "just in case"? What is the exact shape of what it returns, and does the consumer parse that shape? What makes it stop? And the sharpest question: if I deleted the persona prose entirely, would this agent behave differently? If the honest answer is no, the persona was decoration and the real design lives in the other two parts.
- Why is a tool allowlist a stronger constraint than the same rule written into the persona?Because it is enforced outside the model. Prose competes for attention with a growing transcript, large tool results and possibly injected instructions inside fetched content, so compliance decays. The allowlist is applied by the harness: a role never handed a write tool cannot write regardless of what the model decides. Prose expresses intent; the allowlist expresses capability.
- How does a role's return contract differ from ordinary output formatting?In a multi-agent system the output is another agent's input, so it is an interface, not presentation. The contract fixes the verdict vocabulary, the required evidence fields, the length ceiling and what to emit when the agent cannot decide. Callers parse it, so an unspecified return shape shows up as a downstream parsing or reasoning failure, not as untidy prose.
- What is the risk of granting a role a tool it only occasionally needs?Two risks. Selection accuracy falls as the action space grows, so an extra tool makes wrong-tool calls on unrelated steps more likely. And the role's authority widens permanently: since effective permission is the intersection of the caller's rights and the role's capabilities, a rarely-used write or network tool leaves that door open on every run, including runs that process untrusted content.
saying these in an interview costs you the question
- Believing a role is only a system-prompt persona
- Giving every agent the same full tool set
- Assuming prose rules constrain behaviour as reliably as permissions
- Leaving the return shape unspecified between agents
- Adding tools "just in case" a role might need them