Structured Entities
Tickets, OKRs, sprints, releases — first-class.
Eleven structured entity kinds for the work that doesn't fit a markdown doc — bugs, incidents, OKRs, sprints, releases, experiments, reviews, risks, backlogs, and the handoff workflow. All managed via one unified MCP tool.
Quick reference
One tool, eleven kinds.
All structured entities use the unified entity(...) tool. Pass kind to pick the entity and action to pick the operation.
entity(
action: "list" | "get" | "create" | "update" | "delete",
kind: "ticket" | "handoff" | "backlog_view" | "incident" |
"release" | "experiment" | "goal" | "key_result" |
"sprint" | "review" | "risk",
id?: "<uuid>", // for get / update / delete
body?: { ... }, // for create / update — free-form JSON
query?: { ... }, // for list — flattened to URL params
workspace_id?: "<uuid>", // defaults to active workspace
project_id?: "<uuid>", // defaults to active project
)The eleven kinds
Pick the right shape for the work.
Ticket
kind="ticket"Structured work item — bug, feature, task, chore, incident, or epic. Heavier than a todo (status enum, kind, assignee, parent/sprint, labels, story points, external_ref for jira/linear sync) but lighter than a full plan.
When to use
When work needs more structure than a checkbox: assignment, status timeline, parent/child links to epics, sprint placement, or external-tracker sync.
kind
bugfeaturetaskchoreincidentepicstatus
openin_progressblockedin_reviewresolvedclosedcancelledpriority
lowmediumhighurgententity(action="create", kind="ticket", body={
"title": "Fix replication lag on Oregon read replica",
"kind": "bug",
"priority": "high",
"labels": ["postgres", "infra"],
"external_ref": "JIRA-1234"
})Handoff
kind="handoff"Session/agent/team handoff workflow record. Wraps a ContextCapsule (purpose=handoff) which holds the artifact bundle; this row holds the workflow shell — sender, recipient, scope, status, open questions, next steps, linked artifacts.
When to use
When packaging context for another session, agent, or teammate. Pair with capsule(...) to materialize the bundle.
status
draftpendingacceptedcompletedcancelledentity(action="create", kind="handoff", body={
"title": "Auth middleware refactor — finish the rotation tests",
"scope": "tests/auth/*, src/middleware/auth.rs",
"to_agent": "claude",
"summary": "Refactor done; 3 of 5 rotation tests pass; the failing 2 hit a clock-skew edge case.",
"open_questions": ["Should we mock Utc::now() or use tokio::time::pause?"],
"next_steps": ["Replace Utc::now() in rotate_token with the SystemClock trait"],
"capsule_id": "<paired ContextCapsule uuid>"
})Backlog View
kind="backlog_view"Saved ordered slice over tickets. Not a separate entity — a named view + ordering on the tickets table (now/next/later/icebox or any custom bucket) with optional explicit ticket_id ordering.
When to use
When you want a reusable prioritized list view on top of tickets — team backlog, personal queue, sprint candidates, etc.
entity(action="create", kind="backlog_view", body={
"name": "Now / Next / Later",
"bucket": "now",
"filters": { "status": "open", "kind": "bug" },
"ticket_order": ["<uuid-a>", "<uuid-b>", "<uuid-c>"]
})Incident
kind="incident"Operational incident with severity (sev1-4), status timeline, services-affected, incident commander, reporter, and explicit links to the associated ticket and postmortem doc.
When to use
When something is on fire — outage, degraded service, security event. Status transitions auto-set timestamps (detected_at, mitigated_at, resolved_at, closed_at).
severity
sev1sev2sev3sev4status
detectedinvestigatingmitigatedresolvedpostmortem_pendingclosedentity(action="create", kind="incident", body={
"title": "API 500s on /v1/search across all regions",
"severity": "sev1",
"status": "investigating",
"services_affected": ["api", "search"],
"summary": "Search returning 500 since 14:02 UTC; smoke tests failing."
})Release
kind="release"Versioned release record. Tracks version, status (planned/released/rolled_back), git_ref, environments, and links to a release_notes doc via changelog_doc_id.
When to use
When tracking deployments — planned releases, in-progress rollouts, and rollbacks. Distinct from an ad-hoc release_notes doc, which captures the human-readable changelog.
status
plannedin_progressreleasedrolled_backcancelledentity(action="create", kind="release", body={
"version": "1.4.0",
"status": "released",
"environments": ["prod", "eu-west"],
"git_ref": "abc1234",
"changelog_doc_id": "<release_notes doc uuid>"
})Experiment
kind="experiment"A/B test or product experiment with hypothesis, control, treatment, primary_metric, secondary_metrics, status timeline, and a link to a result writeup doc.
When to use
When running structured tests on product changes — feature flags, growth experiments, A/B tests. Pair the result_doc_id with a doc_type='postmortem'-style writeup when shipped or discarded.
status
draftrunningpausedcompletedshippeddiscardedentity(action="create", kind="experiment", body={
"name": "Onboarding checklist redesign",
"hypothesis": "Adding inline progress reduces drop-off in step 3",
"control": "Current sequential checklist",
"treatment": "Inline progress bar + collapsed steps",
"primary_metric": "step_3_completion_rate",
"secondary_metrics": ["d1_retention", "session_length"]
})Goal (OKR Objective)
kind="goal"OKR objective. Goals nest via parent_goal_id (company → team → personal). Each goal has N measurable key_results.
When to use
When tracking quarterly/annual objectives. Goals are the qualitative 'what we want to achieve'; key_results are the quantitative 'how we'll know'.
status
draftactiveon_trackat_riskoff_trackachievedmissedcancelledentity(action="create", kind="goal", body={
"objective": "Ship the platform to 100 paying customers",
"period": "2026-Q2",
"owner_user_id": "<uuid>",
"starts_at": "2026-04-01T00:00:00Z",
"ends_at": "2026-06-30T23:59:59Z"
})Key Result
kind="key_result"Measurable key result owned by a parent goal. Has unit (number/percent/currency/boolean), target_value, start_value, current_value, and status. Created nested under its goal.
When to use
Always paired with a goal. Express the measurable outcome that proves the objective was achieved.
unit
numberpercentcurrencybooleanentity(action="create", kind="key_result", body={
"goal_id": "<parent goal uuid>",
"title": "MAU > 10,000",
"unit": "number",
"start_value": 6500,
"current_value": 7200,
"target_value": 10000
})Sprint
kind="sprint"Time-boxed iteration with name, goal, status, and start/end window. Tickets join via tickets.sprint_id.
When to use
When organising work into iterations. Filter tickets by sprint to plan/run/review.
status
plannedactivecompletedcancelledentity(action="create", kind="sprint", body={
"name": "Sprint 42",
"goal": "Ship taxonomy v1 to GA",
"starts_at": "2026-04-28T00:00:00Z",
"ends_at": "2026-05-12T23:59:59Z"
})Review
kind="review"Structured review record — PR / code / design / security / architecture / product. Tracks requester, reviewers, decisions array, and a free-form subject_ref pointing at the artifact.
When to use
When formal review records matter: security audits, architecture reviews, design critiques, or PR reviews you want to surface in context later.
kind
prcodedesignsecurityarchitectureproductotherstatus
requestedin_progresschanges_requestedapprovedrejectedcancelledentity(action="create", kind="review", body={
"title": "Security review — new entity tool surface",
"kind": "security",
"subject_ref": "github:contextstream/contextstream#1234",
"reviewer_ids": ["<security-eng uuid>"]
})Risk
kind="risk"Active risk register entry with likelihood × impact, mitigation, contingency, owner, and links to a related ticket / incident. Distinct from the distilled node_type='risk' summary node — that's a short-form pointer, this is the system-of-record.
When to use
When tracking project / launch / compliance / security risks that need active management.
likelihood
rareunlikelypossiblelikelyalmost_certainimpact
negligibleminormoderatemajorseverestatus
openmitigatingacceptedtransferredavoidedclosedentity(action="create", kind="risk", body={
"title": "Third-party billing API may rate-limit during launch peak",
"likelihood": "likely",
"impact": "major",
"category": "external-dependency",
"mitigation": "Pre-warm 2x normal capacity; backoff queue with 60s retry"
})Related taxonomy
Structured entities vs. docs vs. events vs. nodes.
- Structured entities (this page) — when work has fixed shape: status enum, assignee, parent/child links, time-boxes.
- Docs — when content is markdown-shaped: runbooks, ADRs, RFCs, postmortems, retros, release notes, playbooks, PRDs, personas, glossaries, etc.
- Events — when capturing a moment in time: decisions, lessons, preferences, standups, achievements, customer feedback, approvals.
- Knowledge nodes — short-form distilled summaries: facts, decisions, preferences, constraints, habits, lessons, plus the new
goal/risk/termvariants. Promoted from raw events by the distillation pipeline (LLM + heuristic rules).
Best practices
A few things that pay off later.
Use external_ref for jira/linear sync
Tickets accept external_ref so you can correlate to your system of record. Format is free-form (e.g. 'JIRA-1234' or 'linear:TKT-99').
Pair handoffs with a ContextCapsule
Handoffs hold the workflow shell; capsules hold the artifact bundle (export, search results, notes). Set capsule_id when creating a handoff so the recipient gets the bundle.
Link incidents to tickets and postmortems
ticket_id and postmortem_doc_id let you walk the chain — from the page event to the bug, to the postmortem doc. Future context() calls surface the chain together.
Status transitions auto-set timestamps
Marking a release 'released' fills in deployed_at, marking it 'rolled_back' fills in rolled_back_at. Same for incidents (mitigated_at / resolved_at) and tickets (resolved_at / closed_at).
Backlogs are saved views, not entities
A backlog_view is a named ordering + filter spec on tickets. Multiple backlogs (team / personal / now-next-later) coexist freely — tickets are the source of truth.
Memory events
Capture significant moments
decisions, lessons, achievements, feedback
MCP tools
Full tool reference
entity, memory, search, graph, reminder, …