Article — Position paper · ○ Open access

A role is not a capability

Why an agentic architecture must separately justify the capability it mobilises, the autonomy it grants and the authority it withholds

Jérôme Vetillard · · Twingital Institute · 12 pages · 11 min read
🇫🇷 Lire en français ↓ Download PDF

Summary

A habit is spreading in agentic system design: splitting the work into personas (a “finance” agent, a “compliance” agent, an “epidemiologist” agent), each embodied by an LLM instance with a role written as a prompt and a voice in a deliberation. The article names this habit persona-based agentification and argues that it conflates three distinct architectural decisions. The first concerns capability: which component, evaluated over which domain of use, actually meets the function’s requirements. The second concerns autonomy: what demonstrated value justifies letting a component choose and revise its own actions. The third concerns authority: which share of the rules, evidence and resources that authorise an external effect remains beyond the reach of the component proposing it.

The thesis condemns neither agents, nor multi-agent systems, nor LLMs. It sets a discipline of justification for agentic systems that act on external resources, data or systems, primarily in healthcare, pharmaceuticals and defence, where evidence has both a cost and a value. The original PDF below contains the full argument and its references.

What you decide when you name an “epidemiologist” agent

The starting point is a situated case: emulating a trial that compares CAR-T therapies with standard of care in aggressive lymphomas. Target trial emulation makes explicit the randomised trial one would have wanted to run, then imitates it with observational data (Hernán and Robins, 2016). Building the causal graph behind the choice of adjustment variables is a matter of scientific judgement: unmeasured confounding, selection mechanisms, the definition of time zero, whose omission is enough to create immortal time bias (Hernán et al., 2016).

Once that graph is explicit and examined, part of the work changes nature. Identifying adjustment sets that satisfy graphical criteria, checking the temporal admissibility of variables and validating data consistency against an ontology are reproducible operations, independent of how the question is phrased. They do not, however, validate the graph, the identifiability of the effect or the relevance of the estimator.

Handing the whole thing to an “epidemiologist” persona merges three objects the example keeps apart: the judgement that frames the problem, the computation that handles its checkable part, and the validation that bears on both. An executable check is not a validated causal inference; making that boundary explicit is the article’s purpose.

Persona-based agentification: working definitions

The argument relies on a stable vocabulary. An agent is a component with an objective, access to tools and a decision loop over its own actions; its autonomy is the extent of the decisions that loop takes without external validation. A role is a behavioural specification assigned by prompt. A capability is an effective aptitude to perform a function, whose properties and limits have been evaluated over a defined domain of use: a role may contribute to it, but is neither its proof nor its guarantee.

Two notions of constraint structure what follows. A constraint is mechanically checkable when a specified mechanism can conclude, from accessible information, that it is satisfied, violated or not assessable, with only the first outcome allowing a positive conclusion. It is open when assessing it requires a judgement that nobody, today, knows how to specify. Finally, an external effect is any action that consumes a resource, discloses data or changes a state outside the reasoning context.

Why teams split by roles, and what the role does well

Persona-based agentification is practised by competent teams, and the article offers four explanatory mechanisms, presented as hypotheses in the absence of frequency data. The organisational mechanism extends Conway’s law (1968): an organisation chart of agents mirrors the company’s own, with its lines of responsibility and budget. The cognitive mechanism makes the role an interface for understanding, useful to explain and maintain the system, but bearing on its representation rather than its properties. The tooling mechanism comes from frameworks that ask for a persona before an interface contract, CrewAI’s role, goal, backstory triptych being the most explicit form. The protocol mechanism comes from A2A: when interoperability is negotiated agent to agent, wrapping a function in an agent becomes the way to make it addressable.

The role has a genuine virtue, which must be granted before it is criticised. In regulated environments, separating whoever produces from whoever approves is a requirement; a role that materialises that boundary has architectural value. The problem starts when the role splits computation without matching any boundary of authority, rights or context. The persona then becomes a governance artefact disguised as a computational artefact: it says who answers for what, and guarantees nothing about what is computed.

The four hidden costs of a persona-based multi-agent architecture

The first cost is one of interpretation. Anthropic reports that a Claude Opus 4 orchestrator with Claude Sonnet 4 sub-agents outperforms a single Opus 4 agent by 90.2% on an internal research evaluation, and that on BrowseComp three factors explain 95% of performance variance, token usage alone explaining 80%. These results show that a multi-agent configuration can gain by mobilising more compute; they establish neither causation nor any specific merit of decomposition into roles.

The second cost is an accounting one, invisible on the inference bill: context rebuilt by each agent, intermediate outputs generated then reread, sequential latency, cross-checks, observability of a deliberation. The relevant measure is the full cost per task correctly completed, rework and validation included, read alongside functional coverage, abstention rate and exposure to prohibited effects. An architecture that correctly refuses will always look more expensive than one that wrongly executes.

The third cost lies in the exchange format. When components pass results to each other as prose, an amount becomes a sentence to reread and an uncertainty becomes an adverb. Typed interface contracts do not guarantee the truth of what flows through them, but they make certain structural violations detectable.

The fourth cost is structural. Cemri et al. (2025) analyse seven multi-agent frameworks and identify fourteen failure modes spread across specification, inter-agent misalignment and verification, while observing that gains over single agents often remain minimal. Two instances of the same model share its biases: their agreement does not prove their correctness. Dependability engineering calls this common-cause failure.

We spent a decade learning not to split a monolith into a hundred chatty services. We are about to do it again with services that bill their chatter by the token.

Allocating each function to the capability that satisfies it

The central proposal reverses the usual order: characterise the function before choosing the component. Allocation runs in three steps. Describe the function (inputs, outputs, variability, degree of rule specification, data reliability, required level of evidence, external effects). Identify every admissible solution, whatever its nature: deterministic function, solver, rules engine, specialised model, LLM, hybrid, generated-then-validated artefact. Then arbitrate, documenting the trade-off, its owner and its review conditions. An undocumented trade-off is not an allocation; it is a habit.

This discipline is not anti-generative dogma. Functional qualification (does generativity contribute a useful capability?) is distinct from arbitration (which admissible solution fits best?). A solver fits when the problem has been posed; an LLM may fit when it has yet to be.

A context-dependent drug contraindication illustrates the most common case, the partially checkable constraint. The documented interaction and the renal-function threshold can be specified; the benefit-risk trade-off for a given patient cannot. If the lab value is outdated, the check must return “not assessable” rather than turn missing data into implicit permission. Handing everything to the LLM leaves the checkable part to a probabilistic component; handing everything to a rules engine pretends the judgement has been specified. The second error is the more common one among those newly converted to determinism.

Two principles complete the allocation. First, one does not prove a component; one proves a property of a component under assumptions, and some properties of an LLM can in fact be guaranteed by its execution envelope (permissions, resource bounds, accepted formats). Second, designing with an LLM does not require executing with one: a generated rule, query or workflow can be validated and then run without generativity, provided that the artefact’s failure does not automatically reopen the door to unqualified generative execution. The doctrine fixes a criterion, not a boundary; the boundary moves with prices, data and models.

Separating a component does not justify making it an agent

Six properties can motivate a split: parallelism, context isolation, separation of rights, verification diversity, regulatory or inter-organisational authority boundaries, and independent exploration of strategies. Each justifies a separation only if the separation actually delivers it at acceptable cost, and none yet justifies an agent: a parallel branch can be a function, a rights boundary a conventional service, an independent check a deterministic test.

Two successive decisions must therefore be argued: why separate, then why give the separated component decision-making autonomy. Separation is justified by the property it delivers; autonomy, by the value it demonstrates against the admissible solutions without it. An agent that separates nothing and whose autonomy contributes nothing is just one more prompt with an identity.

Orchestration concentrates the risk, because the orchestrator often combines proposing the plan, authorising its steps, allocating resources and driving execution. A known process is driven by a workflow or state machine, with the LLM called only where interpretation is needed. A generative orchestrator remains relevant for open-ended tasks, provided it chooses among authorised capabilities without creating rights, task state is externalised outside the model’s context, and stopping conditions are imposed from outside. An agent’s autonomy is measured by what it can decide; its safety, by what it cannot prevent.

An agent must not hold authority over its own effects

This second error exists with or without personas. The typical case is a captive deterministic check: an LLM produces a transfer request with an amount and an approval flag set to true; a rules engine checks the ceiling and the approval, works exactly as specified, and authorises an illegitimate operation. The amount may come from the agent; the approval may not, because it is an assertion by the controlled party accepted as evidence. One must distinguish the action’s parameters, which the agent may produce, authority attributes (identity, rights, approvals), which require independent attestation, business facts, which may require external verification, and policies, which the agent must neither modify nor negotiate. This is complete mediation and separation of privilege in the sense of Saltzer and Schroeder (1975), with an acknowledged limit: independence reduces manipulation, it does not guarantee correctness.

Prompt injection is the contemporary form of the confused deputy described by Hardy (1988): a perfectly typed send call, within the exact scope of its permissions, can exfiltrate a confidential attachment. Authorising a type of action is not authorising its content; for critical effects, authorisation must be bound to a specific object, for instance the hash of the approved document. The risk specific to LLMs is instruction laundering: an instruction carried by data with no authority is rephrased and re-enters the system as a legitimate plan step. A generative output may become an instruction, but only through a distinct, attributable and logged act of authorisation. Authority comes from the act that validates, not from the text that proposes. CaMeL (Debenedetti et al., 2025) offers one instantiation: 77% of AgentDojo tasks solved with what the authors call provable security, against 84% with no defence. The figure holds for their threat model and benchmark; it illustrates the difference in kind between a constraint imposed by architecture and improved model resistance.

Three distinctions complete the picture. Every agent output must carry an explicit status (proposal, information, authorised action). A permitted action is not a funded action: resource allocation belongs to a mechanism independent of the agents. An authorisation is not a transaction: between the order issued and the effect confirmed, the state may remain unknown, and a blind retry is exactly how one pays twice. For open constraints, the right question is not “which verifier?” but “on what basis should one verify?”: external reference first, second judgement next, calibrated abstention last. Human oversight belongs there, targeted and informed, provided humans remain practised in judging.

What the thesis does not claim to prove

The article defends a design criterion, not the overall superiority of architectures that apply it. That second question is experimental: for comparable functions, requirements and resources, what does replacing an LLM persona with a specialised capability bring, and what does autonomy add? Answering it requires fixing the task population, the estimand, the horizon, the primary endpoint, a comparator that includes a single LLM with the same tools, and a definition of equal budget when tokens, compute time, money and energy are not interchangeable.

The limits are explicit. A function’s characterisation evolves, and its allocation with it. Separation eases some proofs but multiplies the interfaces to qualify. Attestation and intent binding carry an engineering and usability cost that may exceed their benefit. The handling of open constraints remains less established than mechanical checks. The explanatory mechanisms for persona-based agentification remain hypotheses.

Three questions to audit an agentic architecture

The criterion applies to any existing architecture. For each component, one must be able to say what capability it provides and over what domain of use that capability was evaluated. For each autonomous decision loop, one must be able to name the demonstrated value that justifies the autonomy. For each external effect, one must be able to establish which share of the rules, evidence, resources and authorisation mechanisms lies beyond the reach of the component proposing it.

An architecture that cannot answer does not merely have too many agents. It has not established what it computes, why it delegates and what it authorises. This requirement will outlive falling inference prices, because it bears not on what models can do, but on what they are allowed to decide.

Frequently asked questions

What is persona-based agentification? It is the practice of assigning each named function (finance, compliance, epidemiology) an LLM instance, a prompt-written role and a conversational interface, before establishing whether that function requires generative processing.

Does the article oppose multi-agent systems? No. Several specialised agents are justified when they bring distinct capabilities, rights or contexts. The article requires that justification to be explicit and that coordination costs and effects be measured.

Why are two instances of the same LLM not an independent verification? Because they share the same foundation model, and therefore its biases and vulnerabilities. Their agreement is homogeneous redundancy, which protects poorly against common-cause failure.

Is a deterministic check enough to secure an agent’s actions? No. A deterministic check is captive if it verifies authority attributes (approval, identity, rights) supplied by the controlled component. Those attributes must be attested by independent sources, and critical authorisations bound to a specific object.

In the Twingital Institute corpus

This article extends The Agent Is Not the Architecture, which treated the agent as an implementation choice rather than a primitive, and Agentic Governance Will Not Come from the Models, which argued for exogenous governance. The question of delegated authority connects with Delegation is not abdication; the explicit status of outputs and assertions with Replay Is No Longer Replay; the “not assessable” outcome and abstention with the taxonomy of agentic refusals. Repositioning the LLM inside a composite architecture is developed in Beyond the LLM-Centric Paradigm; externalised state and compensations rather than blind retries in Event-Driven Architecture as the Essential Complement to Agentic AI; the cybersecurity blind spot of agentic frameworks in AI Never-Ending Story; and the need for humans practised in judgement in Human oversight is not external to the system. The ground of the opening example, CAR-T therapies under time constraints, is covered in When Delay Becomes a Property of the Treatment.

Read the document