Architecture theory becomes clear when you trace a real request through it. Here, we follow an illustrative example step by step: a vague message from a user that must become a clear, structured action. The example is hypothetical, but it demonstrates a pattern that recurs in many multi-agent systems.
The request: a free-form message
Suppose a user sends a message: βThe order I placed last week still hasnβt arrived and nobody is answering.β This message is clear to a human, but to a system, it is free, unstructured text. The systemβs job is to extract the userβs intent, the necessary details, and the correct action from this single sentence.
Step 1: the foreground layer understands the intent
The first component to meet the message is a conversation specialist in the foreground layer. Its job is to process natural language and guide the interaction: it determines that this is a complaint about a delayed order. If a detail is missing β like the order number β it asks the user for it. This layer avoids deep domain logic; it simply clarifies intent and gathers context.
Step 2: handing off to the domain service
Once the intent is clear, the conversation specialist passes the work to a specialised domain service in the background layer. This handoff is not direct. It follows an event-driven pattern: an event is published signalling that a delay complaint is ready, carrying only an identifier. The domain service receives this event and reads the full state from shared memory β never from the event payload itself.
Step 3: the heavy cognitive work
Now the domain service executes the core work: transforming the message into a clear structure. It determines the issue type (delivery delay), infers the priority, and selects the right action β for example, creating a follow-up ticket populated with the required fields. This is where depth of expertise is necessary, and precisely why it is kept separate from the conversation layer.
Step 4: the monitor makes the next decision
When the domain service finishes, it publishes a completion event. The completion monitor receives it, reads the state from memory, and decides deterministically: is there more work to route, or is it time to reply to the user? In this example, the ticket is created and no further tasks remain, so the monitor instructs the conversation layer to prepare the reply.
Step 5: back to the user
Finally, the conversation specialist closes the loop. It provides the user with a clear, human reply: βYour complaint is logged, the reference number is such-and-such, and it will be handled by such a time.β The user experiences a simple conversation, but behind the scenes, their vague message passed through several specialised layers to become a structured action.
What this trace tells us
This path reveals three architectural principles. First, separation of layers: conversation in the foreground, heavy cognitive work in the background. Second, the event as a trigger: components connect through identifiers rather than heavy data payloads, and truth is always read from memory. Third, deterministic decision-making at the key routing points, so coordination does not become fragile. These principles are the difference between a system that resolves a vague message with confidence and one that stalls at the first unexpected case.