PrerequisiteAI 301 Modules 1 to 3 recommended; AI 202 recommended
0 / 6 completed
Sync my progressJoin a session to keep progress across devices and share it with your instructor
Learning objectives
Explain why agents need structured messages rather than free-form chat
Distinguish directed messages from broadcast messages and set communication boundaries
Describe the eight conceptual message types: task request, task result, status update, evidence, question, error, escalation and handoff
Write a message contract with sender, receiver, type, task, context, constraints, evidence, expected response, status and version
Explain acknowledgement, error and escalation messages and when each is used
Design an Agent Communication Contract between two agents
Problem and need
8 min
Lots of chat, poor collaboration
In Module 3 you designed how work is handed over. The handoff still has to travel as a message. The core question of this module is: what should agents exchange, and how do we avoid a situation with a lot of chat but poor collaboration?
Work scenario (simulated)
Two agents help a department office plan a workshop. The Scheduling agent writes: "Looks like Thursday could work?" The Venue agent answers: "Maybe, depends." Twelve messages later neither has stated which room, which date range or who decides. A person reading the log cannot tell whether anything was agreed, and cannot find the point where the misunderstanding started.
Free-form messages hide what is being asked and what is expected back
Long exchanges are not the same as progress
Without a shared format, a reviewer cannot audit what agents told each other
A message contract makes each message do one clear job
Warning
More messages do not mean better collaboration. A person should be able to read the messages between agents and tell who asked what, what evidence was given and what was decided.
Key takeaway: Good collaboration comes from clear messages with a defined purpose, not from more messages.
Core concepts
9 min
Messages, structure and communication boundaries
A message is one unit of information sent from one agent to another. Agent-to-Agent communication works best when messages are structured, meaning they have known fields, rather than paragraphs of open text.
Free-form message
"Can you check this and let me know?"
Purpose, context and expected reply are implied
Hard to review and easy to misread
Structured message
Has named fields for type, task, context and expected response
The receiver knows exactly what to do
A reviewer can follow the exchange
Directed message or broadcast (simulated)
Style
What it is
When it fits
Risk
Directed message
Sent to one named receiver
A specific task or question for one agent
The sender must choose the right receiver
Broadcast
Sent to many agents at once
A notice everyone needs, such as a change in the shared goal
Noise, and unclear who should act
Communication boundaries say who may message whom, about what, and with what information. An agent should not pass on information the receiver has no need to see, and it should not accept instructions from a sender that is not allowed to give them.
Check yourself
An agent needs one specific answer from one specialist agent. Which style fits best?
Key takeaway: Prefer structured, directed messages, use broadcast sparingly, and set boundaries on who may message whom.
10 min
Conceptual message types
Most agent-to-agent traffic can be described with a small set of message types. The names below are conceptual labels for design. They are not a standard or a wire format.
Late registration is allowed until Friday; see attached paragraph
STATUS_UPDATE
Report progress without finishing
Policy check started; waiting for the latest rule document
EVIDENCE
Provide support for a claim or result
The rule paragraph the answer is based on
QUESTION
Ask for missing information
Which event does this question refer to?
ERROR
Report that something failed or could not be done
Cannot read the rule document; access denied
ESCALATION
Send an issue to a person or higher authority
The rule is unclear and the exception needs a decision
HANDOFF
Pass a task and its ownership to another agent
Intake passes the task to Policy with the full handoff contract
A typical exchange
TASK_REQUEST: the sender asks for a specific task
Acknowledgement: the receiver confirms it has understood and accepted
STATUS_UPDATE or QUESTION: the receiver reports progress or asks for what is missing
EVIDENCE + TASK_RESULT: the receiver returns the result with support
ERROR or ESCALATION: used instead when the task cannot be done or needs a person
Text equivalent: an exchange begins with a request and an acknowledgement. During the work the receiver may send status updates or questions. It ends with a result and its evidence. If the task cannot be done, an error or an escalation takes the place of the result.
Check yourself
A receiver cannot open the source document it was asked to check. Which message type should it send?
Key takeaway: Eight conceptual types cover most exchanges: request, result, status, evidence, question, error, escalation and handoff.
10 min
The message contract
A message contract is an agreement about what fields a message carries and what each one means, so any receiver can act on it and any reviewer can audit it. It is a design agreement between agents, and it is not a technical protocol.
Message contract fields
Field
What it holds
Example (simulated)
Sender
Who is sending
Intake agent
Receiver
Who should act
Policy agent
Message Type
One of the conceptual types
TASK_REQUEST
Task / Goal
What is being asked and why
Confirm whether late registration is allowed for Event X
Context
What the receiver needs to know
Deadline was last Friday; student asks for a one-day extension
Constraints
What the receiver must not do
Do not contact the student; do not promise an exception
Evidence
What supports the message
Link to the event rules section
Expected Response
What reply is expected and in what form
TASK_RESULT with a yes or no and the policy paragraph
Status
Where the task stands
Open
Timestamp / Version
When, and which version, if applicable
Version 1 of the request
Info
Timestamp and version matter only when they help: for example, when a message replaces an earlier one, or when a reviewer must know which information was current. Do not add fields that no one uses.
Check yourself
Why does a message contract include an Expected Response field?
Key takeaway: A message contract names sender, receiver, type, task, context, constraints, evidence, expected response, status and version where needed.
Boundaries and pitfalls
8 min
Pitfalls and what stays out of scope
Contracts prevent several common communication problems. They also have a clear scope in this course.
Communication pitfalls and defenses (simulated)
Pitfall
What happens
Defense
Vague request
The receiver guesses what is wanted
Fill Task / Goal and Expected Response
Missing acknowledgement
The sender does not know the request arrived
Require the receiver to confirm acceptance
Silent failure
The receiver fails and says nothing
Send an ERROR message and then escalate if needed
Unsupported claim
A result has nothing behind it
Require Evidence with results
Oversharing
A message includes information the receiver does not need
Limit Context to what the task requires
Chatter loops
Agents keep replying without progress
Define when the exchange ends and when to escalate
Info
Scope: this module teaches conceptual design of what agents say to each other. It does not teach a protocol implementation, message formats or how messages are transported. Reliable long-running message handling and recovery belong to another course (AI 302).
Warning
Messages between agents can carry sensitive information. Share only what the receiver needs, and keep a person able to review the exchange.
Check yourself
A team is asked to design the exact byte format used to send messages between agents. What is the right response for this course?
Key takeaway: Contracts prevent vague requests, silent failures and unsupported claims. Keep the design conceptual and limit what is shared.
Practice and apply
10 min
Practice: Design an Agent Communication Contract
Activity 4 asks you to create a communication contract between two agents. First read 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). Intake agent and Policy agent
Confirm whether a late registration is allowed for a named event
Context shared
Event name, deadline, the student's question (no personal identity)
Constraints
Do not contact the student; do not promise an exception
Evidence required
The policy paragraph used
Expected Response
TASK_RESULT with yes, no or unclear, plus evidence
End of exchange / escalation
Ends with the result. If unclear or an error persists, ESCALATION to a person
1Pick two agents Choose two agents from your use case that need to exchange information.
2Choose the message types List which of the eight conceptual types they will use, and who sends each.
3Fill the contract fields Write the sender, receiver, task, context, constraints, evidence, expected response and status, and add version only if it helps.
4Set the boundaries State what must not be shared, when the exchange ends, and when to send an ERROR or ESCALATION.
Info
Deliverable: the Agent Communication Contract, showing the two agents, the message types they use, the contract fields, communication boundaries and the end and escalation conditions. It becomes part of your Multi-Agent Architecture Canvas.
Which item belongs in the Constraints field of a message?
Key takeaway: Human-AI-Human: a person defines what agents may say and share, agents exchange clear structured messages, and a person can review the exchange and stays responsible.
