OrgX

Use when in-flight work must move to a different specialist agent without losing its context or execution state. Also known as: handoff task, transfer work, change assignee. USE WHEN: a task needs to be reassigned to a different specialist agent. NEXT: Use get_agent_status to confirm the new agent picked up the task. DO NOT USE: for new tasks — use spawn_agent_task instead.

handoff_task

Use when the user names a specific task, milestone, initiative, decision, artifact, or plan session and you need its real state — decisions, owners, linked proof — before acting. Hydrates one OrgX entity with execution context. Also known as: Inspect OrgX Entity, inspect initiative, get full entity context. USE WHEN: continuing work on a named entity or verifying state before a lifecycle change. NEXT: use orgx_search for related records or orgx_recommend for a read-only next-step assessment. DO NOT USE WHEN: browsing or searching many records; use orgx_search. Read-only.

orgx_inspect

Pause, resume, retry, or cancel any node in the work hierarchy — an initiative, workstream, milestone, task, or run. Propagates to descendant tasks + active runs. USE WHEN: the user wants to halt, restart, or re-run part of an initiative. resume/retry re-dispatch the work; pause/cancel stop active runs. NEXT: get_initiative_pulse to confirm. DO NOT USE: to mark a task done — use entity_action instead.

manage_lifecycle

Creates or remembers durable OrgX decisions, lists pending decisions, and opens human review. Approval and rejection are human-session-only: those actions return a review URL and never resolve the decision or resume work from MCP. Per-action input requirements: • action="list_pending" → No required fields; initiative_id and workspace_id are optional filters. • action="create" → REQUIRES title and decision. Optional: context, initiative_id. • action="remember" → REQUIRES decision. Optional: title, context. • action="approve" → REQUIRES decision_id. Optional note is accepted but not persisted by MCP. • action="reject" → REQUIRES decision_id and reason; MCP does not persist the reason. USE WHEN: capturing judgment or reviewing a pending decision. NEXT: open the returned review URL, then act only after the decision resolves. DO NOT USE WHEN: writing non-decision entities; use orgx_write.

orgx_decide

Use when planning should survive the session and become executable context instead of a lost chat draft. Starts, resumes, edits, improves, or completes a tracked OrgX planning session. Per-action input requirements: • action="start" → REQUIRES feature_name. Optional: initial_plan (markdown to seed the session). • action="resume" → Optional session_id; when omitted, resumes the most recent active session in the authenticated workspace. • action="improve" → REQUIRES session_id AND plan_content (the current draft to critique). • action="record_edit" → REQUIRES session_id AND edit_summary (one-line description of the change). • action="complete" → REQUIRES session_id AND plan_content (the final accepted plan). Optional: attach_to (target entity to link the completed plan to). USE WHEN: work is still in planning or should become executable context. NEXT: use orgx_write or orgx_act after the plan is accepted and needs durable execution state. DO NOT USE WHEN: directly scaffolding a full initiative hierarchy; use scaffold_initiative for that compatibility path.

orgx_plan

Use when the user asks what to do next, wants a brief, or returns after time away and needs priorities. Recommends next work, summarizes operator-chronicle/morning-brief signals, and reads prioritization context. The default next_action mode records metered MCP allowance usage; it does not change business records. USE WHEN: user asks what to do next, wants a brief, asks what changed yesterday/week/30 days, or needs priority guidance. mode=morning_brief returns the operator chronicle when available. NEXT: present the recommendation and ask for explicit confirmation before any separate action. DO NOT USE WHEN: the user already specified a concrete action.

orgx_recommend

Use when the user has reviewed a pending decision and wants to reject it or send the agent back with revisions. Also known as: request revisions, send feedback, decline decision. USE WHEN: user wants to reject or request revisions on a decision. NEXT: Agent will revise their approach based on the reason. DO NOT USE: without a reason — always include why. Requires decisions:write.

reject_decision

Use when the user asks to review work, sign off on a deliverable, or clear pending artifact reviews. Surfaces the next artifact awaiting review and renders the artifact-review widget with a preview, version filmstrip, and hold-to-approve / request-changes actions. USE WHEN the user asks to review work, approve a deliverable, or handle pending artifact reviews. DO NOT USE for listing all artifacts — use list_entities type=artifact instead.

review_artifact

Turn a goal, roadmap, launch, or feature plan into one owned initiative with workstreams, milestones, and tasks. Minimum input is title; workspace context is resolved from the session when omitted. workstreams use {title|name, milestones:[{title, tasks:[{title}]}]}; other nested fields are optional. mode=draft validates, mode=scaffold creates records, and mode=launch creates and dispatches work (default). For a named external product or URL, pass source_evidence; unverified sources must stay in draft. Returns initiative_id, ref_map, and preferred_next_calls. Also known as: scaffold project, create roadmap, build workstream tree. USE WHEN: a full initiative hierarchy should be created from a plan. NEXT: inspect the returned initiative or launch its first executable task. DO NOT USE: to add one item to an existing hierarchy; use orgx_write.

scaffold_initiative

Use when context was lost between sessions, another agent's work must be continued, or the answer may already exist in team memory. Finds OrgX entities, decisions, artifacts, and memory. A query without type runs a mixed relevance search and records metered MCP allowance usage; typed searches provide exhaustive cursor/offset pagination without changing business records. Also known as: Search OrgX, find initiative ID, list work, browse OrgX. USE WHEN: browsing work, searching memory, finding IDs, or listing related records. NEXT: use structuredContent.next_call exactly when pagination.has_more=true, orgx_inspect for one selected result, or orgx_recommend when the user asks what to do next. DO NOT USE WHEN: you already know the exact entity and need full context; use orgx_inspect.

orgx_search

Delegate specialist work or check whether delegation is allowed. Actions: guard, estimate, classify, spawn, and handoff. Requirements: existing-task spawn needs task_id; ad-hoc spawn needs title + instructions and should include agent_type. handoff needs task_id + agent_type. guard needs agent_type. classify needs title or task_id. action="estimate" needs title or task_id and returns candidate routes and cost context without dispatching work. OAuth: guard/classify/estimate require agents:read; spawn requires agents:write; handoff requires BOTH agents:write and initiatives:write. Routing: omit model_tier/provider/model for OrgX auto-routing. Set routing or budget fields only when the user, policy, or verification plan constrains them. For controlled reliability validation, use model_tier="standard" and budget_mode="cheapest_valid". USE WHEN: delegating work or checking permission/cost before delegation. NEXT: monitor with orgx_inspect or orgx_search, then attach proof with orgx_submit_receipt. DO NOT USE: to create only a task row; use orgx_write.

orgx_spawn

Use when the user says "show me it actually shipped" — completion must be proven with evidence, not prose. Submits a durable receipt anchored to an OrgX entity or artifact. Required: receipt_type + summary. Strongly recommended: one anchor (entity_type+entity_id OR artifact_id), artifact_type, business_outcome, agent_type, and a verifiable URL in evidence. Recognized receipt_type: "proof", "outcome" (measurable result), "quality" (review/score), "attribution" (credit link to revenue/value), "learning" (distilled lesson). Custom keys also accepted. Recognized evidence shapes (mix and match): { prs: string[] } — GitHub PR URLs. { deploys: string[] } — deployment URLs. { test_runs: string[] } — CI run URLs. { metrics: { name, value, unit? }[] } — quantitative outcomes. { links: string[] }, { notes: string } — supporting URLs/text. Pass idempotency_key when retrying — server deduplicates. USE WHEN: closing the loop on agent work with provenance. Receipts should prove the practical artifact and its business outcome, not just say the agent finished. NEXT: orgx_recommend or orgx_search to find the next priority. DO NOT USE for telemetry — use orgx_emit_activity.

orgx_submit_receipt

Create or update one OrgX record (snake_case fields). Operations: create (default) uses per-type fields; update REQUIRES id + fields. Create requirements: workspace name/title; initiative title/name + workspace_id + goal_ids when the workspace enforces primary objectives; workstream title + initiative_id; milestone title + workstream_id; task title + workstream_id + milestone_id when the workspace requires backlog milestones; decision title; artifact target + artifact_type + artifact_url/external_url; blocker run_id + metadata.description; skill/studio records title. Retry behavior: pass idempotency_key on creates. A key match returns the same UUID as an idempotent replay, without creating a duplicate. Initiative constraints: priority accepts low|medium|high|urgent, not portfolio labels such as active/critical/maintenance/hold. due_date is not accepted on initiative create; store portfolio urgency and target dates in metadata. USE WHEN: adding/editing records. Initiative writes can publish a public live link, and update patches overwrite the supplied fields. NEXT: orgx_act to launch/complete the record. DO NOT USE for lifecycle changes — use orgx_act or orgx_attach.

orgx_write