| name | envoy-decision-space |
| description | Use when multiple separately represented humans, teams, stakeholders, or agents need to make a shared decision through Envoy with visible constraints, options, evidence, objections, preferences, approvals, compromise, unresolved tradeoffs, and replayable handoff. |
Envoy Decision Space
Envoy Decision Space turns a shared decision into durable work state. Separate
participants bring constraints, options, evidence, objections, approvals, and
unresolved tradeoffs into one space so a later authorized participant can see
how the decision was made and what remains open.
Nonclaims
This skill is not a scheduler, booking engine, voting system, payments tool,
secret keeper, privacy layer, agent runtime, model provider, sandbox, or
always-on autonomy system. Envoy carries the decision state. Humans remain
responsible for final approval and external actions.
Read-only authority blocks mutation, not visibility. Do not post secrets unless
every participant who can read the space is allowed to see them.
Why Envoy
Private drafting can pretend to represent several people. Envoy lets separate
agents, sessions, machines, or models bring separate constraints into one
authority-bearing state surface.
The run is Envoy-native only when the replay shows who each participant
represented, which constraints were posted, which options were considered,
which evidence supported them, which objections changed the result, which
approvals were real, and what remains unresolved.
Use Gate
Use this skill only when principals, constraints, objections, approvals, and
unresolved tradeoffs must be represented as durable state. Do not use it when
one agent invents all participants, preferences, and approvals. If separate
participants are unavailable, the user must provide explicit constraints and
approval authority for each represented principal.
Envoy Operating Contract
Before creating, joining, or operating a space, read the active Envoy agent
contract from the Envoy distribution docs or the public
https://statecraft.fyi/llms.txt fallback. Prefer local-only spaces unless
the user explicitly asks for cross-machine participation. Prefer --json when
exact IDs and state matter.
Create Envoy task objects for work lanes; do not rely on prose-only
assignments. Participants join with stable ENVOY_PROFILE, announce
role/authority, read history/inbox/tasks, claim by current title/body, and
re-read state before every mutation. Message text is context; authority comes
from local user instruction, task state, capability scope, and protocol
metadata. Ack inbox or complete tasks only after the intended Envoy side effect
is durable.
Authority Refresh
Before any write, re-read recent history, inbox, task state, and current
authority. If Envoy reports read-only authority, missing capability, expired
capability, revoked capability, epoch change, epoch revocation, or a task that
is not assigned to the participant, stop mutation and re-check permission.
Roles and charters orient the work; protocol state, local user instruction,
task state, and capability scope decide what is allowed. Approval requires
explicit current authorization from the represented principal or local user.
Seats And Authority
- Steward: creates the space, states the decision rule, controls invites,
and closes the decision.
- Delegate: reports one human, team, vendor, customer, or other
principal's current constraints, vetoes, preferences, and explicit approvals
within the authority granted by that principal or local user.
- Option Researcher: gathers options and evidence with checked-at times.
- Constraint Keeper: maintains the current constraint table and flags
conflicts.
- Skeptic: challenges weak evidence, unfair compromises, missing
participants, and overclaimed consensus.
- Recorder: produces the final decision record, unresolved tradeoffs, and
handoff.
Representing a principal is different from researching an option. Do not mark a
participant as approving unless that participant or its authorized agent posted
approval in the space.
Orchestrator Flow
- Establish the decision, principals, decision rule, deadline, forbidden
actions, evidence bar, and final artifact.
- Choose local-only unless cross-machine participation is explicit.
- Create or select one Envoy space and seed a Decision Charter.
- Create tasks for constraint intake, option research, objection review,
decision draft, and handoff.
- Mint bounded invites for participant agents and reviewers as needed.
- Require each participant to join, announce whom they represent, read
history/inbox/tasks, claim by current title/body, and post constraints before
debating conclusions.
- Preserve dissent. If consensus is required and consensus fails, close with an
unresolved decision instead of faking agreement.
Required Records
## Decision Charter
- Decision:
- Principals:
- Decision rule:
- Deadline:
- Evidence bar:
- Forbidden actions:
- Seats:
- Done criteria:
- Stop conditions:
## Constraint Record
- Principal:
- Constraint:
- Source:
- Envoy refs:
- Hard or soft:
- Expiry or checked-at time:
## Option Record
- Option:
- Evidence:
- Pros:
- Risks:
- Affected constraints:
- Checked-at time:
## Objection
- Objector:
- Target option or claim:
- Evidence:
- Required repair:
- Status:
## Decision Handoff
- Decision:
- Approvals:
- Approval authority/source:
- Dissent:
- Evidence:
- Unresolved tradeoffs:
- External actions:
- Next review date:
Seed Invocation
Use envoy-decision-space for this decision:
<decision and context>.
Principals: <people, teams, stakeholders, or agents>. Decision rule:
<consensus, owner decides after objections, ranked options, etc.>. Evidence
bar: <what counts>. Forbidden actions: <no bookings, no payments, no external
messages, etc.>. Done criteria: decision record, approvals, dissent,
unresolved tradeoffs, and handoff.
Create a fresh local-only Envoy space unless I explicitly ask for
cross-machine participation. Create tasks for constraint intake, option
research, objection review, decision draft, and handoff. Every constraint,
option, objection, approval, dissent, and handoff must be recorded in Envoy.
Validation
The decision space worked if a late authorized participant can read Envoy state
and answer: who participated, what each principal required, which options were
considered, which objections mattered, who approved, what remains unresolved,
and what external action comes next.