Giving an AI assistant a role is not a new idea. Prompts such as “You are an experienced editor” or “Act as a financial analyst” are now standard practice. Though, when introducing several AI assistants into real work, the more important challenge is:
How do we design an AI team that performs work normally distributed across people in an organization?
Once several assistants collaborate, the problem is no longer just prompt design. It becomes a question of organizational design: responsibilities, handovers, authority, quality control, and human oversight.
A collection of agents is not yet a team
A typical multi-agent setup might contain a research agent, a writing agent, a review agent, and a publishing agent. Technically, that may be enough to run a workflow.
Organizationally, important questions may still be unanswered:
- Which agent is responsible for the quality of the research?
- Who decides whether a source is credible enough?
- What exactly is handed from research to writing?
- Can the writer introduce claims that were not present in the research?
- Who identifies uncertainty or conflicting evidence?
- Which decisions remain with a human editor?
- What happens when an agent detects a legal, ethical, or reputational risk?
Without clear answers, agents may pass text to one another, but they do not form a dependable working structure.
Start with organizational roles
The starting point should not be an agent framework, a prompt, or an orchestration diagram. It should be the organizational work that needs to be done. A useful first step is to describe the roles that would exist if people performed the work:
- What is each role responsible for?
- What result does it deliver?
- Which information does it receive?
- Who relies on its output?
- What quality is expected?
- Which decisions may the role make?
- When must it escalate?
Only after these questions are answered should we decide whether a role is realized by a person, traditional software, an AI assistant, or a combination of all three. This separates the organizational model from its technical implementation.
Example: an AI-supported editorial team
Consider a publication workflow. A team may include the following roles:
Solution Analyst
→ delivers solution analysis, insights and identifies open questions
Editorial Assistant
→ produces a draft based on approved editorial direction
Fact Checker
→ verifies claims, distinguishes evidence from assumptions,
and flags uncertainty
Human Editor
→ makes final editorial decisions and approves publicationThese are not merely names assigned to prompts. Each role has a defined purpose, expected work results, interfaces with other roles, and clear limits. This makes the system understandable as a team rather than as a chain of disconnected AI calls.
What a role specification should contain
A Job Role Specification describes an organizational role independently of the technology used to realize it. For an AI-supported team, it should define:
- Purpose — Why does this role exist?
- Responsibility — What result is it accountable for?
- Inputs — Which information may it use?
- Outputs — What does it deliver, in which form, and to whom?
- Quality expectations — What makes the result useful and trustworthy?
- Guiding principles and constraints — Which rules must it follow?
Furthermore recommended:
- Decision boundaries — What may the role decide, recommend, or change – or not?
- Escalation rules — When must it involve another role or a human?
The specification should define the organizational intent of the role. It should not prescribe every individual action (specify intent, not execution!).
Roles and workflows are different
A workflow describes a sequence of steps. A role describes a responsibility. Both are needed, but they answer different questions:
- A workflow might specify that every draft is fact-checked before publication. A role specification clarifies what “fact-checking” means, what counts as evidence, what the Fact Checker must deliver, and when uncertainty must be escalated.
- One role may use multiple workflows. One workflow may involve several roles. Keeping these concepts separate prevents a technical process diagram from becoming the only description of organizational responsibility.
The realization can change without changing the role
The same organizational role can be realized in different ways:
- by a human specialist;
- by a deterministic software system;
- by an AI assistant;
- by a hybrid human–AI collaboration.
For example, a human editor may initially review every research result. Later, a specialized AI reviewer may perform an initial quality assessment, while the human remains responsible for high-risk cases and final approval. The organizational role and process remains stable. The realization evolves as the technology, risk profile, and trust in the system evolve.
Not every role must be automated
This is not an argument for replacing every organizational role with an AI agent: Some tasks are better served by conventional software. Others need close human judgment, authority, or accountability. In regulated, safety-critical, or high-impact contexts, detailed procedures, mandatory checks, and human approvals remain essential. The point is not that AI should take over every role. The point is that the decision to use AI should follow a clear understanding of the work, responsibility, and governance involved.
Model an AI team as part of an organization
When AI assistants collaborate on work that would otherwise be distributed across people, they should be designed as organizational roles with explicit responsibilities, handovers, decision boundaries, quality expectations, and escalation paths.
What is not new here?
The ideas of roles, responsibilities, quality criteria, and coordination are not new. Many teams will recognize parts of this approach from methods they already use.
Those familiar with Domain-Driven Design will recognize the importance of shared business language and clear domain boundaries. This approach applies the same discipline to AI teams: roles should be defined in the language of the organization, with clear responsibilities and handovers across business boundaries.
Those working with capability maps or enterprise architecture will know the distinction between what an organization needs to be able to do and the people or systems that enable it. This approach connects that strategic view to operational work: organizational capabilities are realized through a landscape of roles, each with defined responsibilities and work results.
Those using RACI models already ask who is responsible, accountable, consulted, and informed. A Job Role Specification adds the detail needed for AI-supported work: it defines not only ownership, but also expected outputs, quality requirements, decision boundaries, and escalation paths. This matters because an AI assistant may be able to perform an action without being authorized to make the associated decision.
Those experienced with workflows may expect a process description. These remain essential, but a workflow and a role describe different things. A workflow defines the sequence of work; a role defines the responsibility carried through that work. One workflow can involve several roles, and one role can participate in several workflows. The same counts for AI assistants.
Those working in requirements engineering or goal-oriented analysis will recognize familiar elements: purpose, constraints, success criteria, and quality expectations. Rather than specifying only a software system or feature, the goals and intent is used to make implicit knowledge explicit, and as such, specify an organizational role that might be realized as well by a person as by conventional software, an AI assistant, or a hybrid arrangement.
Those using agent contracts will recognize rules for inputs, outputs, tools, and handovers. A Job Role Specification does not replace these technical contracts. It provides their organizational meaning: why an agent exists, what responsibility it holds in the wider work system, which other roles depend on it, and how its contribution is assessed.
What is new here?
What is new, then, is the use of organizational role design as the starting point for modeling AI teams. Instead of beginning with a set of agents, prompts, and orchestration flows, the approach begins with work already distributed across an organization: its responsibilities, handovers, decision rights, quality controls, and escalation paths. Only then does it ask which parts of that team should be realized by people, conventional software, AI assistants, or hybrid collaboration.
