← knowledge.oriz.in

Ticketing primitive — agent operations visible via TaskCreate

rule agenttasksvisibilityticketingorchestration

Ticketing primitive

The rule

Every non-trivial agent operation lands in a task. Not just as a mental model — the actual TaskCreate / TaskUpdate tool must fire so the user sees what's happening.

When ticketing is required

Trigger Task required?
3+ step operation Yes
Any external-state operation (per draft-not-send) Yes
Multi-file refactor Yes
Multi-repo sweep Yes (one task per repo, or one task with subtasks)
Background subagent spawn Yes (task per subagent)
Single-file edit with clear instruction Skip
Reading a file to answer a question Skip
Conversational turn Skip

Task lifecycle

  1. Before starting: TaskCreate with subject, description, activeForm.
  2. On start: TaskUpdatein_progress.
  3. On external state changes: mid-task TaskUpdate if scope shifts materially.
  4. On complete: TaskUpdatecompleted — but ONLY if the work is truly done + verified. Partial credit = keep it in_progress.
  5. On block: TaskCreate a new task describing the blocker; keep original in_progress.

Anti-patterns

Why this matters

Per own-memory-rent-intelligence, your memory + orchestration belong to you. Tasks ARE the orchestration record — they're what makes agent work reviewable, resumable, and portable across sessions.

Ticket = "the receipt for this action". No ticket = no accountability. Especially critical for background subagents and long-running sweeps where the main agent may look busy but you can't see individual step status.

Cross-agent parity

All 6 fleet agents (Claude Code + ZCode + OpenCode + Kilo Code + Antigravity + MiMoCode) need a task system OR must document explicitly why they can't. Currently:

Agent Task tool
Claude Code Native TaskCreate / TaskUpdate / TaskList
OpenCode Native task tool
Kilo Code VS Code extension task view
Antigravity Native
ZCode Unknown — verify next session
MiMoCode Unknown — verify next session

Cross-refs