AWS published a reference architecture for multi-agent M&A due diligence built on Bedrock AgentCore. The system coordinates specialized agents (financial analysis, legal review, risk assessment) against thousands of documents while enforcing approval gates and audit trails. This is the first public AWS pattern showing how to route tasks between agents without circular dependencies, integrate knowledge retrieval at scale, and satisfy regulatory controls in a document-heavy workflow.
Why M&A Due Diligence Stresses Agent Orchestration
M&A workflows combine three hard problems:
- Document volume: Thousands of contracts, financial statements, and compliance records with overlapping clauses.
- Specialization: Financial analysts, legal counsel, and risk officers each need different slices of the same corpus.
- Governance: Regulated industries require human-in-the-loop checkpoints, audit logs, and approval gates before decisions propagate.
Traditional RAG systems struggle because a single retrieval step cannot surface the right context for multiple stakeholders. Multi-agent systems struggle because naive orchestration creates circular dependencies (legal agent calls financial agent, which calls legal agent again).
AgentCore solves this by treating agents as stateful, addressable services with explicit routing rules and shared knowledge bases.
Architecture: Orchestrator, Specialists, and Knowledge Retrieval
The reference architecture uses a supervisor agent pattern:
- Orchestrator agent: Receives the due diligence request, decomposes it into subtasks, and routes each to a specialist.
- Specialist agents: Financial analysis, legal review, risk assessment. Each has its own prompt, tools, and retrieval filters.
- Knowledge base: Amazon Bedrock Knowledge Bases backed by OpenSearch Serverless. Documents are chunked, embedded, and indexed with metadata (document type, date, entity).
- Governance layer: Step Functions workflow wraps the orchestrator, injecting approval gates and logging state transitions to CloudTrail.
Routing Without Circular Dependencies
The orchestrator uses a directed acyclic graph (DAG) of tasks:
- Financial analysis runs first, extracting revenue, EBITDA, and debt covenants.
- Legal review runs in parallel, scanning contracts for change-of-control clauses and indemnification terms.
- Risk assessment runs last, consuming outputs from both financial and legal agents.
Each specialist agent is invoked via Bedrock’s InvokeAgent API with a task-specific prompt and a retrieval filter. The orchestrator never allows a specialist to call another specialist directly. All coordination flows through the orchestrator’s state machine.
# Simplified orchestrator logic
def orchestrate_due_diligence(target_company_id):
# Step 1: Financial analysis
financial_task = {
"agent_id": "financial-agent",
"input": f"Analyze financials for {target_company_id}",
"retrieval_filter": {"document_type": "financial_statement"}
}
financial_result = bedrock.invoke_agent(**financial_task)
# Step 2: Legal review (parallel)
legal_task = {
"agent_id": "legal-agent",
"input": f"Review contracts for {target_company_id}",
"retrieval_filter": {"document_type": "contract"}
}
legal_result = bedrock.invoke_agent(**legal_task)
# Step 3: Risk assessment (depends on both)
risk_task = {
"agent_id": "risk-agent",
"input": f"Assess risk for {target_company_id}",
"context": {
"financial": financial_result,
"legal": legal_result
}
}
risk_result = bedrock.invoke_agent(**risk_task)
return {
"financial": financial_result,
"legal": legal_result,
"risk": risk_result
}The orchestrator serializes specialist outputs into the next agent’s context. This avoids re-retrieving documents and prevents infinite loops.
Knowledge Retrieval: Metadata Filters and Context Windows
Each specialist agent queries the same knowledge base but with different filters:
- Financial agent:
document_type: financial_statement,date_range: last_3_years - Legal agent:
document_type: contract,clause_type: change_of_control - Risk agent:
document_type: compliance_report,entity: target_company
Bedrock Knowledge Bases uses OpenSearch Serverless for vector search. Documents are chunked into 512-token segments with metadata preserved. At query time, the agent’s retrieval filter is passed to OpenSearch as a pre-filter before vector similarity search runs.
This keeps context windows manageable. Instead of retrieving 10,000 chunks and hoping the LLM finds the right clause, the filter narrows the corpus to 50 relevant chunks before embedding similarity runs.
Handling Overlapping Context
When the risk agent needs both financial and legal context, the orchestrator injects summarized outputs from prior agents into the prompt. The risk agent does not re-retrieve the same documents. This reduces token costs and latency.
Governance Controls: Approval Gates and Audit Logs
The Step Functions wrapper enforces three governance checkpoints:
- Pre-analysis approval: Human reviews the document corpus before agents run.
- Post-specialist approval: Legal counsel reviews contract findings before risk assessment runs.
- Final approval: CFO approves the consolidated report before it reaches the deal team.
Each checkpoint is a Step Functions task that waits for an SQS message or API Gateway callback. The workflow state is logged to CloudTrail, creating an immutable audit trail.
{
"Comment": "M&A Due Diligence Workflow",
"StartAt": "PreAnalysisApproval",
"States": {
"PreAnalysisApproval": {
"Type": "Task",
"Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
"Next": "InvokeOrchestrator"
},
"InvokeOrchestrator": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:orchestrator",
"Next": "PostSpecialistApproval"
},
"PostSpecialistApproval": {
"Type": "Task",
"Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
"Next": "FinalApproval"
},
"FinalApproval": {
"Type": "Task",
"Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
"End": true
}
}
}The waitForTaskToken pattern suspends execution until a human approves via a web UI or Slack bot. CloudTrail logs every state transition, including who approved and when.
Deployment Shape
The reference architecture deploys as a CloudFormation stack:
- Bedrock agents: Three specialist agents (financial, legal, risk) and one orchestrator agent.
- Knowledge base: OpenSearch Serverless collection with vector index and metadata filters.
- Step Functions: Workflow with approval gates.
- Lambda: Orchestrator function that invokes agents and aggregates results.
- S3: Document corpus bucket with lifecycle policies for retention.
The stack uses IAM roles to enforce least privilege. Each agent can only invoke its own tools and query its own retrieval filters. The orchestrator has cross-agent invoke permissions but cannot write to the knowledge base.
Trade-offs and Failure Modes
| Dimension | Strength | Weakness |
|---|---|---|
| Orchestration | DAG prevents circular dependencies | Orchestrator is a single point of failure |
| Retrieval | Metadata filters reduce context bloat | Filters must be tuned per document schema |
| Governance | Step Functions provides audit trail | Human approval gates add latency |
| Cost | Parallel specialist invocations reduce wall time | Each agent invocation costs $0.002 per 1K input tokens |
| Scalability | OpenSearch Serverless auto-scales | Cold starts on Lambda orchestrator add 2-5s |
Likely Failure Modes
- Context overflow: If a specialist retrieves too many chunks, the LLM hits token limits. Mitigation: tune chunk size and top-k retrieval.
- Approval timeout: If a human does not respond within the Step Functions timeout (default 1 year), the workflow stalls. Mitigation: set shorter timeouts and send escalation alerts.
- Agent hallucination: Specialist agents may fabricate clauses if retrieval returns no results. Mitigation: enforce citation requirements in prompts and validate outputs against source documents.
Observability: CloudWatch and X-Ray
The orchestrator emits structured logs to CloudWatch:
- Agent invocation start/end
- Retrieval filter applied
- Number of chunks retrieved
- Token counts (input/output)
Step Functions integrates with X-Ray, tracing each agent invocation as a subsegment. This makes it easy to identify which specialist is slow or which retrieval filter is returning too many results.
Technical Verdict
Use Bedrock AgentCore for M&A due diligence when:
- You have thousands of documents with structured metadata (document type, date, entity).
- You need multiple specialists with non-overlapping retrieval needs.
- Regulatory compliance requires approval gates and audit trails.
- You already run on AWS and want managed infrastructure.
Avoid it when:
- Your document corpus lacks metadata (retrieval filters will not help).
- You need real-time responses (approval gates add latency).
- Your workflow changes frequently (Step Functions state machines are verbose to update).
- You need cross-cloud orchestration (AgentCore is AWS-only).
The reference architecture is production-ready for regulated industries. The DAG orchestration pattern generalizes to any multi-stakeholder workflow where specialists need different slices of the same corpus.