CONCEPT Cited by 2 sources

Investigation-phase progression¶

Definition¶

Investigation-phase progression is the architectural discipline of modelling a long-running agent loop as a sequence of named phases (e.g. discovery → trace → conclude) with a distinguished meta-phase responsible for deciding phase transitions. Phase is carried as application state, not prompt state; each phase has its own model- parameter envelope (model tier, token budget, tool surface, output schema).

The pattern is the multi-agent-investigation sibling of the classical deterministic state machine for lifecycle pattern — it treats the investigation itself as a stateful resource with a well-defined lifecycle.

Named and canonicalised in Slack's Streamlining security investigations with agents post (Source: sources/2025-12-01-slack-streamlining-security-investigations-with-agents).

Slack's three-phase model (Spear)¶

Phase	Behaviour	Director's task
Discovery	Broadcast a single question to all Experts	Ensure every data source is examined
Director Decision (meta-phase)	No experts queried; Director decides phase transition	Advance or remain
Trace	Direct question to one specific Expert; Director may vary model parameters or token budget	Focus on the Experts who produced relevant findings
Conclude	Produce the final report	End the investigation

Slack verbatim: "Investigations begin in the discovery phase. After each round of investigation the Director decides whether to remain in the current phase or to progress to a new phase."

And: "We also have the flexibility to vary the model invocation parameters by phase, allowing us to use a different model or enhanced token budget." (Source: sources/2025-12-01-slack-streamlining-security-investigations-with-agents)

Why phases exist¶

1. To decouple control-flow from prompts¶

Single-prompt agents that try to encode multi-step methodologies in text ("First explore broadly, then focus on the most promising leads, then conclude") routinely violate their own instructions. See concepts/prompt-is-not-control. Phases move the control- flow out of the prompt and into application state, where transitions are explicit.

2. To enable per-phase parameter envelopes¶

Different investigation stages have different cost/quality profiles. Discovery benefits from broadcast (every Expert gets the question) and cheap models (the point is breadth). Trace benefits from selection (pick the Expert who already produced useful findings) and possibly deeper reasoning or larger token budgets. Without phases, all rounds look the same.

3. To make termination decidable¶

A single-prompt agent's "conclude when sufficient information has been gathered" is vague; the agent decides internally, and the loop can run forever or conclude too early. Phases externalise termination into the Director's Director-Decision meta-phase, which is an explicit, inspectable, debuggable decision.

4. To support replay + debugging¶

Phase transitions are first-class events in the investigation's event stream, consumable by a dashboard (see patterns/hub-worker-dashboard-agent-service). Reviewing an investigation's phase-transition history is the fastest way to understand "what did the Director decide and why".

The meta-phase (Director Decision)¶

The meta-phase is architecturally load-bearing. Without it, phase transitions would have to be embedded in other phases' prompts, reintroducing the prompt-is-control failure mode. The meta-phase is:

Separately invoked — its own model call with its own schema.
Advice-carrying — "The task's prompt includes advice on when to advance to each phase." (Source: sources/2025-12-01-slack-streamlining-security-investigations-with-agents)
Director-only — Experts and Critic don't see phase- advancement decisions.

Generalisation beyond security investigation¶

The pattern applies to any long-running agent loop with naturally distinct stages:

Research agents: ideation → retrieval → synthesis → draft.
Code review: scan → deep-review → consolidation → ship.
Data-quality audit: discovery (what columns exist?) → profiling (what distributions?) → anomaly-trace → report.
Incident response: initial-triage → evidence-gathering → root-cause → remediation → post-mortem.
Customer-support triage: classify → gather → propose → confirm.

The common shape: a broadly exploratory opening, a focus → depth middle, and a close — with meta-phase transitions made explicit.

Contrasts¶

vs. concepts/deterministic-state-machine-for-lifecycle — classical state machine is fully specified (all states, all events, total transition function). Investigation-phase progression is semi-formal: phases are enumerated but transition logic is delegated to an LLM-backed meta-phase agent advised by prompt text. The rigour is "phases as first-class application state" rather than "formally verified transition function."
vs. a single ReAct loop — ReAct mixes planning and execution in a single loop. Phase progression separates "decide the phase" from "execute within the phase," which maps more cleanly to the knowledge-pyramid cost structure (phase decisions are apex-tier; in-phase work is leaf-tier).
vs. workflow engines — workflow engines like Temporal pre-declare the DAG. Phase progression is closer but not identical: the transition is runtime-chosen by an agent, not statically declared. It sits between a pure workflow DAG and a freeform agent loop.

Operational properties¶

Phase is in the event stream — every phase transition is a logged event. Dashboard consumers can filter by phase, trace back how long each phase took, and correlate phase duration with investigation quality.
Phase is in the state store — if a worker dies mid- investigation, the replacement worker resumes at the last known phase.
Per-phase prompts are small — because phase is application state, the phase-specific prompt doesn't have to explain all phases and their transitions; it just encodes what to do in this phase. This is a direct win on context- window utilisation (see concepts/context-engineering).

Caveats¶

Phase count is a design choice. Slack uses three phases
one meta-phase; a simpler problem might need two; a complex one might need more. No canonical number.
Transition logic is a prompt. The meta-phase's transition decisions are made by an LLM, not a formally verified function. Mis-timing a transition (premature conclude, infinite discovery) remains a failure mode.
Phase ≠ rigid. Slack says "at the moment, we have three phases, but it is simple to add more" — the architecture is designed for phase evolution, not locked-in phase sets.

Seen in¶

systems/slack-spear — canonical first wiki instance. Three phases (discovery, trace, conclude) + one meta-phase (Director Decision). Each phase supports per-phase model parameters + token budgets. Phase advancement is the Director's responsibility. (Source: sources/2025-12-01-slack-streamlining-security-investigations-with-agents) Second post adds: phase is tracked inside the Director's Journal — each Journal entry is auto-annotated with phase
round + timestamp, making phase-progression visible in the reasoning state as well as in the event stream. Journal entries of type action and decision frequently reference phase-transition decisions (e.g. "advance to conclude"). (Source: sources/2026-04-13-slack-managing-context-in-long-run-agentic-applications)