Architecture theory becomes clear when you trace a real request through it. In this piece, we follow an illustrative example step by step: a vague message from a user that has to become a clear, structured action. The example is hypothetical and generic, but it shows 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βs free, unstructured text. The systemβs job is to pull out, from this sentence, the userβs intent, the necessary details, and the right action.
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 understand natural language and guide the conversation: it works out that this is a complaint about a delayed order, and if some detail is missing β like the order number β it asks for it. This layer doesnβt go deep into the domain logic; it only clarifies the intent and gathers enough context.
Step 2: handing off to the domain service
Once the intent is clear, the conversation specialist hands the work to a specialised domain service in the background layer. This handoff isnβt direct; it follows the same event-driven pattern: an event is published saying βa delay complaint is ready,β carrying only an identifier. The domain service hears this event and reads the full state from shared memory β not from the event itself.
Step 3: the heavy cognitive work
Now the domain service does the main work: turning the message into a clear structure. It determines the type of issue (delivery delay), infers the priority, and chooses the right action β for example, creating a follow-up ticket with all the needed fields. This is exactly where depth of expertise is required, and exactly why itβs kept separate from the conversation layer.
Step 4: the monitor makes the next decision
When the domain service finishes, it publishes a βdoneβ event. The completion monitor hears it, reads the state from memory, and decides deterministically: is there more work, or is it time to reply to the user? In this example, the ticket is created and nothing else remains, so the monitor tells the conversation layer to prepare the reply.
Step 5: back to the user
Finally, the conversation specialist closes the loop: it gives the user 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 saw a simple conversation, but behind the scenes, their vague message passed through several specialised layers and became 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, not heavy data, and the truth is always read from memory. Third, deterministic decision-making at the key points, so coordination doesnβt become fragile. These few principles are the difference between a system that carries a vague message through with confidence and one that gets stuck at the first unexpected case.