Custom Multi-Agent Framework vs MightyBot

Common multi-agent topologies

Four shapes cover most custom builds. They differ in who decides what happens next: the agents at runtime, or code written before it.

Supervisor and hierarchy. One agent routes work to the others. In LangChain's multi-agent docs, "a main agent coordinates subagents as tools. All routing passes through the main agent, which decides when and how to invoke each subagent" (LangChain docs, multi-agent). CrewAI's hierarchical process organizes tasks "in a managerial hierarchy, where tasks are delegated and executed based on a structured chain of command," and requires a manager model or a custom manager agent (CrewAI docs, processes). For vendor-level comparisons see MightyBot vs LangChain and LangGraph and MightyBot vs CrewAI.

Handoffs. Control passes from agent to agent. In the OpenAI Agents SDK, "handoffs are represented as tools to the LLM," so a handoff to a refund agent appears as a tool named transfer_to_refund_agent (OpenAI Agents SDK docs, handoffs). LangChain describes the same pattern: "agents transfer control to each other via tool calls" (LangChain docs, multi-agent). The vendor agent SDK handoffs page covers what hosting that loop takes.

Group chat. Agents share a conversation and take turns, a pattern AutoGen popularized. As of October 24, 2026, the AutoGen README on GitHub says the project is "archived and no longer maintained" and that "new users should start with Microsoft Agent Framework" (microsoft/autogen README). See MightyBot vs Semantic Kernel and MightyBot vs AutoGen.

Code-defined graphs. The same frameworks also let code fix the order. LangChain's custom workflow pattern builds "bespoke execution flows with LangGraph, mixing deterministic logic and agentic behavior" (LangChain docs, multi-agent). Microsoft Agent Framework, "the direct successor" to Semantic Kernel and AutoGen, offers "functional and graph-based workflows that connect agents and functions through explicit execution paths" and recommends a workflow when "you need explicit control over execution order" (Microsoft Learn, Agent Framework overview). In this shape the dependency graph is yours to design, test and keep aligned with the policy as it changes. The 2026 enterprise AI agent market map places these stacks against the platform category.

What breaks between agents

The published evidence points at the seams.

Failure modes. The MAST study built a taxonomy of multi-agent failures from annotated traces and found "14 unique modes, clustered into 3 categories: (i) system design issues, (ii) inter-agent misalignment, and (iii) task verification." Its dataset holds "1600+ annotated traces collected across 7 popular MAS frameworks" (Cemri et al., arXiv 2503.13657). Two of the three categories are about how the agents are wired together.

Lost context. Cognition's engineering team, after building its own agents, set two principles: "Share context, and share full agent traces, not just individual messages" and "Actions carry implicit decisions, and conflicting decisions carry bad results" (Cognition, Don't Build Multi-Agents). In a credit memo, an agent that summarized the rent roll made a decision about what mattered. The agent that writes the debt service coverage section never sees why.

Tokens and reruns. Anthropic, describing its own multi-agent research system, reports that "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats." The same post notes that agents "are non-deterministic between runs, even with identical prompts," which "makes debugging harder" (Anthropic, How we built our multi-agent research system). Those are figures for one research system, not a rule for every build.

Fit. Anthropic also names the poor fit for its kind of system: "some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today" (same post). A loan package review has many of those dependencies. Independent document extractions can fan out in parallel, but the extraction feeds the reconciliation, the reconciliation feeds the policy check, and all of it runs under one policy version. Whether agents route at runtime or code fixes the graph, someone designs the dependency graph and the context contract for each step, validates them and operates them. In a custom build that someone is your team.

What your team builds for a lending workflow

A crew of agents is the visible part. The build is the rest:

• The dependency graph: which steps are independent and can fan out, which must wait, and which decisions are made by code before runtime and which by an agent during it.
• Orchestration and shared state, so the supervisor, the handoff chain or the graph runtime knows where the case is and what has been decided.
• Context contracts. Which documents, extractions and prior findings each agent receives, in what form, and what it must return.
• Tracing across agents, so a failure in step six can be traced to a decision in step two.
• Evaluations for each role and for the whole system, rerun on every model and framework upgrade.
• Guardrails per agent and per tool, including what an agent may write to a system of record.
• Per-run cost caps, because the token bill scales with agents, handoffs and retries.
• Review queues for the cases the agents cannot settle.
• One audit record per decision that an examiner can read, assembled from many agent traces.

The build vs buy hub lists the eight production layers in detail. A multi-agent framework supplies part of the execution layer, including graph runtimes where you choose them. The calculator gives this architecture its highest token and retry assumptions of the five presets (the ROI calculator's planning assumptions).

How MightyBot coordinates specialized agents

MightyBot runs specialized agents as well. The difference is where the dependency graph, the scheduling and each agent's context come from: the compiled policy, rather than orchestration code your team writes and maintains. A team can build the same planned coordination on LangGraph or Agent Framework workflows; the work is designing, validating and operating the graph and the context contracts, and keeping them aligned with the policy as it changes. MightyBot supplies that as a platform.

Your team describes the work in plain English. The Agent Compiler builds the schemas, the workflow and the execution plan at design time, and that plan fixes which agents run, in what order, on what inputs. Independent analyses run in parallel; dependent ones wait for the step they need (how MightyBot plans specialized agents). The platform's own description is four agents, one compiled plan, with a Gatekeeper that validates before the Builder processes, a Verification Agent that checks the Builder's output, and a Reconciliation Agent that resolves conflicts, all following the dependency graph (compiled agent execution).

Shared context is a property of the plan rather than a message an agent remembers to forward. Each step receives the documents, extractions and findings it depends on. Deterministic checks run outside the model, so a threshold test gives the same verdict on the same extracted values; whether a full rerun agrees also depends on the extraction steps, which is why end-to-end agreement is listed as unpublished. When the Gatekeeper cannot classify a document it routes to a person; when the Reconciliation Agent finds a discrepancy it escalates with both values, both sources and the relevant threshold (compiled agent execution).

Every decision carries one why-trail linking the verdict to the policy version, the page-level evidence and the sign-off, with compliance exports to your warehouse (compliance). Policy changes are edits to a versioned plain-English policy, and Policy Profiles let one workflow carry rules for several jurisdictions or products (Policy Engine). The whitepaper describes three execution patterns, a compiled plan, stepwise execution and planned sequences, so a bounded step-by-step case runs without an open-ended loop.

The planning assumption is about 60 days to production (calculator assumption: 2 months, editable), against 15 months for the build preset (build vs buy hub; production results).

Benchmark status

MightyBot is running a first-party benchmark across the five build types on this hub, including a custom multi-agent arm. No results are published yet, and nothing on this page states or implies an outcome. Until the method and results are published, the calculator's preset values for this architecture are labeled planning assumptions.