conflicts

/conflicts (cross-document conflict detection)

Runs OloLand's Deal Document Conflict Detector over a deal's ingested documents. It reads the data room against itself and surfaces places where two documents disagree — a revenue figure that differs between the CIM and the audited financials, an ownership percentage that moves between the cap table and the SPA, a close date that conflicts across the LOI and the disclosure schedule. Each conflict is traced to the specific documents (and pages) that disagree, so it is a review item you can act on, not a vibe.

This is the discrepancy-hunting complement to /verify: /verify checks that the figures an artifact states are supported by the corpus; /conflicts hunts for places the corpus contradicts itself.

Usage

/conflicts <deal_id>

Arguments

• deal_id (required) — the OloLand deal whose ingested documents to scan. Requires a deal with a populated data room (multiple documents — there is nothing to cross-check in a single file).

Execution

This is an asynchronous managed-agent run. Do not expect an immediate answer; start it, then poll.

1. Start. Call mcp__ololand__run_conflict_detection with deal_id. It returns a task_id (with task_type: "managed_conflict_detection").
   • If it returns {"error": "Deal not found: …", "error_code": "not_found"} — the deal id is wrong; ask the user to confirm it with mcp__ololand__list_deals.
   • If it returns {"error": "Company scope required …"} — the MCP connection is not company-scoped (it needs a database-backed olo_agent_sk_* key, which the OloLand connection provides on sign-in). Tell the user to reconnect / sign in, do not retry blindly.
   • If the tool itself errors (e.g. the managed executor is unavailable) the call fails closed — relay the error rather than presenting an empty "no conflicts" result.
2. Poll. Call mcp__ololand__check_task_status with the task_id every few seconds. While state is STARTED / PROGRESS, relay the progress message (it names each engine call, e.g. Engine call: reconcile_documents) so the user sees it working. Keep polling until state is SUCCESS or FAILURE.
3. On FAILURE — report the error verbatim. Do not synthesize a conflict list from nothing.
4. On SUCCESS — the result object is:
   • status — "success" or "error". Check it: an error status means the run completed but the agent hit a problem mid-flight.
   • error — null on success; on an error status, the message string to relay.
   • text — the conflict report itself: a structured list of conflicts (each with the conflicting sources, the disagreeing values, and a severity) plus a confidence / limitations note. This is the deliverable.
   • run_id — the replayable agent_runs row.
   • artifact_id — the persisted conflict_report artifact.
   • tool_calls — how many engine calls the detector made.