← Back to Insights

Architecting Multi-Agent Orchestration for Enterprise Finance

How we structured a scalable DAG of 15+ specialized agents to automate complex financial audits, reducing processing time by 80% while maintaining compliance.

Nirmal Soni

June 2026 · 22 min read

Financial audits are one of the most document-intensive, time-critical workflows in enterprise operations. A mid-size company running a quarterly close process touches hundreds of ledger entries, reconciles across dozens of sub-systems, and must satisfy a constellation of regulatory requirements — all under deadline. For years, the dominant approach was to throw more human hours at the problem.

We took a different path. Over the past eight months, we designed and deployed a multi-agent orchestration system that handles a complete financial audit cycle end-to-end — from raw ledger ingestion to final compliance attestation — with minimal human intervention. This is the architecture we built, and the lessons we extracted from watching it fail, recover, and ultimately succeed.

"The temptation with multi-agent systems is to build one omniscient agent. We learned, painfully, that specialization is not a design preference — it is a correctness requirement."

Why a DAG, not a pipeline

The first instinct is to build a sequential pipeline: ingest → classify → reconcile → report. It's easy to reason about. It's also completely wrong for financial workloads, where different audit tracks have radically different latency profiles and dependency structures.

Consider a statutory audit that covers both accounts payable and intercompany eliminations. The AP reconciliation depends on invoice-level data, which arrives at different times from different ERP modules. The intercompany elimination depends on AP being settled, but also on FX conversion rates, which are independent. A rigid pipeline either serializes everything — incurring massive wall-clock latency — or collapses into unmaintainable spaghetti.

A Directed Acyclic Graph lets us express the actual dependency structure of the work. Nodes that don't share dependencies run in parallel. Nodes that do share dependencies wait only on what they actually need. The result is a system whose latency approaches the critical path, not the sum of all paths.

The fifteen agents and what they actually do

Specialization was our cardinal principle. Each agent has a bounded context, a narrow tool surface, and a clearly defined output contract. No agent tries to do two things. When an agent fails, we know exactly where in the audit chain the failure occurred and why.

Implementation

The orchestrator is not a god object

One of the most consequential design decisions was what the orchestrator should not know. It is not aware of accounting principles. It cannot read a ledger entry. It has no opinion about whether a 3-way match has failed. Its job is purely topological: given a DAG, execute nodes in dependency order, surface failures, and know when to retry versus escalate.

This distinction matters enormously for reliability. When the AP Reconciler agent fails because a vendor invoice file is malformed, the orchestrator does not attempt to repair it — it raises a BLOCKED status, captures the failure artifact, and notifies the human-in-the-loop queue. The accounting knowledge lives in the leaf agents. The orchestration logic stays clean.

# Simplified orchestrator dispatch logic

async def run_dag(graph: AuditDAG, context: AuditContext) -> AuditResult:
    completed = set()
    in_flight  = {}

    while not graph.all_complete(completed):
        ready = graph.get_ready_nodes(completed)

        for node in ready:
            if node.id not in in_flight:
                in_flight[node.id] = asyncio.create_task(
                    run_agent(node, context)
                )

        done, _ = await asyncio.wait(
            in_flight.values(),
            return_when=asyncio.FIRST_COMPLETED
        )

        for task in done:
            result = task.result()
            if result.status == "BLOCKED":
                await escalate(result)
                return AuditResult.partial(completed)

            completed.add(result.node_id)
            del in_flight[result.node_id]
            context.update(result.artifacts)

    return AuditResult.complete(context)
      

Context propagation and the artifact contract

The hardest engineering problem was not the agents themselves — it was getting data between them correctly. In a monolithic system, a function passes its return value directly to the next function. In a distributed multi-agent system, the "return value" of an agent is an artifact: a structured document that another agent will consume later, possibly much later and possibly on a different machine.

We defined a strict artifact schema for every agent pair. Every artifact is versioned, typed, and immutable. When the AP Reconciler produces a reconciliation report, it emits a typed APReconArtifact that specifies exactly which fields are guaranteed to be present. The IC Eliminator, which depends on this artifact, knows at compile time what shape of data it will receive. If the shape changes, the system fails loudly during integration testing — not silently in production.

Human-in-the-loop without breaking the loop

Compliance requirements mandate human review above certain materiality thresholds. This cannot be an afterthought — in our domain, an AI system that routes around human oversight is a regulatory liability, not an engineering achievement. But naively blocking the entire DAG while waiting for human approval destroys the latency advantage you built the system to achieve.

Our solution was to treat human review as a first-class node type in the DAG, with its own timeout and escalation path. When the Attestation Agent flags an item for human review, it emits a PENDING_REVIEW artifact and sends a structured notification to the relevant reviewer. The DAG continues on all branches that do not depend on that item. If the reviewer responds within the SLA window, their decision is incorporated and downstream nodes proceed. If they do not, the entire audit package is paused, not failed, and re-queued for the next business day.

Results

What 80% faster actually means in practice

A quarterly financial close that previously took a team of eight people eleven days now completes its first draft in eighteen hours. Human reviewers then spend two to three days on materiality judgments, exceptions, and narrative refinement — work that is genuinely high-judgment and benefits from human expertise. The other eight days were clerical and reconciliation work that the agents handle completely.

The accuracy improvement is, if anything, more significant than the speed improvement. Human reconciliation at scale is prone to fatigue errors, inconsistent application of materiality thresholds, and copy-paste mistakes in working papers. The agents apply the same logic to the ten-thousandth transaction as to the first. The error rate on mechanical reconciliation tasks has dropped to effectively zero. The errors that remain — and there are some — are in ambiguous accounting judgments, which is precisely where human oversight belongs.

"The agents apply the same logic to the ten-thousandth transaction as to the first. This is not an aspirational property. It is simply how deterministic software works."

Lessons for teams building similar systems

What comes next

We are currently working on two extensions to this architecture. The first is a reflection layer: a meta-agent that reviews completed audit packages, identifies patterns in the exceptions that humans override, and surfaces those patterns as candidate policy updates. The goal is to close the feedback loop between human judgment and agent behavior systematically rather than through occasional manual rule updates.

The second is cross-client generalization. Right now, each client deployment is configured with client-specific policy rules, chart of accounts mappings, and ERP connectors. We are working on a configuration layer that would allow a new client to be onboarded by describing their accounting environment in natural language and having the system derive the correct configuration — with human review before go-live.

The deeper lesson of this project is that multi-agent orchestration is not primarily an AI problem. It is a systems design problem that happens to have AI components. The disciplines that make distributed systems reliable — clear interfaces, bounded responsibilities, observable state, graceful degradation — apply here exactly as they do in any other complex system. The agents are powerful. The architecture is what makes them trustworthy.