Task Lifecycle
How tasks move through the system
Where §3-§6 covered what tasks are and who does them, this section covers how they move through the system.
Creation — the 4 stages
A task enters the system through four conceptual stages. The flow is the same for every task, but the time each task spends in each stage varies wildly — a templated trip-lifecycle task passes through in milliseconds; a relationship gesture may live as a suggestion for hours awaiting TA approval.
A raw event or sensed condition: a client message arrives, a flight feed pushes a delay, a scheduled query returns a hit. The signal is not a task — it's a candidate. Stored briefly while the system decides whether to make something of it.
The system promotes one or more signals into a proposed task. At this stage the task is not yet canonical — it has draft fields (title, rationale, evidence, proposed routing tier) but no entry on the main board. Suggestions live in the Review queue (see §7.2 Surface model). Stale suggestions expire silently after a window (24h default; see §8 for cadence questions).
The decision point between Suggestion and Canonical task. Every suggestion carries a confidence_score. The approval policy evolves in two phases:
- v1 (launch): every suggestion requires human review. The operator reviews (sees the rationale + evidence per §7.4), can edit any field, then approves or rejects. The
confidence_scoreis captured from day 1 for telemetry / calibration only — to learn where the auto-approval threshold should live per task type. - v2 (post-calibration): auto-approve above a confidence threshold (e.g. ~90%) per origin / task type. Below threshold still routes to human review. Threshold is product-tunable per type once telemetry supports the cut-over.
Distinct from the auto routing tier in §6.1 — that one describes post-canonical execution, not the creation gate. Auto-tier tasks (e.g. trip-prep templated checklists) still need a human approval click at creation in v1.
The approved task record (see §7.2 schema). Lives on the task board, executes per its routing tier (auto / assist / escalate per §6), closes per §7.3.
Manual creation bypasses Stages 1–3 — a first-class fast path, not a fallback. A TA or ops associate can create a task directly — typing into the New Task modal, or hovering a message and clicking "create task." The keyboard shortcut (see §7.2 Operator essentials) is always available, even when suggestions are firing — TAs who need to create a task NOW must never be forced through the suggestion pipeline. Manual creation skips Signal / Suggestion / Approval gate and lands the task directly in Canonical. Per §7.2, the manual-create UI surfaces ≤ 2 fields (title + owner); everything else is inferred from context.
Agent mode is a hybrid. When a TA prompts the agent ("research connecting rooms at the Aman Tokyo"), the agent's run may spawn AI sub-tasks and human sub-tasks. AI sub-tasks travel the full 4-stage flow inside the agent run; human sub-tasks emerge as direct Canonical tasks routed to the appropriate operator.
AI-suggested replies are tasks too. When the AI proposes a reply to a client message (e.g. the TA is away from their computer and a customer has messaged), that proposal travels the same 4-stage flow. TA approves inline ("yes"), the action (send the message) fires immediately, the canonical task is created and auto-closed in the same step. The whole interaction takes one click. Keeping this in the task model rather than as a separate "AI suggestion" feature: the audit trail (who approved sending which message) lives in one canonical record.
Management
Once approved, tasks live on the task board:
- • One filterable list across all clients — AI tasks and human tasks share the same surface, distinguished by routing tier badge rather than by separation
- • Ownership: one primary, many watchers. Each task has exactly one primary owner — accountable for closure. Other people can be added as watchers for visibility / collaboration; they see the task on their personal list but don't share accountability. Single ownership keeps responsibility unambiguous.
- • Filters: status, priority, origin bucket, routing tier, owner, source
- • Default views per role (open question — see §8: TA dashboard ≠ ops dashboard)
- • Bulk operations: assign, reassign, complete, dismiss
- • Inline AI assistant accepts natural-language queries: "show me overdue", "what should I work on first", "give me an end-of-day summary"
Surface model: in-context approval is primary, Review queue is the catch-up surface
Most approvals happen in-context, where the operator is already working: TA messaging a client and AI proposes a follow-up reply (Claude-style "yes, yes, yes" inline approval); TA on a trip page and AI suggests a hotel re-shop after a vendor change; TA prompts the agent and approves both AI sub-tasks + human sub-tasks within the agent run; TA on a member page and AI suggests scheduling a call to capture credit-card details.
- Main task board: approved, executable tasks. Stays clean and trusted, never shows unapproved suggestions.
- Review queue: secondary catch-up surface for suggestions the operator didn't see (or didn't act on) in context. Filterable by trip, member, type, age. Used for batch-approve / batch-dismiss when clearing backlog.
Risk to manage in implementation: the review queue can become a dead inbox if it accumulates faster than operators clear it. Mitigations: silent expiry on stale suggestions, batch operations, in-context approval as the dominant flow. Placement and expiry policy details are open in §8 q11.
Operator essentials (day 1)
The TA-side experience requires these from CC v1's baseline forward:
- • Keyboard shortcuts —
ccreate,eassign,j/knavigate,xdismiss,Escclose - • Batch-close — multi-select with a confirm step before commit
- • Snooze — "not now, remind me in 2h" / "remind me end of shift"
- • Mute signal for this trip — TA already handled the weather alert; don't re-fire on the next monitor sweep
- • Undo on dismissal — 10-second window before the dismissal commits (caught misclick / hot-key slip)
- • End-of-shift handoff view — my open tasks + owner-context, one click → hand off to the next shift
- • Manual create now — keyboard shortcut available even when suggestions are firing; see §7.1 for the bypass path
These are not optional features — CC v1 has most of them, and v1 of Conductor can't be worse without breaking operator trust.
Canonical task fields (data layer — not the manual-create UI)
Once approved, a task is a single record with 29 fields. Different surfaces (board, trip page, account page, agent mode) render this same record differently — the task_type field drives which fields are visible per surface. Fields: id, title, action, actor, when, primary_owner, watchers, status, approval_state, confidence_score, primary_context, origin, task_type, subtype, creator, creation_surface, routing_tier, priority, due_at, rationale, evidence_refs, created_at, updated_at, snooze_until, dismissal_reason, reopen_count, last_reopened_at, parent_task_id, agent_run_id. Status enum: pending / in_progress / blocked / snoozed / done / dismissed. Priority enum: High / Normal / Low. Activity log is a separate entity (per-task append-only) capturing every state transition; not denormalised onto this record.
UI constraint: manual creation surfaces ≤ 2 fields. When a TA or ops associate creates a task manually, they see only title and (optionally) owner. Everything else is inferred from context or filled with defaults. Schema-for-system, not schema-for-hand-entry — preserves CC v1's 2-second task creation speed.
Full field table and worked examples of populated records are in Appendix D.
Closure
A task leaves the system in one of four ways:
A human marks it done. Always available, lowest trust bar.
For auto-tier tasks the AI fully executed. The AI knows it's done because it did it.
AI detects evidence of completion (a confirmation arrived, the conversation moved past the issue) and surfaces a "close this?" prompt for a one-click human ACK.
A human closes the task without completion, with a reason captured for audit. Distinct from "completed."
Audit: Every state change writes to an activity log. Reopening is supported. For high-stakes tasks (VVIP, large bookings) we may need a "soft-closed" intermediate state — see §8.
Explainability
Every AI-suggested or AI-auto-approved task surfaces why it exists and what evidence triggered it — at a glance, not buried.
- Rationale One line, plain English. "Client message mentioned dietary preference." / "Flight SQ232 delayed 4 hrs." / "SLA timer < 30 min to breach." Length cap is intentional: multi-paragraph LLM justifications get skipped.
- Evidence One link (or two, max) to the source signal: the message, the alert, the query result, the prior task. Full audit trail lives in the activity log on demand.
- Manual tasks Rationale is optional. If a TA created it manually they know why; the field is open if they want others to.
Constraint: one line + one link. Walls of text go banner-blind faster than no rationale at all.