Delegation Run Protocol

Purpose: Define how delegated agents and personas report progress, blockers, decisions, completion, and follow-up work. The protocol exists to prevent users from having to ask "is this still running?" during delegated work.

Scope: Agent/persona delegation through Slack, Linear, Codex, or Pantheon automation. This is an operating protocol, not an implementation change.

Problem

Recent HAN-299/HAN-302 work showed a recurring gap:

Work can pause at a user-decision point without a clear state transition.
Candidate follow-up work can remain in a document without clear Linear ticket creation status.
Slack, Linear, and documents can show different levels of progress.
The user may need to ask for status before the agent reports that it is blocked.

The issue is not that agents fail to work. The issue is that delegated work needs a standard run protocol.

Status Model

Status	Meaning	Required report
`accepted`	Agent accepted the task	Scope, intended output, first check
`investigating`	Agent is reading or analyzing	What is being checked
`decision_required`	Agent cannot proceed safely	Blocker, options, recommendation, impact
`executing`	Agent is making the agreed change	Current action and expected artifact
`long_running`	Work exceeds the expected silent window	Current progress, next checkpoint
`completed`	Requested work is done	Output links, verification, remaining risk
`follow_up_required`	Work produced separate follow-up items	Ticket status: created, not created, or intentionally deferred

Reporting Rules

Start

When taking a delegated task, report:

The concrete goal.
The expected artifact.
The first thing being checked.

Example:

Taking HAN-302. I will remove wrap-up review remnants only, verify there is no R&R change hidden in the diff, and report any out-of-scope alert ownership questions separately.

Investigation

During investigation, report only material findings:

Relevant file, ticket, or thread found.
Scope boundary discovered.
Risk that changes the plan.

Avoid progress messages that only say work is continuing.

User Decision Required

If work stops because a decision is required, the agent must report in this shape:

Field	Required content
Blocker	Why progress stopped
Options	2-3 viable choices
Recommendation	One preferred choice
Scope impact	Whether the choice stays in the current ticket or needs a follow-up
Default if no response	What the agent will do if the user does not decide

Template:

Decision required. Blocker: ... Options: 1. ... 2. ... Recommendation: ... Scope impact: ...

Default if no response: ...

Long-Running Work

If work continues beyond 10 minutes without a visible artifact or beyond the last stated checkpoint, report:

Current status.
What has been completed.
What remains.
Whether the agent is blocked.

This applies especially to Slack-driven delegation, where the user does not see local terminal activity.

Completion

Completion reports must include:

What changed.
Where the artifact is.
What was verified.
What remains out of scope.
Whether follow-up tickets were created.

Example:

HAN-302 complete. Removed #sessions dead code only. _post_anomaly_alert was left unchanged because it is an alert R&R question, not wrap-up residue. Follow-up ticket HAN-310 covers that decision.

Follow-Up Ticket Rule

When work produces follow-up items, the agent must distinguish:

State	Meaning
`created`	Linear ticket exists and is linked
`candidate_only`	Listed in a document but not created
`deferred`	Intentionally not created, with reason

The phrase "follow-up tickets" should not be used unless Linear tickets were actually created.

Slack / Linear / Document Consistency

Slack is the live status channel.
Linear is the source of truth for committed work items.
Documents are analysis artifacts and may contain candidates.

When these differ, the agent must say so explicitly.

Example:

F1-F5 are candidates in the inventory document only. They are not Linear tickets yet.

HAN-300 Summary

Delegation requires a standard run protocol. Each delegated agent/persona must make state transitions visible, report decision blockers with options and a recommendation, and distinguish documented follow-up candidates from created Linear tickets. This protocol should be incorporated into the Agent/Persona Operating Model.