Your multi-agent system works. But do you understand how your agents communicate?

Today, I witnessed an interesting discussion at my workplace.

Our company founder and a friend from Deloitte were evaluating candidates for an engineering role. The initial screening involved qualifications and resumes, with Hermes being used in the process. Shortlisted candidates were then given a practical assignment:

The requirements included proper error handling, guardrails, constraints, and other elements expected in a reliable agentic system.

But what caught my attention wasn't the assignment itself. It was the way candidates were being evaluated.

As I listened to the discussion, I started thinking about something that I believe is frequently overlooked in agentic AI engineering.

Not just whether they can call tools. Not just whether they have skills. Not just whether they have guardrails.

But what kind of orchestration architecture are they using? How do they delegate tasks? How do they exchange information? What happens when two agents disagree? How does the system recover when an agent fails?

A lot of people focus on building agents. Far fewer focus on engineering the coordination layer that makes multiple agents work together effectively. And that's where the real complexity begins.

The current agentic AI ecosystem offers an enormous number of tools and frameworks. Agent frameworks, tool-calling systems, skills and reusable capabilities, MCP servers, guardrails, memory systems, agent harnesses, observability platforms, evaluation frameworks, model routing systems.

All of these can be valuable. But assembling these components does not automatically result in a well-engineered multi-agent system.

Imagine you build three agents: a research agent, a coding agent, and a verification agent. You connect them together and give each of them a set of tools. The system appears to work. But here are the questions that matter.

These are not merely implementation details. They are fundamental architectural decisions.

When designing a multi-agent system, one of the first questions should be: how are the agents going to communicate and coordinate?

There isn't a single universal answer. Different tasks require different coordination patterns. Here are the five fundamental approaches, each with a diagram of the mechanism, what it buys you, and what it costs you.

This is where architectural thinking becomes important. Delegation, peer to peer communication, creator and verifier workflows, negotiation, and broadcast describe different aspects of coordination. They are not necessarily competing architectural choices.

A single multi-agent system can combine several of them:

1. A supervisor delegates tasks to specialist agents.
2. Two research agents communicate directly to resolve a missing dependency.
3. Multiple research agents work in parallel.
4. A creator agent generates a solution.
5. A verifier agent validates the solution.
6. A monitoring component broadcasts an event when a task fails.

This is a hybrid multi-agent architecture. The right question is not "which communication pattern is the best?"

Communication patterns explain how agents interact. Orchestration topology explains how the overall workflow is structured. These two concepts are related, but they are not the same.

Switch between the four below. The nodes stay the same, only the shape changes.

Suppose a candidate submits a multi-agent system for a two-day engineering assignment. It has a planner, a researcher, a coding agent, a verifier, a tool layer, guardrails, and error handling. At first glance it might look impressive. But I would want to understand the architecture behind it.

These questions help distinguish someone who has assembled a demo from someone who understands agentic systems engineering.

For a two-day multi-agent engineering challenge, the quality of the final demo should not be the only consideration. The architecture, reliability, and engineering decisions should also be examined. Open any row for what to listen for.

This framework evaluates whether the candidate understands the system as an engineered product rather than simply a collection of framework components.

Modern agentic systems often emphasize tools, skills, harnesses, and guardrails. All of these are important. But they answer different questions.

You can have a sophisticated tool ecosystem and still build a poorly coordinated multi-agent system. You can have excellent guardrails and still have an inefficient orchestration design. You can have multiple powerful LLMs and still end up with a system that cannot recover from a simple failure.

Imagine we are building an agentic software development platform. The user submits:

We have five agents: planner, researcher, coder, verifier, security reviewer. Instead of simply connecting them, we define an architecture. Step through it.

What communication methods are being used here?

This one system combines several patterns:

• Delegation. The orchestrator assigns work to specialized agents.
• Sequential execution. Planning precedes implementation, and implementation precedes verification.
• Creator and verifier. The coding agent produces an artifact that the verifier evaluates.
• Iterative refinement. Failed checks send the workflow back to the coding agent.
• Potential parallelism. Independent research or security analysis may run concurrently when dependencies permit.
• Structured communication. Agents exchange task specifications, artifacts, and verification reports.
• Guardrails. Tools and permissions restrict what agents can do.

This is the difference between simply having five agents and designing a multi-agent system with explicit coordination logic.

A system does not need to use every communication pattern to be well engineered.

A sequential pipeline with clear state schemas, robust error handling, deterministic routing, strict tool permissions, comprehensive testing, and strong observability may be better engineered than a complex peer to peer system with dozens of agents and poorly defined responsibilities.

Similarly, a single agent with well-designed tools and a reliable control loop may outperform a multi-agent system when the task does not require multiple specialized roles.

Architectural complexity should be justified by task complexity. A candidate who uses a single agent with a well-designed workflow should not automatically be considered weaker than someone who deploys ten agents. The real question is whether the candidate can explain their decisions and demonstrate that the system meets its requirements.

If a candidate builds a multi-agent orchestration system, the interviewer should not focus exclusively on the final output. Start here:

Then follow up:

• Which agents communicate directly?
• Which messages are structured?
• Where is the shared state stored?
• What happens when the verifier rejects the creator's output?
• How do you prevent infinite loops?
• What is your retry policy?
• What is the system's termination condition?
• How do you measure whether your architecture is actually improving quality?

Agentic engineering is not just about giving agents tools, skills, and guardrails. It is about designing the coordination layer. That means understanding how agents communicate, how tasks are delegated, how workflows are structured, how agents synchronize, how outputs are verified, how conflicts are resolved, how failures are handled, how state is shared, how decisions are evaluated, and how the system terminates safely.

Without a deliberate orchestration architecture, a multi-agent system can become little more than a collection of LLM calls connected by ad hoc logic. And that may be enough for a prototype. But building reliable agentic systems requires a deeper level of engineering.

That's the difference between building agents and engineering agentic systems.

One final distinction

Agent communication is not the same as agent intelligence. An agent may communicate through a sophisticated protocol and still produce poor results. Likewise, a highly capable model may perform well in a simple sequential workflow.

Architecture must be evaluated alongside task success, reliability, cost, latency, observability, quality of decisions, and safety and operational constraints.