AI System Architecture for Programmatic M&A

An AI system for programmatic M&A connects research, deal decisions, and post-close results through shared evidence and durable workflows. Design it around the work a team must finish and the decisions people must own.

The architecture below is a reference design for builders. It describes how components should behave, rather than promising a specific product configuration.

Separate the system into six responsibilities

Keep the boundaries clear even if one application implements several components. This makes failures easier to detect and changes easier to test.

A workflow should continue after a browser closes or a worker restarts. Store progress outside the conversation. Keep the explanation readable, but use typed records for state transitions and tool inputs.

Route each task to the right method

Use language models for interpreting documents, proposing classifications, and drafting explanations. Use deterministic code or spreadsheet formulas for arithmetic and financial schedules. Use rule checks for mandatory fields, permitted transitions, and approval authority.

Choose models against task-specific evaluation results. Screening a company description, reading a scanned table, and reconciling contradictory contract clauses have different failure modes. Include document extraction quality and reviewer effort in the comparison.

Multiple agents can be useful when tasks are independent and outputs have clear contracts. A commercial reviewer and a technical reviewer can work separately. Their final synthesis must retain disagreements and shared source dependencies. Agreement between agents that read the same wrong source is not independent confirmation.

Make each run inspectable and restartable

A run record should identify the workspace, deal, workflow version, input versions, model configuration, and tool permissions. Record cost, start and completion times, errors, and reviewer decision.

Use explicit states such as queued, running, awaiting review, completed, failed, and canceled. Mark a run complete only when its required outputs pass validation. A provider response is not proof that a usable memo or model exists.

Retries need bounded budgets and stable operation identifiers. If a worker times out after creating a research task, the retry should recover that task rather than create another. Bind a proposed action to its reviewed payload so a later edit cannot inherit stale approval.

Carry one finding through the whole system

Consider a hypothetical diligence finding: the seller's contract requires consent before a customer migration.

1. Ingestion records the contract version and any unreadable pages.
2. Retrieval returns the relevant clause and amendment, within the deal's access scope.
3. The analyst records a finding, affected customer, open interpretation, and counsel reviewer.
4. Counsel resolves the issue; the integration owner updates the migration dependency.
5. Finance reruns the cash-flow timing using the reviewed input.
6. The deal lead submits the revised recommendation for approval.

When the contract changes, the system flags dependent findings as needing review. It preserves the earlier decision and its evidence rather than silently replacing them.

Test recovery at the storage boundary

Interrupt the workflow at each point where it changes state. Inspect stored records and tool calls to confirm what happened, then resume the run.

Implement these as integration tests against real storage and tool boundaries. Confirm that the final write checks the operation identifier before creating or changing a record. Repeat the tests after changing orchestration, permissions, or tool contracts, and add failures observed during operation.

Continue with data and evidence, AI governance, and the implementation playbook.