PrerequisiteAI 301 Module 1 recommended; AI 202 and AI 201 Tool and Permission concepts recommended
0 / 6 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor
Learning objectives
Explain Role, Responsibility, Capability, Authority, Scope and Ownership, and how they differ
Describe the duplicated-responsibility failure and its effects
Complete an Agent Role Card with all ten fields, from Role Name to Escalation Boundary
Define a Permission boundary, an Input contract and an Output contract for a role
Recognize Role overlap and gaps, and apply Domain specialization and Separation of duties
Design 3 to 5 candidate roles for your own use case and produce Agent Role Cards using simulated data
Problem and need
8 min
When every agent does the same thing
In Module 1 you decided that a task deserves more than one agent. Now the harder part begins: dividing the work. Splitting a task into agents is not enough; each agent must know what it is for and what it is not for. The core question is: how do several agents divide the work so that they do not all do the same thing?
Work scenario (simulated)
Three agents are each told: "Help prepare the grant application." All three read the funder rules. Two of them build a budget, and the two budgets do not match. The third rewrites the narrative that one of the others had just finished. Nobody checked the deadline, because each agent assumed another one would. When the final version is needed, nobody knows whose version it is.
Duplicated work: the same job is done two or three times
Conflicting outputs: two agents produce different answers and nobody owns the decision
Gaps: a job that everyone assumes belongs to someone else is not done
Unclear accountability: when something goes wrong, no one can say who was responsible
Warning
Agents do not resolve vague roles by talking to each other. They usually resolve them by each doing a little of everything. Clear roles are a design decision made by a person before any agent runs.
Key takeaway: A team of agents works only when each agent has a clear job. Vague roles produce duplicated work, conflicts and gaps.
Core concepts
9 min
Role, Responsibility, Capability, Authority and Scope
Six words describe how work is divided. People often mix them up, and the mix-ups cause most role design problems, so keep each one separate.
Six terms, illustrated with a simulated grant application team
Term
The question it answers
Example
Role
What is this agent in the team?
Compliance Reviewer
Responsibility
What must this agent make sure gets done?
Check the application against every funder rule and report each gap
Capability
What is this agent able to do?
Read the rules, compare text to rules, produce a checklist
Authority
What is this agent allowed to decide or change?
It may mark an item as non-compliant; it may not edit the application or approve it
Scope
Which tasks, data and cases belong to this role, and which do not?
Only the funder rules and the current application; not budget calculation
Ownership
Who is accountable for a given result?
The Compliance Reviewer owns the compliance report; a named person owns the final submission
Capability: what it can do
Set by tools, knowledge and instructions
A technical fact about the agent
Can be wider than what is appropriate
Authority: what it may do
Set by a person, as a design decision
A rule about what is permitted
Should be no wider than the role needs
Info
An agent may be able to do something it should not be allowed to do. Capability is not permission. Role design decides authority, and it should be narrower than capability wherever a mistake would be costly.
Check yourself
An agent has an email tool, so it could send messages to suppliers, but the team decides it must never send anything without a person. What is that decision?
Key takeaway: Role names the job, Responsibility names the outcome, Capability is what the agent can do, Authority is what it may do, Scope is where the role starts and ends.
10 min
The Agent Role Card
To make a role concrete, write it down on one card. The Agent Role Card has ten fields that run from what the role is, to what it uses, to when it must stop and hand back to a person.
The ten fields of an Agent Role Card
Role Name: a short name for the job
Purpose: why this role exists
Responsibilities: what it must make sure gets done
Capabilities: what it can do
Knowledge: what it needs to know
Tools: what it may use
Permissions: what it is allowed to read, change or send
Inputs: what it receives, and from whom
Outputs: what it returns, and to whom
Escalation Boundary: when it must stop and hand the decision to a person
Text equivalent: the card is read from top to bottom. It starts with the name and purpose of the role, then lists its responsibilities, capabilities, knowledge and tools. It then states permissions, inputs and outputs. It ends with the escalation boundary, which is the point where the agent stops and hands the decision to a person.
Example card (simulated): Compliance Reviewer
Field
Content
Role Name
Compliance Reviewer
Purpose
Make sure the application meets the funder rules before a person reviews it
Responsibilities
Check every rule; list each gap with the rule it breaks
Capabilities
Read rules and text; compare them; produce a checklist
Knowledge
The funder rules and the application template
Tools
Document reader only
Permissions
Read the rules and the draft; no editing, no sending
Inputs
The draft application and the rules document, from the Coordinator
Outputs
A compliance checklist with sources, returned to the Coordinator
Escalation Boundary
If a rule is unclear or two rules conflict, stop and ask a person
Check yourself
Which field of the Agent Role Card says when the agent must stop and hand a decision to a person?
Key takeaway: One card per role, with ten fields, from Role Name to Escalation Boundary. If a field is hard to fill, the role is not clear yet.
9 min
Permission boundaries and contracts
A role is only useful if its edges are clear. Three ideas define the edges: the Permission boundary decides what the role may touch, and the Input contract and Output contract decide what goes in and out.
Boundaries and contracts (simulated examples)
Idea
Meaning
Example
Permission boundary
The limit of what the role may read, change or send
The Budget Drafter may read the cost table but cannot submit anything
Input contract
What the role needs to receive, in what form, before it starts
A confirmed list of costs and the funder budget rules; if missing, the role asks and does not guess
Output contract
What the role must return, in what form, with what evidence
A budget table with a source for every line, plus a list of assumptions
Escalation Boundary
The situations the role must hand back to a person
A cost that exceeds the limit; two rules that conflict
Give each role the smallest permissions that let it do its job
A role that has no input contract will guess, and a guess looks like a fact to the next agent
An output without evidence cannot be checked by the next role or by a person
If a role can do something only in emergencies, that is an escalation, not a permission
Info
Tool and permission technology is covered in AI 201, and the exact message formats between agents come later in this course. Here, the goal is only to decide what each role may touch and what it must receive and return.
Check yourself
The Budget Drafter agent returns a table of numbers with no sources or assumptions. Which part of its role design is missing?
Key takeaway: Define what each role may touch, what it must receive and what it must return, plus when it must stop and hand back to a person.
Overlap and separation
9 min
Role overlap, gaps and separation of duties
Once you have candidate roles, test them against each other. Two problems show up most: Role overlap, where two roles claim the same work, and gaps, where nobody owns it.
Role overlap
Two roles both draft or both decide the same thing
Results conflict and nobody owns the final one
Fix: give the responsibility to exactly one role, and let the other consume its output
Gap
A necessary job appears in no role
Each agent assumes another is doing it
Fix: add the job to one role, or add a role, and name its owner
Three ways to divide the work (simulated examples)
Split by
What it means
Example
Domain specialization
Different subject knowledge
Compliance rules, budget arithmetic and narrative writing are three domains
Stage of the work
Different points in the flow
Gather requirements, draft, review
Risk and authority
Different levels of permission or impact
The role that may send anything outside the team is separate from the roles that only draft
Separation of duties: the role that produces a result is not the role that approves it
One responsibility, one owner: a shared responsibility is often an unowned responsibility
Prefer fewer, clearer roles over many thin ones; every role adds coordination cost
Check every important outcome: which role owns it, and which role or person checks it?
Check yourself
Two agents both produce a final budget, and the versions differ. What is the problem and the best fix?
Key takeaway: Test roles against each other: one responsibility, one owner, no gaps, and the producer is not also the approver.
Practice and apply
10 min
Practice: Design the Agent Team
Activity 2 asks you to design 3 to 5 candidate roles for a complex use case. Use the worked example to practice, then do the same for your own use case from Module 1. Please do not enter real company secrets, client personal data or any unauthorized sensitive information in this exercise.
Worked example (simulated): a grant application team of four roles
Role
Responsibility
Permissions
Escalation Boundary
Coordinator
Owns the plan; sends tasks to the other roles and collects their outputs
Read and write the working folder; send nothing outside the team
Any conflict between outputs; anything to be sent outside
Compliance Reviewer
Checks the draft against every funder rule
Read only
An unclear or conflicting rule
Budget Drafter
Builds the budget from confirmed costs, with a source for every line
Read the cost table; write the budget draft only
A cost over the limit; a missing cost
Narrative Drafter
Writes the project narrative from the approved facts
Read the facts; write the narrative draft only
A claim that has no source
1List the responsibilities For your use case, write every job that must be done. Group them into 3 to 5 candidate roles, using domain, stage or risk.
2Fill an Agent Role Card for each role Complete all ten fields, from Role Name to Escalation Boundary. Keep permissions as small as the job allows.
3Test for overlap and gaps Check that each responsibility has exactly one owner and that no needed job is missing. Make sure the producer of a result is not also its approver.
4Mark where a person is needed Note which outputs a person must review, and which decisions belong to a person and not to any agent.
Info
Deliverable: Agent Role Cards, one for each candidate role, each with all ten fields. They become part of your Multi-Agent Architecture Canvas.
Which statement best describes a good set of Agent Role Cards?
Key takeaway: Human-AI-Human: a person designs the roles and boundaries, the agents carry out their roles, and a person reviews the outputs and stays responsible for the result.
