Get Started

Decision to Action

Use when someone brings an open question, choice, or problem where research could change what they should actually do — vendor selection, hiring, market entry, build-or-not, where to focus. Drives it end to end: frame the decision, gather evidence in parallel, attack the emerging answer, commit to one recommendation, then prepare or execute the next actions. Stop at a research report only when no safe action exists.

  1. 1

    Frame the decision

    Do not start researching. Convert the request into a decision contract first.

    Read the context you already have, then write down: what is being decided, why now, the candidate options, what a good outcome looks like, hard constraints, the deadline, what is already known, which unknowns could change the answer, who owns the final call, and what the agent may do without asking.

    Ask the requester only about things you genuinely cannot look up — preferences, priorities, internal constraints, risk appetite. Anything searchable, go find yourself.

    If the options are vague or the real question is hidden behind a stated one, stress-test the framing before accepting it.

    Gate: you may proceed only once you can state what a good answer would look like. If you cannot, the framing is not done.

  2. 2

    Map what must be known

    Work backwards from the contract: which unknowns could actually flip the decision? Only those are worth researching.

    Harvest internal context before touching the open web — local files, prior reports, email, chat, drive, CRM, code, databases, saved memory. Reach these through MCP servers or native connectors where they exist; when a CLI or API already exists, drive that directly instead of building new plumbing.

    Then split the remaining gap into 3-6 research lanes. Each lane is one question that can be investigated largely independently of the others. Mark each lane critical, high, or normal, and name the source types that would settle it.

    Write an explicit stop condition so research can terminate.

    Gate: parallelize only lanes that do not depend on each other's findings. Do this mapping yourself — do not spawn research agents yet.

  3. 3

    Investigate in parallel

    Now delegate. Hand each independent lane to its own short-lived research agent: one agent, one question. Do not ask an agent for an essay, and do not let it recommend anything.

    Require source-first work, in this order of preference: primary source, official documentation, original data or paper, reliable secondary source, community experience. A claim with no locatable source is an unknown, not a finding.

    Collect every agent's result in the same shape so the findings can be compared rather than read one by one. Keep only the structured result in coordinator context; discard the agent's working transcript.

    Gate: for every critical lane there is evidence, each finding names its source, and the remaining uncertainty is stated rather than smoothed over.

  4. 4

    Challenge the emerging answer

    Write a provisional recommendation, then try to break it. This phase is what separates this playbook from a research report.

    Go after: the strongest counterargument, missing evidence, findings that contradict each other, assumptions nobody stated, the downside scenario, how stale the sources are, whether the numbers actually add up, and which consequences are irreversible.

    When the stakes justify it, send the hypothesis to an independent verifier that did not gather the evidence. For code or built artifacts, review the source and separately validate real behavior.

    Record every material claim in one ledger, tagged: [V] verified, [D] disputed, [U] unknown, [A] assumption.

    Gate: the unknowns that could reverse the recommendation have been reduced to a level you can defend in writing.

  5. 5

    Decide

    The coordinator decides. Never delegate this to a research agent.

    Produce exactly one recommendation — not a pros-and-cons table for the human to resolve. State: the recommended option, why, why the best alternative loses, the material evidence behind it, a confidence level, the real risks, and the specific findings that would reverse the decision.

    If the decision is cheap and reversible and you hold the authority, take it and say so. Return it to the human owner when it is expensive, irreversible, or outside the granted authority.

    When you return it, do not ask "what would you like to do?" Present the recommendation, the evidence, the remaining risk, and named choices with their consequences: proceed, modify, or stop.

  6. 6

    Turn the decision into action

    A decision that produces nothing is not done. Build an action pack, choosing domain skills to fit the decision — a spec and tickets for a product call, drafts and trial setup for a vendor call, an itinerary and booking-ready options for a trip, reference questions and an offer draft for a hire.

    Do freely: search, read, analyze, calculate, draft, prepare, validate, simulate. Stop for explicit approval before you send, publish, purchase, sign, delete, deploy, move money, change permissions, or commit anyone to an external obligation.

    Execute what is safe and authorized. Leave everything else approval-ready — written, checked, one confirmation away — and log what was executed versus what is waiting.

    Done means: the decision is made and evidence-backed, major uncertainties are explicit, next actions are concrete, artifacts exist, safe actions are executed, and unsafe ones wait only on a human yes.