Skip to content
NTPU AI Learn

AI 301 · Module 3

Task Allocation, Delegation & Handoff

Which agent should own the next task, and how can work be handed over safely?

Start Section 1
  • Duration55 min
  • LevelArchitect
  • PrerequisiteAI 301 Modules 1 and 2 recommended; AI 202 recommended
0 / 6 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor

Info

After you join, your completed lesson numbers are sent to your instructor together with your learner code, so they can see your progress. Use the codes your instructor gave you, and do not enter your name, company secrets or other personal data. Progress is kept with the rest of that session's data.

Learning objectives

  • Distinguish static assignment from dynamic assignment and match tasks to agent capabilities
  • Describe the delegation model: identify capability, select agent, send task with context and constraints, return result with evidence and status
  • Write a handoff contract with the eight required parts
  • Explain ownership transfer, return path, completion criteria and escalation
  • Recognize common failure modes such as incomplete handoff, context loss, circular delegation and unauthorized delegation
  • Decide for each task whether to keep, delegate, parallelize or escalate to a human, and produce a Delegation & Handoff Map

Problem and need

8 min

Roles are defined, but who does the next task?

In Module 2 you gave each agent a role, capabilities and a responsibility boundary. A role card does not yet say which agent should take a particular task at a particular moment, or how the work moves from one agent to another. The core question of this module is: which agent should own the next task, and how can work be handed over safely?

Work scenario (simulated)

A department office uses three agents to handle event registration questions: an Intake agent, a Policy agent and a Drafting agent. A question arrives about a late registration. Intake forwards it to Policy with the single line "please check". Policy does not know which event, which deadline or what output is wanted, so it asks Drafting for help. Drafting sends it back to Intake. Two days later nobody has answered, and each agent believes another one owns the task.

  • Having capable agents does not decide who should do a task
  • Work handed over without context has to be rediscovered by the receiver
  • Without a clear owner, everyone assumes someone else is handling it
  • Delegation is a design decision, not something to leave to chance

Warning

Handing over a task does not hand over responsibility for the outcome. A person stays accountable for what the team produces, and delegation should never hide who decided what.

Key takeaway: Roles say who could do work. Allocation, delegation and handoff say who does it now, and how it moves.

Core concepts

9 min

Task allocation: static, dynamic and capability matching

Task allocation is the decision about which agent takes which task. There are two basic styles, and both depend on matching the task to the capability an agent actually has.

Static assignment

  • The task type is fixed to an agent in advance, for example all policy questions go to the Policy agent
  • Predictable and easy to review
  • Can be a poor fit when a task does not match the usual pattern

Dynamic assignment

  • The agent is chosen at the time, based on the task and the current situation
  • Flexible for varied work
  • Needs clear rules for choosing, or the choice becomes arbitrary
What to check before allocating a task (simulated)
ConsiderationQuestionExample
Capability matchingDoes this agent have the capability the task needs?A Drafting agent can write text but cannot confirm policy
PriorityHow urgent is it compared with other tasks?A deadline closes tomorrow, so it goes first
DependenciesWhat must be finished before this can start?Policy check must finish before the reply is drafted
BoundaryIs the task inside the agent's responsibility boundary?Sending an official notice is outside the Drafting agent's boundary

Info

Capability is not the same as permission. An agent that could do a task should still not take it if it lies outside its responsibility boundary from Module 2.
Check yourself

A task is well suited to the Drafting agent's writing skill, but sending it would be an official notice outside that agent's boundary. What should the allocation do?

A task is well suited to the Drafting agent's writing skill, but sending it would be an official notice outside that agent's boundary. What should the allocation do?

Key takeaway: Match tasks to capability, priority, dependencies and boundaries, whether the assignment is static or dynamic.

9 min

The delegation model

Delegation is one agent asking another to do part of a task. A safe delegation follows the same path each time, and it ends with a result that comes back with evidence.

The delegation model
  1. Task: the piece of work to be done
  2. Identify Required Capability: what ability does it need?
  3. Select Agent: choose the agent with that capability inside its boundary
  4. Send Task + Context + Constraints: give what the receiver needs
  5. Execute: the receiver does the work
  6. Return Result + Evidence + Status: report back what was done and how it is known

Text equivalent: the model runs in one direction and then returns. A task is broken down to the capability it needs, an agent is selected, and the task is sent together with context and constraints. The receiver executes, and returns the result together with evidence and a status, so the sender can check it rather than trust it.

Ideas that support a delegation
IdeaWhat it meansExample (simulated)
Completion criteriaHow the receiver and the sender agree the task is doneA draft reply that cites the policy paragraph and stays under 150 words
Return pathWhere the result goes when finishedBack to the Intake agent, not to a different agent
StatusWhere the task stands nowDone, partly done, blocked, or needs a person
EvidenceWhat supports the resultThe policy paragraph the answer relies on
Check yourself

Why does the delegation model end with Result + Evidence + Status rather than only a result?

Why does the delegation model end with Result + Evidence + Status rather than only a result?

Key takeaway: Delegate with task, context and constraints, and expect back the result, evidence and status through a defined return path.

9 min

The handoff contract and ownership transfer

A handoff is the moment work passes from one agent to another. Delegation usually keeps the sender responsible for the whole task. A handoff can also transfer ownership, meaning the receiver now owns the task. Either way, the handoff should carry a written contract so nothing depends on what the sender happens to remember.

Each handoff should contain
PartWhat it holdsExample (simulated)
taskWhat must be doneAnswer a late-registration question
objectiveWhy it matters and what good looks likeGive the student a clear, correct next step
required contextWhat the receiver must knowEvent name, deadline, the student's question
constraintsWhat the receiver must not doDo not promise an exception; do not contact the student
expected outputThe form of the resultA draft reply of up to 150 words
evidence requirementsWhat must support the resultCite the policy paragraph used
completion statusWhere the task standsOpen, in progress, done or blocked
unresolved issuesWhat is still unknown or openUnclear whether the event allows late registration

Weak handoff

  • One line: "please check"
  • Receiver has to guess the context
  • Nobody knows who owns the task now

Clear handoff

  • All eight parts are stated
  • Receiver can start without asking back
  • Ownership and return path are explicit
Check yourself

A handoff lists the task, expected output and constraints, but leaves out the required context and unresolved issues. What is the most likely result?

A handoff lists the task, expected output and constraints, but leaves out the required context and unresolved issues. What is the most likely result?

Key takeaway: A handoff contract has eight parts, so the receiver can start work and everyone knows who owns the task.

Failure modes and escalation

9 min

Failure modes and escalation

Delegation fails in predictable ways. Knowing them lets you design the handoff and the rules around it to prevent them.

Common failure modes and simple defenses (simulated)
Failure modeWhat happensDefense
Incomplete handoffKey parts are missing, so the receiver guessesUse the eight-part handoff contract
Context lossFacts known to the sender are not passed onList required context and unresolved issues
Duplicated workTwo agents do the same taskName one owner for each task
Ambiguous ownershipEach agent thinks another owns itState who owns the task after the handoff
Circular delegationA sends to B, B sends back to ADefine the return path and who may delegate onward
Endless bouncingThe task passes around without progressLimit the number of handoffs, then escalate
Unauthorized delegationAn agent hands work to one that is not allowed to do itDefine who may delegate to whom, and what needs approval

Escalation is the planned exit from these situations. When a task is blocked, risky, out of boundary or bouncing, it goes to a person with the context attached, rather than continuing to circulate among agents.

Info

Human-AI-Human: a person should decide what may be delegated, what must be escalated, and stay responsible for the outcome. This module teaches the design of delegation. Infrastructure for running and recovering long workflows belongs to another course (AI 302) and is not covered here.
Check yourself

A task has passed between three agents four times with no progress. Which defense fits best?

A task has passed between three agents four times with no progress. Which defense fits best?

Key takeaway: Design against incomplete handoff, context loss, duplicated work, ambiguous ownership, circular delegation, bouncing and unauthorized delegation, with escalation as the exit.

Practice and apply

11 min

Practice: Delegate or Keep?

Activity 3 is called Delegate or Keep? First work the example, then do it for your own use case. Please do not enter real company secrets, client personal data or any unauthorized sensitive information in this exercise.

Worked example (simulated). Event registration team of three agents
TaskDecisionReason
Read the incoming question and identify the eventKeep within current agent (Intake)Inside its role and needs no other capability
Check the late-registration policyDelegate to Policy agentNeeds a capability Intake does not have
Check the deadline and the draft reply wording at the same timeParallelizeThe two tasks do not depend on each other
Approve an exception to the deadlineEscalate to humanA decision with real impact that is not the agents' to make
  1. List the tasks
    Write the main tasks of your use case, one per line.
  2. Decide for each task
    Choose one: keep within current agent, delegate, parallelize, or escalate to human. Give a reason.
  3. Write one handoff
    For one delegated task, fill in the eight parts of the handoff contract, and state the return path and who owns the task afterward.
  4. Check failure modes
    Mark where circular delegation, context loss or unauthorized delegation could occur, and add a defense or an escalation point.

Info

Deliverable: the Delegation & Handoff Map, a table showing each task, its decision (keep, delegate, parallelize or escalate), the receiver, the handoff contract for delegated tasks, the return path and the escalation points. It becomes part of your Multi-Agent Architecture Canvas.
Check yourself

A task needs a decision that could affect a real person and is not inside any agent's boundary. Which choice fits Delegate or Keep?

A task needs a decision that could affect a real person and is not inside any agent's boundary. Which choice fits Delegate or Keep?

Key takeaway: Human-AI-Human: a person defines what can be delegated and what is escalated, agents carry out clear handoffs, and a person reviews the results and stays responsible.

Save as PDF

What next?