Ask three engineers what multi-agent means and you’ll get three answers. One says it’s a prompt with several roles. Another says it’s separate services calling each other. A third points at a vendor diagram.

DNotifier builds infrastructure for agent workflows, so getting this definition right matters here. Muddy terms lead to muddy designs. Teams pay for complexity they don’t need. Or they skip a design that would’ve worked.

This post gives a plain definition, two common patterns, and the trade-offs. None of it is new in 2026. The sources are dated 2025 and 2026, and they still hold.

The Short Answer

A multi-agent system is two or more agents working toward one goal. Each has its own instructions, tools, and context window. A lead agent or your own code coordinates them.

A context window is the text a model can read at one time. Anthropic’s June 2025 engineering post on its research system calls an agent a model that uses tools in a loop. A multi-agent system is several of those loops, working together.

One Prompt, Many Roles

Asking one model to play researcher, reviewer, and writer is still one agent. One context window. One tool set. One loop. Role prompts can help. They just don’t isolate anything.

Real separation looks different. In Anthropic’s post, each subagent gets its own tools, prompts, and context window. It then sends a short result back to the lead.

Picture a researcher who reads forty pages of notes. The writer never needs those pages. That’s the point of splitting.

Two Patterns You’ll See

Most designs follow one of two patterns. In the manager pattern, one agent keeps control and calls the others as tools. In a handoff, one agent passes control to a peer, and the peer takes over the conversation. The OpenAI Agents SDK documentation describes both.

The manager pattern suits work with one clear owner. Anthropic’s research system works this way. A lead agent plans, then runs subagents in parallel. Anthropic reports that parallel runs cut research time by up to 90% on complex queries.

Handoffs suit routing. A triage agent sends a refund question to a refund agent, and that agent owns the rest of the chat. The catch? Control spreads out, so tracing a decision gets harder.

DNotifier’s advice for any agent multi agent setup is simple. Pick the pattern first. Tools come second.

When Multi-Agent Pays Off

It pays off when work splits into independent parts, outgrows one context window, or needs many tools. It pays less when each step leans on the one before.

Anthropic measured a lead agent with subagents beating a single agent by 90.2%. That was its own internal research test. Read it as a vendor result for research work, not a promise.

The same post shows the other side of the ledger. Multi-agent systems used roughly 15 times more tokens than chats. Anthropic also says most coding tasks have fewer parallel pieces than research does.

A Made-Up Workflow

Here’s a hypothetical: a vendor risk review. Keep four layers apart.

Orchestration decides which agent runs next. Messaging carries updates between system parts and users. Model execution is the provider running each call. Application state is your records, decisions, and permissions.

An intake agent pulls out the vendor name and scope. A research agent searches your policy documents. A reviewer agent checks findings against policy. A writer drafts the summary. A person approves it in your app.

Where DNotifier Fits

DNotifier covers the orchestration, search, messaging, and visibility layers here. It offers one SDK and one API with multi-model support. It doesn’t replace your database, your approval rules, or your model providers.

Orchestration comes first. You define named agents, register them in a workflow, and write an entry function that calls them with run_agent. The DNotifier Python SDK page describes sequential pipelines. The Dart SDK docs mention shared workflow state. In the example, the entry function runs intake, research, review, and writing in order.

Search is next. The knowledge-base APIs let you add documents and run semantic search over them. The research agent uses that. Each agent reaches a model through send_ai, and the DNotifier docs list provider and model selection.

Messaging runs over WebSocket. Push progress to the reviewer’s screen as each step ends.

Then there’s visibility. The workflow observability option shows execution and step telemetry in the dashboard. The logs option tracks model sessions, token usage included, per the Dart docs. You see which agent did what, and what it cost.

Your app still owns business rules, approvals, records, and output checks. Providers own model quality, rate limits, and pricing. The published DNotifier documentation doesn’t describe durable replay, checkpoints, or automatic retries, so build recovery in your own code. The Python SDK is also listed as beta, version 1.0.3, released September 14, 2026.

Trade-Offs and Mistakes

The big trade-offs are cost, coordination, and debugging. Every extra agent adds model calls. Every handoff is one more place for information to slip.

Here are the mistakes DNotifier would steer you away from:

• Splitting too early. Start with one agent. Add another only when a role needs its own context or tools.
• Vague delegation. Anthropic found that short instructions caused duplicated work. Give each agent an objective, an output format, tools, and limits.
• Grading steps. Agents take different valid paths on each run. Judge the outcome, then check that the process looks reasonable.
• No tracing. Anthropic added full production tracing to learn why agents failed.
• Treating messages as memory. Keep your source of truth in your own store.

FAQs

Is a multi-agent system just several prompts?
No. Several prompts to one model share one context. Real agents keep separate instructions, tools, and context.

How many agents do I need?
Use the fewest that give each role a distinct job. Anthropic’s scaling rules call for one agent on simple fact-finding. Direct comparisons get two to four subagents.

Do agents need to talk to each other directly?
Not always. In the manager pattern, every message goes through the manager. In a handoff, control moves to a peer.

One Last Thought

Multi-agent describes a division of labor, not a label. If roles need separate context, separate tools, or parallel work, the design earns its cost. If they don’t, one agent is simpler. To explore the workflow side, visit dnotifier.com.