v2 Published snapshot

Decision to Action

Drives an open question, choice, or problem end to end: frame the decision, gather evidence in parallel, attack the emerging answer, commit to one recommended next move, then execute it and verify the outcome. Stops at a research report only when no safe action exists.

Use when: there is a real decision or choice, evidence could materially change the answer, more than one viable action exists, and the outcome matters enough to justify structured investigation.

Do not use for: simple factual lookup, straightforward drafting, trivial reversible choices, or tasks where the requested action is already unambiguous.

Execution convention: keep intermediate work in runtime-private scratch state and return concise, human-readable handoffs in the conversation. Do not create repository files by default. Persist to a Case, Record, or an exported file only when the user explicitly asks for that form of durability.

Back to playbook

Starting inputs

decisionOwner

Who makes the final call. Defaults to the requester.

string

researchScope

Sources the agent may read. Defaults to supplied context, repository, and public sources; internal connected sources require explicit approval.

array

options

Known candidate options, if any. Leave empty when the options are themselves unclear.

array

deadline

When the decision must be made (ISO date or plain description).

string

question *

The question, choice, or problem as the requester stated it.

string

authority

Per-action-class permission: autonomous, approval, or forbidden. The four keys shown are a minimum; add finer-grained classes freely (e.g. draftEmail, sendExternalEmail, stagingDeploy, productionDeploy) — Step 6 defers to whatever classes are defined here.

object

constraints

Hard limits such as budget, timeline, headcount, or compliance.

object

Steps

  1. 1

    Frame the decision, scope, and authority

    Before researching, establish a decision contract in the conversation. State the decision, why it matters now, options, success criteria, constraints, deadline, what is known, the few unknowns that could change the answer, and the final decision owner.

    Agree the research scope before reading beyond the supplied context. Default to the supplied context, repository, and public sources. Reading email, chat, CRM, Drive, databases, saved memory, or other internal connected sources requires explicit permission.

    Set authority per action class. Unless explicitly granted, treat external contact, publishing, spending, permission changes, internal-source access, delegation, and creation of durable Epismo state as approval-required. Ask only for facts the requester must supply, such as preferences, priorities, internal constraints, or risk appetite.

    Gate: you can state a good answer, the allowed evidence sources, and the decision owner. Otherwise the framing is incomplete.

  2. 2

    Choose the research depth and map decisive questions

    Use the decision contract as the source of truth. If new information makes it materially wrong, return to framing and state the amendment explicitly.

    Choose the lightest investigation that can support the decision. For a cheap, reversible choice, a short direct check may be enough. Use structured research only when evidence could materially change the choice; use independent parallel lanes only when the stakes and deadline justify them.

    Work backwards from the decision: identify only the unknowns that could flip the recommended next move, then define the evidence that would settle each one and a clear stop condition. Do not access an internal source outside the agreed scope.

    Gate: the research plan is proportional, bounded, and contains no dependent lane marked for parallel work.

  3. 3

    Gather decisive evidence

    Gather decisive evidence according to the agreed plan. Investigate sequentially by default; use independent workers only for genuinely independent questions when the runtime supports delegation and the contract permits it. Each worker answers one scoped question and returns evidence, uncertainty, and decision impact, not a recommendation.

    Prefer primary sources, official documentation, original data or papers, reliable secondary sources, then community experience. Treat unsupported claims as unknowns. Keep only a concise, source-linked handoff; discard transient worker traces.

    Gate: every critical question has evidence or an explicit uncertainty, and no claim is presented as settled without a locatable source.

  4. 4

    Challenge the emerging recommendation

    Write a provisional recommended next move, then try to break it. Test the strongest counterargument, missing or stale evidence, contradictions, unstated assumptions, downside scenarios, arithmetic, and irreversible consequences.

    For high-stakes decisions, use an independent verifier when available. For code or built artifacts, inspect the source and separately validate real behavior. Label material claims as verified, disputed, unknown, or assumption, and keep the labels in a concise conversation ledger.

    Gate: each uncertainty capable of reversing the recommendation is resolved, shown not to change the next move, or named as a decision blocker for the owner.

  5. 5

    Recommend or identify the decision blocker

    Produce one recommended next move, not a pros-and-cons table. A bounded pilot with an explicit decision rule is a valid next move when a final irreversible choice is not justified. State the recommendation, why it wins, why the best alternative loses, evidence, confidence and its basis, risks, the decision owner, and what would change the recommendation.

    Do not force a decision when a decision blocker remains. State exactly what evidence or owner judgment is needed. Take a decision only when it is cheap, reversible, and explicitly within the granted authority; otherwise present proceed, modify, and stop with their consequences for the owner to choose.

    Gate: the owner can understand the recommendation and its limits without opening a local artifact.

  6. 6

    Turn the recommendation into safe progress

    Turn the recommendation into safe progress. Perform only actions that are safe and explicitly authorized. Prepare all other actions so they are one human approval away, but do not send, publish, buy, sign, delete, deploy, move money, change permissions, contact external parties, or create durable Epismo state without the required approval.

    Return a concise action handoff in the conversation: what was safely done, evidence that its real-world outcome was verified, what remains, and the exact approval needed. Use a Case or Record only when durable collaboration was explicitly requested; create local files only when the user explicitly requests an export.

    Done means: the recommendation is evidence-backed, uncertainties are explicit, safe actions are verified, and every remaining consequential action has a clear owner and approval boundary.