war-game

War Game Simulation

Run an RL-powered competitive strategy simulation for a deal.

Usage

/war-game <deal_id> [scenarios]

Arguments

• deal_id (optional) — The deal to simulate. If omitted, resolve it from the prose (see below).
• scenarios (optional) — Comma-separated: base_case, expansion, macro_stress, regulated_stress, or all. Default: base_case. When the user asks about regulatory response, include regulated_stress.

Natural-language invocation (no deal_id)

Users rarely pass a bare deal_id — they describe a company and a counterfactual, e.g. "/war-game on Robinhood, assume it built Exchange Funds in-house instead of acquiring Frec/Cache. Competitive and regulatory response?" Treat the counterfactual as a caller-supplied hypothetical. If the simulator or required deal evidence is unavailable, relay that result; do not present an empty or inferred result as a simulation.

1. Resolve the target to an existing deal. Use deal-search / list_deals to find an existing deal for the named company. If none exists, say that a deal context is required; do not create one automatically.
2. Separate review from execution. For an audit, review, or read-only request, follow /plan: create or reuse the deal conversation session, submit the user's verbatim counterfactual with submit_plan_for_approval, render the plan, and stop for approval. After approval, direct the user to continue the same session in the OloLand app or normal SSE/message endpoint with the returned plan payload supplied as approved_plan on SubmitMessageRequest. That field supplies execution context; it is not a persisted or hash-validated approval identity. Do not call the MCP ask_deal_agent or talk_to_deal tools for this planned execution because they cannot carry the field; quoted plan prose is not a substitute. If the client cannot use the normal endpoint, report the governed review as unavailable on this rail; do not run a simulation or infer an answer. For a request that explicitly asks to run the simulation, continue to Execution step 1; that is a bounded, fixed-purpose tool call rather than a conversational executor turn.
3. Pick scenarios from intent. "regulatory response" → regulated_stress; "across conditions" / unspecified depth → all; otherwise base_case.
4. If the user supplied a custom counterfactual or premise that would change the simulated business, buyer, capability, market, or competitive setup, fail closed as unsupported on this MCP rail. run_war_game_simulation accepts only deal_id and scenarios; do not discard the premise, invent an argument, substitute another tool, or run the default deal-context simulation as if it answered the custom question. State that the requested premise cannot be carried by this bounded tool. A plain scenario request with no custom premise may continue to Execution.
5. Separate factual buyer premises from simulator predictions. Do not claim a buyer/acquirer identity, observed strategy, historical action, expected synergy, or any other real-world premise unless a tenant-authorized returned source supports it with an inline citation. Keep caller-provided buyer premises labeled hypothetical. A completed simulator's modeled strategy, likely action, competitor response, EV distribution, or robustness score may be relayed without a document citation only when it is clearly labeled simulator prediction and tied to the exact returned simulation identity and scenario; never restate that prediction as a sourced fact.