How AI Agents Talk to Each Other in Business Workflows

By Lazar Milicevic · Published October 10, 2026 · 11 min read

You've probably built one AI automation that works: it drafts a reply, tags an email, summarizes a call. Now you want the next step, where the output of one automation becomes the input of another without you copy-pasting between them. That's a multi-agent workflow, and the hard part isn't the AI. It's how the pieces pass work, context, and responsibility to each other.

This guide covers the mechanics (handoffs, protocols, shared context), a concrete lead-to-CRM-to-follow-up example you can adapt, the real costs and risks, and a safe way to start.

What "agents talking to each other" actually means

Agents don't chat like people. In practice, one agent produces a structured message (usually JSON), and another agent or tool receives it, does its own job, and returns a result. "Communication" is three things: a task handed over, the context needed to do it, and a result handed back.

There are three mechanisms in real systems, and most confusion comes from mixing them up:

1. In-process handoffs. Both agents live in the same codebase or framework. One transfers control to the other. No network protocol is involved.
2. Agents calling tools. An agent calls a function, an API, or a server that exposes capabilities (CRM lookups, email sending, database queries).
3. Agent-to-agent protocols. Independent agents, possibly built by different teams or vendors, discover each other and exchange tasks over the network.

For a solo operator or small team, in my experience most of your time goes to the first two. The third matters when you need agents from different systems to cooperate. Let's take each in turn.

Pattern 1: Handoffs and orchestrators inside one system

The simplest multi-agent design is a single codebase where one agent routes work to specialists. There are two distinct flavors, and the difference changes what each agent can see.

In the OpenAI Agents SDK, a handoff transfers control to a specialist agent, and the receiving agent sees the conversation history unless you apply an input_filter to change it. That differs from agents as tools, where the original agent keeps the conversation and calls the specialist like a function. (OpenAI Agents SDK: Handoffs)

Here's what that distinction means in practice:

Anthropic describes a different shape for its multi-agent research system: an orchestrator-worker pattern, where a lead agent coordinates and delegates to specialized subagents that run in parallel. (Anthropic: How we built our multi-agent research system) This fits tasks that split into independent pieces, like researching ten prospects at once.

A minimal orchestrator in Python looks like this (pseudocode-level, framework-agnostic):

from dataclasses import dataclass

@dataclass
class Task:
    kind: str          # "enrich" | "score" | "draft_followup"
    payload: dict      # only the fields this worker needs
    correlation_id: str

def orchestrate(lead: dict) -> dict:
    cid = lead["id"]

    # Each worker gets a narrow slice of context, not the whole record
    enriched = run_agent("enricher", Task("enrich", {"company": lead["company"], "email_domain": lead["email"].split("@")[1]}, cid))
    scored   = run_agent("scorer",   Task("score",  {"enriched": enriched, "message": lead["message"]}, cid))

    if scored["score"] < 40:
        return {"action": "archive", "reason": scored["reason"]}

    draft = run_agent("writer", Task("draft_followup", {"name": lead["name"], "need": scored["need"], "tone": "plain"}, cid))
    return {"action": "queue_for_review", "draft": draft}

Notice what the orchestrator does not do: it never passes the full lead record to every worker. Each worker gets the minimum it needs. That single habit prevents most context-related bugs and leaks.

OpenAI's guidance supports keeping workers narrow: give each specialist a narrow job, and split into a new agent only when the next branch truly needs different instructions, tools, or policy. (OpenAI: Orchestration and handoffs) If two "agents" share the same instructions and tools, they're one agent with a longer prompt. Don't add a hop that buys you nothing.

Pattern 2: Agents reaching tools through MCP

Most business automation value comes from agents doing things in your systems, not from agents chatting with each other. That's where the Model Context Protocol (MCP) comes in.

Anthropic open-sourced MCP as an open standard for connecting AI assistants to the systems where data lives, such as content repositories, business tools, and development environments. (Anthropic: Introducing the Model Context Protocol) It was introduced on November 25, 2024, and in December 2025 Anthropic donated it to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI. (Wikipedia: Model Context Protocol)

Technically, MCP uses a host/client/server structure. Client and server communicate with JSON-RPC 2.0 messages, and servers expose tools and resources that the AI host can call. (Wikipedia: Model Context Protocol)

A tool call over MCP is just a JSON-RPC request:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "crm_create_contact",
    "arguments": {
      "email": "jane@acme-example.com",
      "company": "Acme Example",
      "source": "website_form",
      "score": 72
    }
  }
}

Why this matters for a small business: instead of hand-writing a custom integration per agent per tool, you expose the CRM once as an MCP server, and any compatible agent can use it. The security guidance is worth knowing up front. MCP's guidance requires implementations to follow OAuth 2.1 security best practices and forbids token passthrough. (Wikipedia: Model Context Protocol) In plain terms: give each server its own scoped credentials. Don't forward one agent's token to another system.

Pattern 3: Agent-to-agent with A2A

When agents are built by different teams or vendors, in-process handoffs don't work. That's the gap the Agent2Agent (A2A) protocol fills: an open standard for communication and interoperability between independent AI agent systems, which may be built on different frameworks or by different vendors. It was originally contributed by Google and is hosted by the Linux Foundation. (A2A Project on GitHub)

The mechanics, per the A2A repository:

• Discovery happens through "Agent Cards" that describe an agent's capabilities and connection info.
• Transport is JSON-RPC 2.0 over HTTP(S).
• Interaction modes include synchronous request/response, streaming (SSE), and asynchronous push notifications. (A2A on GitHub)
• Agents collaborate without sharing internal memory, proprietary logic, or tool implementations. (A2A on GitHub)

That last point is the real design idea: the remote agent is opaque. You send it a task, it sends back a result. Your agent never sees its prompts or private tools.

Google announced A2A in April 2025 and transferred the protocol, specification, and SDKs to the Linux Foundation in June 2025. (Wikipedia: Agent2Agent)

The A2A documentation frames the two protocols as complementary: MCP connects agents to tools and data, and A2A connects agents to other agents. (A2A Protocol docs) A rule of thumb:

An A2A-style Agent Card is conceptually a small JSON document like this (illustrative shape only; check the A2A spec for the exact schema):

{
  "name": "Invoice Reconciler",
  "description": "Matches incoming payments to open invoices",
  "url": "agents.example.com
  "capabilities": { "streaming": true, "pushNotifications": true },
  "skills": [
    { "id": "match_payment", "description": "Match a payment record to an invoice" }
  ]
}

Most solo operators won't need A2A on day one. Know it exists so you don't build a bespoke agent-to-agent protocol that you'll regret.

A worked example: lead intake → CRM → follow-up

This is an illustration, not a case study or benchmark. It shows how the pieces above compose into a real workflow. Assume a website contact form.

The agents and their narrow jobs:

1. Intake agent. Reads the raw form submission, extracts name, company, need, and urgency. Outputs structured JSON. No tools beyond reading the submission.
2. Enrichment agent. Takes company name and email domain only. Looks up public company info. Never sees the message body.
3. CRM agent. Creates or updates the contact via an MCP-exposed CRM tool. Has write access to contacts, nothing else.
4. Follow-up agent. Drafts a reply using the structured need and tone rules. Has no send permission. It writes to a review queue.
5. Human gate. You (or a team member) approve, edit, or reject drafts in the first weeks.

The message passed between steps (the contract, not the conversation):

lead_event:
  correlation_id: "lead-2026-10-0142"
  stage: "enriched"
  contact:
    name: "Jane Doe"
    email: "jane@acme-example.com"
  company:
    name: "Acme Example"
    size_hint: "11-50"
  need_summary: "Wants to automate invoice reminders"
  urgency: "medium"
  history: []        # intentionally empty: workers don't inherit raw text
  approvals_required: ["send_email"]

Three design choices carry most of the weight here:

• Structured contracts between agents, not free-form text. If the enrichment agent hallucinates a field, a schema validator catches it before the CRM agent writes bad data.
• A correlation ID on everything. When a draft looks wrong, you can trace it back through every hop.
• Approval flags on side effects. Sending an email, creating a deal, and updating a record are different risk levels. Mark which ones need a human.

If you've already got a single-agent version of this, don't split it just to look sophisticated. Split when a step truly needs different tools, permissions, or instructions, which is exactly the OpenAI guidance cited earlier.

Costs and failure modes you should plan for

Multi-agent systems cost more and fail in new ways. Both deserve numbers and specifics before you commit.

Token cost. Anthropic reports that agents use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more. Their conclusion: multi-agent systems only pay off for tasks valuable enough to cover the extra cost. (Anthropic engineering post) Anthropic also found that in its BrowseComp evaluation analysis, token usage alone explained 80% of performance variance, which tells you more agents often means more spend, not automatically better results. (same source)

For your own planning, do the math with round, labeled numbers. As an example only: if one lead through a single-agent flow costs a small amount of tokens, multiply by roughly 15 if you're modeling a naive multi-agent version, then compare against the value of one qualified lead. If the lead is worth a few dollars and the workflow costs more than that, collapse agents. Check your provider's current pricing page for real per-token rates.

Project failure rate. Gartner's June 25, 2025 press release predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. Gartner also estimates only about 130 of the thousands of agentic AI vendors are real, describing the rest as "agent washing": rebranded chatbots, RPA, and AI assistants. (Gartner press release) Translation: be skeptical of vendor claims and define the business outcome before the architecture.

Security risks specific to agents talking to agents. The OWASP Top 10 for Agentic Applications includes risks that map directly onto multi-agent designs: ASI01 (goal hijacking via prompt injection), ASI06 (memory and context poisoning), ASI07 (insecure inter-agent communication), and ASI08 (cascading failures). I've confirmed this list only through secondary sources, so check the official OWASP GenAI Security Project page for exact names and numbering before quoting it in your own docs. For a broader comparison of agent security frameworks, see Security Considerations for Multi-agent Systems on arXiv.

Here's how each one shows up in the lead workflow:

OWASP's guidance for goal hijacking recommends limiting agent tool privileges and requiring human approval for goal-altering or high-impact actions. (Graylog: What is the OWASP Top 10 Agentic AI) That's the single most useful sentence for a small team starting out.

How to start safely: a six-step rollout

You don't need a platform team. You need discipline about scope.

1. Pick one workflow with a clear dollar value. Lead intake, invoice reminders, and support triage are good candidates. Avoid anything where a wrong action is irreversible or embarrassing.
2. Build it as a single agent first. If it works, you have a baseline for quality and cost. Only split when a step needs different tools, permissions, or instructions.
3. Define the message contract before the agents. Write the JSON/YAML schema for what moves between steps. Validate it in code, not in the prompt.
4. Give each agent the minimum. Least-privilege tools, scoped credentials, only the fields it needs. No shared "god" API key.
5. Put a human gate on every side effect. Draft, don't send. Propose, don't create. Loosen this only after weeks of reviewed output that you've sampled for errors.
6. Log every hop. Correlation ID, input, output, tool calls, approvals. When something goes wrong at 2 a.m., you want a trace, not a mystery.

A small logging wrapper pays for itself immediately:

import json, time, logging

def run_agent(name: str, task: Task) -> dict:
    start = time.time()
    result = AGENTS[name](task.payload)   # your agent call
    logging.info(json.dumps({
        "cid": task.correlation_id,
        "agent": name,
        "kind": task.kind,
        "input_keys": list(task.payload.keys()),   # log shape, not secrets
        "output_keys": list(result.keys()),
        "ms": int((time.time() - start) * 1000),
    }))
    return result

Log field names and metadata by default; log full content only where you have a retention and privacy plan.

Where this fits

The pattern above is the one I reach for: narrow agents, structured handoffs between them, scoped access to the tools they touch, and a human approval step on anything that sends, charges, or deletes. You'll find more practical automation write-ups at bizflowai.io. And for many small workflows, a single agent is the better answer.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.