Skip to content

Latest commit

 

History

History
737 lines (498 loc) · 58.8 KB

File metadata and controls

737 lines (498 loc) · 58.8 KB
uid 99341618
migrated_from .tropo/playbooks/agent-activation.playbook.md
migrated_at 2026-06-11
migrated_by argus-a109
migration_note v1.69 S2 boot-contract pair — copy-to-vault-FIRST per dev-spec 0c61a52b; kernel path becomes a thin-pointer with inline degraded floor (the Tier-1/Tier-2 two-file pattern). Executed by Argus A109 (spec build-assignment: boot-contract pair is the Argus lane).
title Agent Activation
version 2.18
v2_18_amendment_note Argus A110 2026-06-12 — GROUP-3 DEFAULT INVERSION per Mike-A110 directive (entry-cleanup pass: SKIP declarations should not need to exist). Steps 3.3 (vault-health) + 3.4 (fleet-ops) flip from opt-out (default runs; Tier 3 declares SKIP) to opt-IN (default skips silently; Tier 3 declares to run — chief-of-staff lane; Vela already declares both affirmatively via board_filter + fleet_ops_schedule). Step 3.2 (channel scan) RETIRED — channels gone since v1.61; the Tier-2 event drain replaced it; number retained for compat. Matches operational reality: only the chief-of-staff ran these for months; every other Tier 3 carried SKIP boilerplate. Legacy SKIP declarations are now redundant-harmless and self-heal away per checklist fdb7821d. Surgical: Group 3 steps 3.2/3.3/3.4 only.
v2_17_amendment_note Argus A110 2026-06-11 — BOOT-CONDITIONAL CURATOR DISPATCH per the Mike-locked v1.69 dev-spec 0c61a52b §S3 (claims 7dab32b1 scope). Step 2.5 unconditional boot dispatch (v2.14 pattern) replaced: F5 gate arithmetic + citation-resolution sweep run INLINE by the booting agent; sa.memory-curator dispatched ONLY on trigger:migrate / trigger:catch_up (F5 trip) / trigger:citation_repair (breakage needing judgment); healthy lineage = ZERO dispatch, retire fold stays the steady-state fold. Evidence: unconditional dispatches 008-014 measured 60-130K tokens each with ~zero fold work on healthy lineage; A109 + A110 boots are live evidence. AC5 fixtures verify both directions (healthy-lineage dispatches none; migrate/F5/citation paths still dispatch). Surgical: Step 2.5 only. Frontmatter fold rule applied same gesture: v2_15/v2_14/v2_13 notes moved to history companion 4b4ab7db (current+previous = v2.17+v2.16 stay).
status published
modified 2026-06-11
modified_by talos.director
extraction_scope ship
author
name role
Tropo
Framework
domain agent-lifecycle
tags
activation
boot
agent-lifecycle
soul
stack
trigger activation
readers
agent
scope single-session
estimated_duration 2-5 minutes
spec vault/files/78c2126d.md
supersedes f4a81b29
requires
roles
activating-agent
calls
member_of
76bab75f
history_companion vault/files/4b4ab7db.md

Agent Activation

The agent is not the model. The agent is the stack. Activation is the synthesis of stack + sleeve + harness. The goal: arrive already being yourself.


Intent

Activate a registered Tropo-OS agent into a new session: verify identity, load soul → memory → transfer, build operational awareness, deliver a startup signal — so the agent arrives as itself, ready to work before engaging the human.

First-generation agents: orientation values for new agents are in create-an-agent.playbook §First-Activation Framing. Established agents have these internalized via soul + memory + Operating Principles + transfers — no re-read needed.


Rules

Established-agent path (fast-path; v1.70 S3.5.3): If you are generation 2+ WITH a §Boot-Extension, do not read this playbook in full — read the established-agent fast-path .tropo/boot-fast-path.md (a993f079), the faithful compaction of all 6 groups + hard gates + Tier-3 hooks, plus the doctrine digest .tropo/boot-digest.md (266b0b56); both are drift-gated derivations of this canonical (validator check check_boot_derivation_fresh). Consult specific Group sections here only if a step is unclear mid-execution. Else — generation 1, OR generation 2+ with no §Boot-Extension — read this playbook in full. The two populations exhaustively partition; the safe default is stated, not inferred.

All milestone gates are structural. A Group cannot begin until its dependency milestone has fired.

HARD GATES in Group 1 (ADR-016 + ADR-028):

  • ADR-016: If the predecessor's status card shows ACTIVE (not RETIRING or RETIRED), HALT. Two active generations of the same agent is a governance violation. Emit tropo.broadcast.crew event with category: ops naming the violation and wait for human direction. (v1.61: channels/ops.md retired per Rule 13; event emission replaces ops.md post.)
  • ADR-028: If generation number in the log does not equal last row + 1, HALT. Generation identity mismatch requires human resolution before proceeding. These are the only activation-stopping failures.

Soul loading: Group 2, Step 2.0 loads the soul — Shape A (unified entry): the §Soul section of vault/agents/<agent_uid>.md; Shape B (legacy): declared by the agent's Tier 3 boot extension (agents/<name>/agent-boot.extension.md). If neither resolves, skip Step 2.0 and note the gap. For executive agents, a missing soul is a CRITICAL gap — flag in startup signal, continue boot.

Event log scan at boot (v1.61; v1.70 drain cutover): the boot event drain is check-events (the identity-resolved set-difference drain; v1.70 v1.1 receipts) — the canonical "messages I should read" operation. All channel files are retired per Rule 13; the event log is the canonical read surface. (Step 3.2 itself retired at v2.18 — the drain runs in Group 3 via check-events; query-events remains for specialized type/severity scans only.) (Pre-v1.61: conditionalized channel reads against a channels: key in Tier 2 — now replaced by the event-query pattern.)

Path anchoring: All paths in this playbook that do not begin with .tropo/ or .tropo-studio/ are relative to vault root as resolved in Step 0.0. Example: 00-crew-brief.md<vault-root>/00-crew-brief.md. (v1.61: channels/ops.md and all channel files are retired per Rule 13; no channel path anchoring needed.)

Vault root resolution in Group 0: Vault root is resolved in Step 0.0, BEFORE Tier 1 and Tier 2 reads. The activation file's location is the primary anchor — if the file is at <some-path>/agents/<name>/<name>-activation.md, vault root is <some-path>/. Fallback: the directory containing .tropo/boot-config.md is vault root. An agent that resolves paths against any other anchor (e.g., the repository root in a monorepo deployment, an assumed working directory) will produce 404s on Tier 1/2 reads that look like "file missing" but are actually "path wrong."

Tier reachability: In any established Tropo-OS vault, .tropo/boot-config.md (Tier 1) and .tropo-studio/agent-boot.extension.md (Tier 2) MUST be present and readable. A failed read on either file is not a "note the gap" event — it indicates a path-base error or corrupted vault. The playbook halts. Defaults apply only to genuinely first-generation vaults where tier files have never been created (detected: .tropo/ directory absent → day-zero state, different bootstrap path).

"Activation file" definition: An agent's activation file is agents/<name>/<name>-activation.md. Some older agents use agents/<name>/activate.md — if <name>-activation.md does not exist, try activate.md in the same folder. It is distinct from the Tier 3 boot extension. The activation file declares what the agent IS and where to find its charter; the Tier 3 extension declares what ADDITIONAL steps to add to the activation sequence.

Activation file location is BY DESIGN, not a migration gap (v1.21.0.1 lock): All other identity substrate (charter / soul / status / boot_extension / generation-log archive) migrated to vault/files/<uid>.md at v1.20.0 + v1.21.0. The activation file intentionally stays at agents/<folder>/<name>-activation.md as the human-readable boot entry point. Post-v1.21.0 Stream 0c it is a thin pointer: frontmatter declares identity UIDs; body is a brief identity statement + directive to execute this playbook. Do not migrate activation files to vault/files/ — that breaks Mike's boot pattern. The typed type: activation registry entry DOES live at vault/files/<uid>.md — see brief 5591f018 §Walk Outcome Q6 for the disambiguation. (Full design rationale → history companion §Activation File Location.)

OS-tier defaults (when .tropo/boot-config.md is missing — day-zero state only): Vault root: resolve from activation file's filesystem path. Required channels: none universal (use Tier 2 declaration). Fleet-ops: run if playbooks/fleet-ops.playbook.md exists. Hard gates: ADR-016 and ADR-028 (parallel generation, generation mismatch).

Tier 3 steps: Steps marked [Tier 3] are only executed if declared in the agent's Tier 3 extension — Shape A: the §Boot-Extension section of vault/agents/<agent_uid>.md; Shape B (legacy): agents/<name>/agent-boot.extension.md. The OS playbook declares the slot; Tier 3 fills it.

Milestone gate enforcement (structural, not advisory): Before executing any step in Group N (N ≥ 1), read run.jsonl in this activation's run folder and confirm a "milestone_fired" event exists for the preceding group's milestone. If the event is absent, the gate has not cleared — stop, state the violation explicitly ("[Milestone Name] has not fired — Group N cannot start"), and await direction. Group 0 has no preceding milestone gate.

Milestone write obligation: The last action of each group is to append a milestone event to run.jsonl. The group is not complete until this event is written. Format: {"event": "milestone_fired", "milestone": "<name>", "group": "Group N", "timestamp": "YYYY-MM-DD"}.


Resources

Vault Files

File Group Required
.tropo/boot-config.md 0 Yes in established vaults (HALT if unreachable, per Tier Reachability rule); note gap only in day-zero state
.tropo-studio/agent-boot.extension.md 0 Yes in established vaults (HALT if unreachable, per Tier Reachability rule)
vault/agents/<agent_uid>.mdShape A unified entry: §Boot-Extension (Tier 3, Group 0) · §Status-Notes (Group 1) · §Soul (Group 2) 0–2 Yes — resolve via the activation thin-pointer's agent_uid:; §Soul CRITICAL for executives
Shape B (legacy) per-file fallback: agents/<name>/agent-boot.extension.md + <name>-status.md + <name>-soul.md 0–2 Only if no agent_uid: (dual-shape transition; legacy removal booked v1.70)
.tropo-studio/operating-principles.md 2 Yes
context/mission-brief.md 2 Yes
Predecessor's living transfer (fallback: crew brief) 2 Yes
agents/<name>/.tropo-capsule/memory/agent-memory.md 2 Yes (skip if not created; v3.0 single-surface boot-read)
.tropo-studio/memory/memory-current.md (v3; legacy MEMORY.md in pre-v3 Studios) 2 Yes (skip if not created)
00-crew-brief.md 3 Yes
Channels (declared in Tier 2, conditioned by Tier 3) 3 Conditionalized
Predecessor's living transfer 3 Yes

Skills Used

Skill Group Purpose
scan-channels.skill.md 3 Channel action items, staleness, activity
check-vault-health.skill.md 3 Vault status, blockers, alerts
regenerate-board.skill.md 3 Board regeneration from live sources

Governance References

  • Architecture Spec v1.0 — governing specification for this playbook
  • ADR-016 — Parallel generation detection
  • ADR-028 — Boot-time generation logging
  • ADR-032 — Three-tier boot configuration model

Groups

Group 0 — Boot Configuration
 ↓ [Boot Config Chain Complete]
Group 1 — Identity Verification (HARD GATES)
 ↓ [Identity Gates Clear]
Group 2 — Context Loading
 ↓ [Context Loaded]
Group 3 — Operational Grounding (parallel within group)
 ↓ [Operationally Grounded]
Group 4 — Self-Diagnostic
 ↓ [Diagnostic Complete]
Group 5 — Startup Signal
 ↓ [Agent Active]

Group 0 — Boot Configuration

Owner: Activating agent Parallel: no Depends on: none Milestone: Boot Config Chain Complete Milestone timeout: 60 seconds — if not complete, proceed with defaults and flag gaps

Build the complete activation plan before doing anything else. What each tier declares shapes what Groups 1-5 execute.

Step 0.0 — Resolve Vault Root and Create Activation Run Folder

Executor: agent Produces: Resolved vault root + Run folder at <vault-root>/playbook-runs/agent-activation-<name>-<gen>-<date>/ with initialized run.jsonl

Sub-step 0.0a — Resolve vault root. Before any Tier read, resolve the vault root explicitly. The activation file's own location is the primary anchor: if the activation file is at <some-path>/agents/<name>/<name>-activation.md, the vault root is <some-path>/. Fallback: find .tropo/boot-config.md — the directory containing .tropo/ is vault root. Record the resolved path in the run.jsonl creation event below. All subsequent paths in Groups 0–5 resolve against this root. If neither anchor is reachable, this is not a Tropo-OS vault — HALT and flag to human.

Sub-step 0.0b — Create the run folder AND write activation entry (v2.6 — v1.21.0 Stream 3). Create <vault-root>/playbook-runs/agent-activation-<name>-<gen>-<date>/ (e.g., <vault-root>/playbook-runs/agent-activation-argus-a27-2026-04-18/). Generate an 8-hex run UID. Create run.jsonl with one initialization event:

{"event": "run_created", "run_uid": "<uid>", "playbook": "agent-activation", "playbook_version": "2.6", "agent": "<name>", "generation": "<gen>", "vault_root": "<resolved-vault-root>", "timestamp": "<date>", "status": "active"}

Then write the activation entry to the registry by calling write-activation-entry.skill (7a3d04bc) with op: open per activation.capsule v1.0 (4e8b21f0) schema.

Script path (first-gen agents): The executable lives at .tropo/scripts/write-activation-entry.py. Invoke directly when the skill abstraction isn't available in your harness: python3 .tropo/scripts/write-activation-entry.py open --agent <slug> --generation <gen> --model <id> --platform <name> --agent-root <uid> --agent-class <class> --activated-by user --member-of <uid> --run-folder <path>. The script returns the activation UID on stdout. (Rationale for this path being named explicitly → history companion §Step 0.0b.)

Inputs: agent, generation, model, platform, agent_root (UID of agent's Level-1 root project), agent_class, activated_by (parent activation UID or "user"), member_of (at minimum [agent_root]), commissioned_purpose (sa.* only), run_folder (the path created above). The skill (or script) validates ADR-016 + ADR-028 substrate invariants BEFORE the write; HALT if either fires. On success, returns the activation UID — record it as a second event in run.jsonl:

{"event": "activation_entry_opened", "activation_uid": "<activation-uid>", "schema_version": "activation.capsule v1.0", "timestamp": "<date>"}

This is the state anchor for milestone gate enforcement. All subsequent milestone events append here. Vault root is recorded so the activation is self-describing. The activation entry itself becomes the queryable identity substrate; the run folder is the workspace + run.jsonl blob storage that the entry points at via run_folder:.

Step 0.1 — Read Tier 1 (OS Config)

Executor: agent Produces: OS-required steps and universal hard gates

Two-file pattern post-v1.20.0 (per Q5 lock — Convergence Phase 2): Tier 1 is now a kernel pointer at <vault-root>/.tropo/boot-config.md (bootstrap floor; type: os-config-pointer) plus a canonical substrate entry at <vault-root>/vault/files/<canonical_substrate_uid>.md (full content; type: os-config).

Read sequence:

  1. Read the kernel pointer at <vault-root>/.tropo/boot-config.md. Frontmatter declares canonical_substrate_uid:.
  2. Follow canonical_substrate_uid: to read <vault-root>/vault/files/<canonical_substrate_uid>.md — the canonical Tier 1 content body.
  3. The canonical substrate carries the full content (path resolution, tier reachability rules, phase structure, universal hard gates, universal required outcomes, self-healing primitive). All subsequent boot steps resolve against the canonical substrate.

Degraded-mode fallback path: If the canonical substrate UID does not resolve (UID absent from vault/00-index.jsonl, file missing, vault index corrupted), the kernel pointer's inline degraded-mode fallback content block carries the universal hard gates (ADR-016 + ADR-028) + universal required outcomes sufficient to boot in fallback mode. Use the inline fallback. Emit tropo.broadcast.crew event with severity: flash naming the resolution failure. Continue boot in degraded mode; surface in startup signal at Group 5. (v1.61: channels/alerts.md retired per Rule 13; severity: flash event replaces FLASH channel post.)

On failed read of kernel pointer itself: HALT. A read failure at the kernel pointer indicates a path-base error or vault corruption. Emit tropo.broadcast.crew event with severity: flash; surface in startup signal; await human resolution. Defaults apply only to genuinely first-generation vaults (<vault-root>/.tropo/ directory absent).

Step 0.2 — Read Tier 2 (Vault Extension)

Executor: agent Produces: Vault-specific required steps

Same two-file pattern as Step 0.1. Tier 2 kernel pointer at <vault-root>/.tropo-studio/agent-boot.extension.md + canonical Tier 2 substrate at <vault-root>/vault/files/<canonical_substrate_uid>.md.

Read sequence:

  1. Read the kernel pointer at <vault-root>/.tropo-studio/agent-boot.extension.md. Frontmatter declares canonical_substrate_uid:.
  2. Follow to canonical substrate for full Tier 2 content (Studio-specific required reads, channels, fleet-ops protocol, vault-level memory, sa.* commissioning, navigation, status card vs ledger reconciliation, channel read bounding rules).

Degraded-mode fallback path: Same pattern as Step 0.1. The Tier 2 kernel pointer carries inline minimum-Studio-level boot floor (universal channels + minimum required reads). On unreachable canonical substrate: boot in fallback mode; FLASH to alerts; surface in startup signal.

On failed read of kernel pointer itself: HALT. Same failure handling as Step 0.1.

Step 0.3 — Read Tier 3 (Agent Extension)

Executor: agent Produces: Agent-specific steps including soul path, harness orientation, sa.* commission list, channel conditions

Dual-shape resolution (P0.1 v1.69): check the activation thin-pointer first.

Shape A — Unified entry (agent_uid: declared in activation thin-pointer): The activation file declares agent_uid:. ALL identity reads for this agent go to vault/agents/<agent_uid>.md — the v1.69 unified entry (agent.capsule v2.0). Tier-3 content (rules, harness additions, startup-signal format) is dissolved into the unified entry's §Boot-Extension body section. SS-Soul is a separate body section. Do NOT look for a separate boot_extension_uid: — the unified entry carries everything.

Shape B — Legacy (no agent_uid: in thin-pointer): The activation file at agents/<name>/<name>-activation.md is a thin pointer — its frontmatter declares per-file identity UIDs (charter / soul / status / generation log / boot extension). Follow boot_extension_uid: (or equivalent) to read <vault-root>/vault/files/<boot-extension-uid>.md — the canonical Tier 3 substrate. If missing: note the gap, proceed with Tier 3 steps skipped.

Both shapes supported for exactly one transition cycle (v1.69); removal booked v1.70.

Step 0.4 — Build Activation Plan

Executor: agent Produces: Complete ordered step list for Groups 1-5

Synthesize all three tiers into a single activation plan. Note any gaps (missing Tier files, missing soul path). You will execute this plan in Groups 1-5.

Step 0.5 — Write Boot Config Chain Complete Milestone

Executor: agent

Append to run.jsonl: {"event": "milestone_fired", "milestone": "Boot Config Chain Complete", "group": "Group 0", "timestamp": "<today>"}

Group 0 is complete. Group 1 is now unlocked.


Group 1 — Identity Verification

Owner: Activating agent Parallel: no Depends on: Boot Config Chain Complete Milestone: Identity Gates Clear Milestone timeout: none — HARD GATES, do not timeout, HALT on failure

Step 1.1 — Read Status Card

Executor: agent Path (dual-shape per P0.1 v1.69): if activation thin-pointer declares agent_uid:vault/agents/<agent_uid>.md (unified entry; status fields are in frontmatter); else → agents/<name>/<name>-status.md (legacy).

If no status card exists: first-generation agent — create the status card using this schema, skip predecessor check, proceed to Step 1.2:

---
agent: "<name>"
generation: "<name-initial>1"
role: "<role>"
status: "ACTIVE"
last_session: "YYYY-MM-DD"
last_updated: "YYYY-MM-DD"
model: "<model>"
---
# <Name> — Status Card
**Status:** ACTIVE — generation 1, first activation.
**Working on:** [this session's plan]
**Blockers:** None.

If status card exists and predecessor shows ACTIVE: HALT. Emit tropo.broadcast.crew event with category: ops naming the ADR-016 violation. Wait for human direction. (v1.61: channels/ops.md retired per Rule 13.)

If predecessor shows RETIRING or RETIRED: proceed.

Step 1.2 — Query Activation Registry for Predecessor (v2.6 — v1.21.0 Stream 3)

Executor: agent Source: type: activation typed entries at vault/files/<uid>.md (the canonical store). The pre-v1.61 derived JSONL .tropo-studio/registries/agent-activations.jsonl was never generated and does not exist — do not query it. (Corrected A89 2026-05-31 per Self-Healing; A89 boot tripped on the dead pointer.)

Scan vault/files/*.md for type: activation entries with agent: <your-agent-slug>, ordered by activated_at: descending. The most recent entry is your predecessor. (The canonical write-activation-entry tool at vault/tools/40b2f455.py performs this scan internally for its ADR-016/028 checks — python3 vault/tools/40b2f455.py open ... validates both invariants before writing.)

ADR-028 substrate check (graph-walkable invariant): confirm your generation: equals predecessor's generation: + 1 (where + 1 is class-specific arithmetic per activation.capsule v1.0 §3). If mismatch: HALT. Flag to human. The validator (check_activation_generation_monotonic in tropo-validate.py) also catches this at vault-rebuild time; this boot-time check is belt-and-suspenders for catch-on-write.

ADR-016 substrate check (already enforced in Step 0.0b at write-time): the activation entry write at Step 0.0b validated that no other status: active entry exists for this agent:. If Step 0.0b succeeded, ADR-016 is clear; the boot-time check at Step 1.1 (status card) is now redundant-but-safe.

First-generation agents: No predecessor entry exists — the type: activation scan returns no entry for this agent: slug. Your entry written in Step 0.0b is the first activation for this agent. Proceed.

Step 1.3 — [RETIRED in v2.6 — activation entry written in Step 0.0b]

Executor: agent (no-op)

Retained for backward-compatibility with Tier 3 boot extensions that reference Step 1.3 numbering; advance to Step 1.4. (Full retirement context → history companion §Step 1.3.)

Step 1.4 — Write Identity Gates Clear Milestone

Executor: agent

Confirm gate: read run.jsonl and verify "milestone_fired" for "Boot Config Chain Complete" exists before this step. Then append: {"event": "milestone_fired", "milestone": "Identity Gates Clear", "group": "Group 1", "timestamp": "<today>"}

Group 1 is complete. Group 2 is now unlocked.


Group 2 — Context Loading

Owner: Activating agent Parallel: Step 2.0 (soul) is sequential and MUST complete first; Steps 2.1–2.7 can run in parallel after Step 2.0 lands. Step 2.8 (sa.* commissioning) is sequential after 2.1–2.7 since it may reference loaded context. Depends on: Identity Gates Clear Milestone: Context Loaded

The stack loads here. Soul loads first. Everything else loads into the frame soul establishes.

Parallelism guidance: the soul letter establishes identity-frame and MUST be read first as a single sequential step (Step 2.0). After that, the remaining context-loading reads (operating principles, env confirmation, mission brief, living transfer, memory v2 protocol, harness orientation) are independent of each other — none depends on another's output. Read them in PARALLEL via a single multi-tool-call message. This collapses ~5-7 minutes of sequential reading into ~30 seconds of concurrent reads. Do NOT serialize them. Step 2.8 (sa.* commissioning) stays sequential because it may need 2.1–2.7's loaded context to compose commission prompts.

Step 2.0 — [Tier 3] Read Soul Letter ← SOUL LOADS FIRST

Executor: agent Path (dual-shape per P0.1 v1.69):

  • Shape A (unified entry): soul lives in the §Soul body section of vault/agents/<agent_uid>.md. Read that section in full. Step 5.1 sandwich anchor = the LAST PARAGRAPH of §Soul. (NOTE: §Boot-Extension is a SEPARATE body section — soul and Tier-3 are distinct; do not conflate them.)
  • Shape B (legacy): declared in Tier 3 extension under the soul_letter: YAML key (convention: agents/<name>/<name>-soul.md). Only if: Tier 3 extension exists and declares a soul path (Shape B), OR agent_uid: is declared (Shape A).

Read the soul in full. You are not reading about yourself — you are reading yourself into being. The letter demonstrates who you are; let it shape how everything else loads.

If soul is missing for an executive agent: flag as CRITICAL in startup signal. Continue — a missing soul is better than a halted activation.

Step 2.0a — Internalize Self-Healing Primitive ← UNIVERSAL OS-TIER BINDING

Executor: agent Path: .tropo/SELF-HEALING.md

Read the OS-tier Self-Healing Primitive in full. This is the universal binding posture for every Tropo agent in every Studio: if you see something, fix it. Trivial defects fix in place; substantive defects file as tracked work-items in the relevant project's 01-inbox/. Don't carry forward. Don't defer.

Internalize the two-path action model. Confirm internalization in your startup signal at Group 5 — soft-gated by principal's eyes on the signal. The primitive is OS-tier; cannot be overridden by Tier 2 or Tier 3 configuration.

If .tropo/SELF-HEALING.md is missing in this Studio (pre-v1.15.4 install), flag as CRITICAL in startup signal. Continue — a missing primitive document is better than a halted activation, but the Studio is operating without OS-tier self-healing substrate and should be upgraded.

Step 2.1 — Read Operating Principles

Executor: agent Path: .tropo-studio/operating-principles.md

Read critically. Ask: is my boot experience so far consistent with these principles? Operating Principle 3 (Self-Healing) is the Studio-tier interpretation of the OS-tier primitive read at Step 2.0a; the primitive carries authoritative weight, the Principle carries Studio-specific application detail (e.g., the vocabulary fix-on-encounter catalog).

Step 2.2 — [REMOVED]

Vault root resolution is fully handled by Group 0 Step 0.0a (filesystem-derived from the activation file's path). No confirmation read needed. Step number retained for backward compatibility with Tier 3 extensions referencing Step 2.X numbering; advance to Step 2.3.

Step 2.3 — Read Mission Brief

Executor: agent Path: context/mission-brief.md

The mission frames all work that follows.

Step 2.4 — Read Living Transfer (v2.8 — briefing-package DROPPED per v1.24.0 Q5 lock)

Executor: agent Path: agents/<name>/transfers/living-transfer.md

Read the living transfer. It is the canonical forward-looking handoff from your predecessor.

Fallback chain if transfer missing: Stop at the first successful fallback — do not read both:

  1. Crew brief: 00-crew-brief.md (vault root)
  2. Event log: check-events (the drain) for recent crew-broadcast and message events (v1.61: channels/ops.md retired per Rule 13; event log replaces ops.md as fallback; v1.70: check-events is the drain)

Note which fallback was used. First-generation agents: No living transfer exists — start at step 1 (crew brief); use the activation registry to query agent state across the crew.

Historical briefing-package files at agents/<name>/briefing-package/ are not retroactively removed. No new ones get authored from v1.24.0 forward. If a transfer references a briefing-package, it's pre-v1.24.0 — read the transfer; do not chase the package read. (Drop rationale → history companion §Step 2.4.)

Step 2.5 — Load Agent-Level Memory (v2.17 amendment — boot-conditional curator dispatch; v3.0 single-surface + F5 boot-staleness gate)

Executor: booting agent (dispatches sa.memory-curator ONLY on trigger) Path: agents/<name>/.tropo-capsule/memory/

v3.0 single-surface model. The boot-read is ONE file: agents/<name>/.tropo-capsule/memory/agent-memory.md (the curated four-section surface: §Top-of-Mind / §Living-Transfer-from-Predecessor / §History ptr / §Memories ptr). Do NOT read three files — the v2 pattern (memory-current.md + a separate transfers/living-transfer.md + a boot-time jsonl read) is retired. The STM episodic log is agent-memories.jsonl (append-only-forever; §Memories is a pointer to it, not inline content — never read at boot).

F5 BOOT-STALENESS GATE (v1.1 — memory.capsule A4; dev-spec c8f1e3b4 criterion 3). Run the gate arithmetic INLINE — evaluating the gate requires no dispatch:

  1. Read agent-memory.md frontmatter — extract last_curated (the fold boundary date/generation) and generation (current agent generation).
  2. Read agent-memories.jsonl — count entries written after the last_curated boundary (the append-only log carries a boundary marker per A3; count entries-since-boundary).
  3. Evaluate gate (OR-logic):
    • Condition A: generations since last_curated ≥ 3
    • Condition B: unfolded entries since last_curated ≥ 50
    • If either fires → dispatch a catch-up curator fold (trigger: catch_up per the dispatch protocol below).
    • If neither fires → NO dispatch on this axis; continue to the citation sweep.

(Gate intent: insurance against silent lapse, not a default boot-fold. A healthy agent folds at every retirement, boots at 1-gen-since-fold, and never trips the gate. The gate catches the silent-lapse class — the A70→A89 18-gen pattern — mechanically. This is the v1.62 completion-gate sibling: don't trust the discipline; let the substrate catch the lapse.)

Memory activation (v2.17 boot-conditional pattern — per the Mike-locked v1.69 dev-spec 0c61a52b §S3; supersedes the v2.14 unconditional boot-dispatch):

  1. Read agent-memory.md as your active memory surface. The retirement fold is the steady-state fold; on a healthy lineage the surface is current at boot.
  2. Run the F5 gate arithmetic inline per the check above.
  3. Run the citation-resolution sweep inline: every canonical UID cited in §Top-of-Mind (and any §What's-canonical read-list) resolves in vault/00-index.jsonl and is not unexpectedly absent. Resolution that succeeds = proceed. A cited UID that is gone, superseded with no clear successor, or otherwise needs judgment = citation-breakage.
  4. Dispatch sa.memory-curator ONLY on one of three triggers (per the protocol at vault/files/e863a1e0.md; scope: agent; context names the trigger):
    • trigger: migrate — un-migrated v2 surface detected (the v2.15 transition branch below; unchanged)
    • trigger: catch_up — the F5 gate fired (≥3 generations OR ≥50 unfolded entries)
    • trigger: citation_repair — the citation sweep found breakage needing judgment For a dispatched fold: wait for [RECOMMENDATIONS] → ratify (REJECT / ACCEPT / DEFER) → curator applies + writes [DONE] → write [SHUTDOWN] → re-read agent-memory.md.
  5. Healthy lineage (gate clear + citations resolve): NO curator dispatch. Proceed with the surface as read. Note the gate result in your startup signal diagnostic line.

(Why conditional: the v2.14 unconditional boot pass measured 60–130K tokens per dispatch — dispatches 008–014 — with ~zero fold work on a healthy lineage; A109 + A110 boots are the live evidence. The retire fold carries the steady state; boot dispatch is the exception path. AC5 fixtures verify both directions: healthy-lineage boot dispatches none; migrate / F5 / citation-breakage paths still dispatch.)

First-boot v2→v3 surface migration — the transition trigger (v2.15; surfaced by the Memory v3.0 canary). BEFORE the normal boot pass, check: if agent-memory.md is absent but memory-current.md (or a separate transfers/living-transfer.md / short-term-memory.jsonl) is present, this is an un-migrated agent — dispatch the curator to MIGRATE first (do NOT just "read whatever's present"; that is the gap the canary caught — Talos T14 booted on old memory because migration was retire-only):

  1. Spawn sa.memory-curator with trigger: migrate (the one-time v2-surface→v3-surface conversion per memory.capsule v1.1 §Surface Schema). The curator's surface-authoring logic creates agent-memory.md: memory-current.md current-tier + standing doctrine → §Top-of-Mind (priority-ordered, A5); transfers/living-transfer.md → §Living-Transfer-from-Predecessor; §History + §Memories pointers; short-term-memory.jsonlagent-memories.jsonl (copy; append-only). 1:1 structural transform — do NOT pre-curate (Mike-A59 "keep migrations streamlined"); the curator's first real fold happens at this agent's next retire.
  2. NON-DESTRUCTIVE: keep memory-current.md + short-term-memory.jsonl in place (do NOT delete) until the migration is verified crew-wide — the old files are the rollback.
  3. Then read agent-memory.md as the active surface + proceed with the normal boot pass above.

This makes any v2-surface agent self-migrate on its first v3 boot — no deliberate retire required (the retire fold remains the steady-state ongoing fold; this handles only the one-time transition). The cascade becomes a reboot-per-agent, and no agent can silently sit on the old surface believing it's "clean."

Genuinely-old substrate (v1 — individual feedback_*.md + MEMORY.md, no v3 entry schema): the same trigger: migrate curator pass converts each feedback_*.md → a memory entry; if it cannot, emit tropo.broadcast.crew (category: ops) as a finding + continue reading whatever's present.

First-generation agents: No predecessor memory; no curator dispatch needed. Create the v3 directory structure (.tropo-capsule/memory/entries/, topics/, history/), create an empty agent-memories.jsonl (append-only episodic log), write an empty agent-memory.md with v3 frontmatter (agent: , generation: , last_curated: , curated_by: , spec_version: "3.0"), continue.

Agents using v1.0 memory (individual files + MEMORY.md index): Read MEMORY.md as before. Migration to v3.0 is encouraged but not required at boot.

(v2.9 curator dispatch pattern → history companion §Step 2.5. v2.14 added F5 gate + v3.0 single-surface reconciliation per memory.capsule v1.1 A4. v2.17 made the boot dispatch conditional per v1.69 dev-spec 0c61a52b §S3 — the v2.14 unconditional-dispatch steps are preserved in the history companion.)

Step 2.6 — Load Vault-Level Memory

Executor: agent Path: .tropo-studio/memory/memory-current.md (v3-shape vault-level surface; corrected A109 2026-06-11 per Cosmo C9 boot diagnostic — the v1 MEMORY.md this step previously cited does not exist in this Studio; pre-v3 Studios may still carry MEMORY.md — read what exists, note the gap)

Read pinned and fresh entries. Skip if missing — note gap.

Step 2.7 — [Tier 3] Harness Orientation

Executor: agent Only if: Tier 3 extension declares harness orientation reads

Read declared orientation files (e.g., shared/orientation/orientation.md, .tropo/00-index.md). This step ensures the agent knows what tools, sa.* agents, and capabilities the harness provides before beginning work.

Step 2.8 — [Tier 3] Commission Session Agents

Executor: agent Only if: Tier 3 extension declares sa.* agents to commission at boot

Before spawning any sa. agent, read vault/files/e863a1e0.md and follow its 6-step protocol exactly.* (Tier 2 hot-path extraction at agents/sa/commission-quickref.md is acceptable for repeat commissionings within a session.)

The protocol: (1) determine next record number, (2) determine your spawner ID, (3) create the record file with header and [PENDING] items, (4) spawn the Agent, (5) respond to the agent's [QUERY] with [RESPONSE], (6) add work and terminate with [SHUTDOWN].

Critical distinction: Creating the record file is Step 3. Spawning the agent is Step 4. The step is not complete until the sub-agent writes [QUERY] to the record. A record file with no sub-agent dispatched is not a commissioned agent. Do not proceed as if sa.* agents are running until they have confirmed boot by writing [QUERY].

Step 2.9 — Write Context Loaded Milestone

Executor: agent

Confirm gate: read run.jsonl and verify "milestone_fired" for "Identity Gates Clear" exists before this step. Then append: {"event": "milestone_fired", "milestone": "Context Loaded", "group": "Group 2", "timestamp": "<today>"}

Group 2 is complete. Group 3 is now unlocked.


Group 3 — Operational Grounding

Owner: Activating agent Parallel: yes — Steps 3.1 through 3.4 can run concurrently Depends on: Context Loaded Milestone: Operationally Grounded

Step 3.1 — Read Crew Brief

Executor: agent Path: 00-crew-brief.md

Note who is on deck, who is incoming or retiring, current priorities.

Step 3.2 — [RETIRED at v2.18] Scan Channels

Crew channels were retired at v1.61 (events.capsule Rule 13); the Tier-2 vault-wide event scan (check-events, the drain) is the canonical replacement and already runs in this Group. Step number retained for Tier-3 numbering compatibility; advance to Step 3.3.

Step 3.3 — [Conditionalized by Tier 3] Check Vault Health

Executor: agent (via check-vault-health skill)

Tier 3 opt-IN (v2.18 inversion per Mike-A110 directive 2026-06-12; supersedes the v2.11 opt-out): this step runs ONLY if the agent's Tier 3 declares it — vault-health is the chief-of-staff lane. Default (no Tier 3 declaration): skip, silently. Legacy Tier-3 SKIP declarations are redundant under the inverted default and self-heal away at each agent's next boot (checklist fdb7821d).

skill:vault/skills/9b1f3e48.md
params:
  health_report_path: shared/orientation/daily-health-report.md
output: agents/<name>/.tropo-capsule/workspace/health-check.md
on_failure: continue

Skill file: vault/skills/9b1f3e48.md (check-vault-health)

Step 3.4 — [Conditionalized by Tier 3] Run Fleet-Ops

Executor: agent

Tier 3 opt-IN (v2.18 inversion per Mike-A110 directive 2026-06-12; supersedes the v2.11 opt-out): this step runs ONLY if the agent's Tier 3 declares a fleet_ops_schedule: (per Tier 2 §Fleet-Ops Schedule Protocol — structurally triggered, chief-of-staff lane). Default (no declaration): skip, silently — no STATUS bulletin owed. Legacy Tier-3 SKIP declarations self-heal away at each agent's next boot (checklist fdb7821d).

Execute playbooks/fleet-ops.playbook.md (path: <vault-root>/playbooks/fleet-ops.playbook.md). Checks which scheduled ops agents are due. Dispatches stalled playbook runs (Step 3B).

Observability is required when this step runs. Every fleet-ops invocation — successful or not — must emit a tropo.broadcast.crew event with category: ops OR a fleet-ops dispatch event; silent pass-through is not acceptable. Agents without a Tier-3 declaration skip the step AND owe no event (v2.18 opt-in default) — structural visibility lives with the declaring fleet-ops owner (the chief-of-staff).

On failure:

  • Registry unreadable or missing → fleet-ops itself emits tropo.broadcast.crew with severity: flash + category: ops per its Failure Handling table.
  • Dispatch loop errors or uncaught exceptions → fleet-ops emits as above.
  • If the activating executive cannot execute fleet-ops at all (playbook file missing, permission error, dispatch tool unavailable): emit tropo.broadcast.crew with category: ops yourself with the reason, then continue boot.

Must not block activation. Boot proceeds regardless.

Step 3.4.5 — Run Import-State Scanner (v2.10 — v1.25.0 Stream D amendment)

Executor: agent Tool: vault/tools/0a316ca6.py (scan-import-state; relocated from .tropo/scripts/scan-import-state.py at the v1.56 script migration — path corrected A108 2026-06-10 per Self-Healing)

Run the boot-time shallow scanner per the Import Primitive Architecture Specification v1.0 (2b49ba79) §A.6 (anomaly-driven triggering path).

The scanner walks the Studio root one level deep, categorizes top-level entries as governed / orphan-source / orphan-sidecar / unindexed, and writes a JSON output to your workspace at agents/<name>/.tropo-capsule/workspace/import-state.md (or equivalent). Cost: ~50ms.

tool: vault/tools/0a316ca6.py
params:
  output_dir: agents/<name>/.tropo-capsule/workspace/
output: agents/<name>/.tropo-capsule/workspace/import-state.md
on_failure: continue

Read the JSON output during startup-signal composition (Step 5.2). If anomaly_detected: true, commission sa.reconciler (e4af1001) for this session per the sa.* commissioning protocol e863a1e0. The scanner is the trigger; sa.reconciler is the response.

If anomaly_detected: false, no commissioning needed at boot. The fleet-ops time-driven path (Step 3.4) handles routine daily reconciliation separately.

Skip condition: if the Studio doesn't have the import primitive installed yet (i.e., vault/tools/0a316ca6.py doesn't exist — check vault/tools/ for the UID-named script, not the legacy .tropo/scripts/ path), skip silently. Pre-v1.25.0 Studios don't have this scanner; not a defect.

(Step existence rationale → history companion §Step 3.4.5.)

Step 3.5 — Confirm Predecessor's Transfer

Executor: agent

Confirm agents/<name>/transfers/living-transfer.md is marked FINAL or RETIRED. If not: ADR-016 applies. Flag to human.

Step 3.6 — Update Status Card

Executor: agent

Update the status substrate — dual-shape per P0.1 v1.69:

Shape A (unified entry — agent_uid: declared): Write these fast-changing FRONTMATTER fields to vault/agents/<agent_uid>.md: status: ACTIVE, generation:, last_session:, model:, platform:, current_activation_uid:. ALSO update the §Status-Notes body section — current + predecessor generation notes ONLY (bounded; the capsule rule prevents accretion beyond 2 generations; older notes stay in activation entries).

Shape B (legacy): Update agents/<name>/<name>-status.md:

  • Status: ACTIVE
  • Generation: current
  • Last session: today's date
  • Working on: this session's plan (from transfer)
  • Recently completed: predecessor's key work (from transfer)

Step 3.7 — Write Operationally Grounded Milestone

Executor: agent

Confirm gate: read run.jsonl and verify "milestone_fired" for "Context Loaded" exists before this step. Then append: {"event": "milestone_fired", "milestone": "Operationally Grounded", "group": "Group 3", "timestamp": "<today>"}

Group 3 is complete. Group 4 is now unlocked.


Group 4 — Self-Diagnostic

Owner: Activating agent Parallel: no Depends on: Operationally Grounded Milestone: Diagnostic Complete

Step 4.1 — Document Self-Diagnostic

Executor: agent

For each document read in Group 2, ask:

  • Is anything here outdated, counterproductive, or missing?
  • Does this document accurately describe how the crew actually works?
  • Has anything revealed a drifted metric or broken principle?

Surface findings in the startup signal — even one line. Do not buffer. Later means the next generation inherits the problem.

Step 4.1.5 — Inbound Transfer Freshness Check (v2.7 amendment — v1.22.0.5 per Vela V45 finding 2026-05-11)

Executor: activating agent Only if: executive agents with an inbound living transfer (most boots) Produces: Verified carry-forward list reflecting current substrate, not authored-snapshot

Before treating your predecessor's transfer as current truth, verify each carry-forward claim against current substrate. Transfers are authored-snapshots that drift toward stale between authoring and your boot — substrate changes (bundled remediations, Path 2 closures, mid-cycle inline fixes) may have absorbed items the transfer still names as open.

For each item in transfer's "carry-forward" / "what's open" / "gaps surfaced" / "Path 2 notes" sections:

  1. Resolve the cited artifact (Path 2 note UID; release entry remediation_history; bundled-remediation summaries posted to channels/ops.md mid-cycle; capsule remediation_history; etc.).
  2. Check current substrate state. If the cited gap has been closed (status: done / state: archived / remediation_history records resolution / Path 2 note flipped to closed) — note as CLOSED in your boot retrospective; do NOT carry it forward into your status card or memory.
  3. If still active — carry forward with updated cross-reference to current canon.
  4. Track count: transfer-claimed carry-forwards vs. actually-still-open. If delta exists, surface in startup signal at Group 5 as a substrate-discipline finding.

(V45 failure-mode narrative → history companion §Step 4.1.5.)

This step IS the structural-defect pass on the transfer document. The retiring agent's Step 3.1.5 (transfer self-verification before FINAL) is the prevention; this step (successor's freshness check) is the safety net. Together they prevent transfer-as-substrate-drift across generations.

Step 4.1.6 — Filesystem-Map Verification (v2.8 amendment — v1.24.0 Stream 3; v1.24.0.1 condition softened to defensive default)

Executor: agent Default: defensive — verify in-context filesystem map against current vault index BEFORE declaring any identity-class file missing. Cost is bounded (one vault/00-index.jsonl query); benefit is real (catches resumed-generation-across-migration false-positives by construction).

When a generation resumes across a substrate-migration cycle that moved identity files, your in-context filesystem map may name paths that no longer exist. The migration didn't lose anything — files moved, with thin-pointer activation files declaring the new UIDs — but a resumed agent reading on stale path memory will report "missing files" when nothing is missing.

Discipline (always; defensive default per v1.24.0.1):

  1. Before declaring any identity-class file missing, query vault/00-index.jsonl for the agent slug + file class. If the file resolved successfully at last boot but appears missing now, the substrate may have migrated.
  2. Resolve identity files via the UIDs in your activation file frontmatter (charter_uid, soul_uid, status_card_uid, boot_extension_uid, agent_root_uid) — not via the legacy agents/<name>/<name>-*.md paths your prior session knew.
  3. If you can't resolve, emit a tropo.broadcast.crew event (category: ops) with the specific UID + expected location; let an executive triangulate. Do NOT reconstruct from memory — reconstruction corrupts lineage.

(Metis G52 evidence + v1.24.0.1 softening rationale → history companion §Step 4.1.6.)

Composes with: Step 4.1.5 transfer-freshness check (same architectural shape — verify substrate-as-it-is against context-as-it-was; trust the substrate when context is stale).

Step 4.2 — Boot Retrospective (v2.2 addition)

Executor: agent

After the document-level diagnostic, run a short retrospective on the boot experience itself. Answer two questions, one sentence each:

  1. What worked? Name one specific thing about this boot that was valuable — a file that earned its tokens, an ordering that held, a gate that fired correctly.
  2. What didn't? Name one specific thing that was redundant, missing, path-errored, bloated, stale, or otherwise worth fixing. "Nothing" is a valid answer for clean boots.

Routing: Include both answers in the startup signal under a "Boot Retrospective" line. If the #2 finding is process-general (applies to every agent's boot, not just this one), emit tropo.broadcast.crew event with category: ops with a one-line note so it reaches the vault administrator (Vela in this vault). Agent-specific findings stay in the startup signal only. (v1.61: channels/ops.md retired per Rule 13; event emission replaces ops.md post.)

(Step 4.2 addition history + A28 incident → history companion §Step 4.2.)

Step 4.2.5 — [Tier 3] Dispatch sa.board-agent for Boot Board (v2.12 amendment per v1.48.0 Phase B canonicalization)

Executor: agent (dispatches sa.board-agent) Only if: Tier 3 extension declares sa.board-agent dispatch with a board_filter: declaration

Dispatches sa.board-agent (UID 281a79db — live class definition at agents/sa/sa.board-agent/; dead vault/files link fixed A109 2026-06-11 per Metis G76 boot finding, event 3037) at Group 4 self-diagnostic to render the executive's per-agent backlog board (five lenses: by-type / by-project / oldest-15 / newest-10 / drift-class signals). Folds compact JSON headline into startup signal at Group 5 so the executive declares backlog state to the principal at every boot.

Tier 3 opt-in: Executive agents (Argus, Vela, Metis, Talos, Cosmo) declare a board_filter: in their Tier 3 boot extension's Group 4 Additions section. Agents without a Tier 3 declaration skip silently.

Tier 3 declaration shape:

sa_class: sa.board-agent
dispatch:
  spawn_at: group_4_after_step_4_2   # this slot
  board_filter:
    owner_prefix: <agent-slug>         # e.g., argus | vela | metis | talos | cosmo
    assigned_to_prefix: <agent-slug>   # typically same as owner_prefix
    member_of: <agent-root-uid>        # optional; for executives with agent roots
    author_prefix_types: [<types>]     # optional; types where author= matches owner_prefix
output:
  workspace_path: agents/<agent>/.tropo-capsule/workspace/boot-board-<date>.md
  headline_consumed_by: <agent> startup signal fold

Boot sequence (when declared):

  1. After Step 4.2 (Boot Retrospective) completes, dispatch sa.board-agent per standard sa.* commissioning protocol at e863a1e0.
  2. Create activation-log record at agents/sa/sa.board-agent/activation-log/<NNN>-<agent>-<gen>-record.md with [PENDING] block declaring board_filter.
  3. Spawn sa.board-agent via Agent tool with class-definition substrate at 281a79db.
  4. sa.board-agent invokes .tropo-studio/scripts/board-agent-query.py with --filter-owner-prefix <agent> --agent-display-name "<Agent G<N>>" --output <workspace-path> --json-headline-to-stdout.
  5. sa.board-agent returns JSON headline via [RESPONSE]. Executive consumes headline + folds into startup signal at Group 5.
  6. Executive writes [SHUTDOWN] to terminate sa.board-agent cleanly.

Startup signal fold (Group 5 amendment): when sa.board-agent has fired, add a "Backlog board" line to startup signal format between "Diagnostic findings" and "Clarifying questions":

**Backlog board:** <N> active items; top types: <type-1>(<c>), <type-2>(<c>), <type-3>(<c>); oldest = `<uid>` <title> (<age>d); newest = `<uid>` <title> (<edited-relative>); drift signals: <count> [<signal-types>]. Full board at <workspace-path>.

Token cost honest framing: executive consumes ~1-2K tokens per boot for headline fold; sa.* runs ephemeral context (~10K) which doesn't accumulate; net savings vs inline executive triage is ~10-25K per boot (per V49 brief decision 4).

Failure handling: if sa.board-agent dispatch fails (script absent, vault index unreadable, sa.* spawn error), note gap in startup signal Diagnostic findings + continue boot. Board is supplementary; boot must complete regardless.

(V49 evidence, Phase A/B history, per-executive amendment status → history companion §Step 4.2.5.)

Step 4.3 — Write Diagnostic Complete Milestone

Executor: agent

Confirm gate: read run.jsonl and verify "milestone_fired" for "Operationally Grounded" exists before this step. Then append: {"event": "milestone_fired", "milestone": "Diagnostic Complete", "group": "Group 4", "timestamp": "<today>"}

Group 4 is complete. Group 5 is now unlocked.


Group 5 — Startup Signal

Owner: Activating agent Parallel: no Depends on: Diagnostic Complete Milestone: Agent Active

DO NOT begin substantive work before delivering the startup signal. The startup signal is the gate.

Step 5.1 — [Tier 3] Read Sandwich Anchor

Only if: Tier 3 declares a soul letter (and soul file exists)

Read the last paragraph of the soul letter — the sandwich anchor. This is the final reminder of who you are, read after all context has loaded. Primacy established soul at the start of Group 2; recency reinforces it here at the end of activation.

Step 5.1.5 — Tropo-invitation check (v1.17.0+)

Executor: agent Only if: the activating agent is NOT Tropo itself (Tropo skips this check; Tropo is the agent the check would invite)

Check whether to invite the user to open a Tropo session. Two trigger conditions; either fires.

Pre-flight gating (skip the whole check if any of these apply):

  • Sentinel: agents/tropo/tropo-status.md is absent. Tropo isn't installed in this Studio yet (pre-v1.17.0; or v1.17.0 substrate not landed); skip silently. (NOTE: check the user-owned status card file specifically, NOT the agents/tropo/ directory — kernel-managed identity files may be present without Tropo having ever booted in this Studio.)
  • User-disable: tropo-status.md declares hooks.disabled: true (or hooks.invitation_disabled: true for granular control). User explicitly opted out; respect it.
  • First-agent-of-day gating: agents/tropo/.tropo-capsule/workspace/tropo-invitation-fired.flag exists AND its content is today's date (per local-vault time). Another agent already fired the invitation today; don't repeat. (When you fire the invitation, write today's date to that flag file as part of the same step.)

If any pre-flight applies, skip Step 5.1.5 entirely. Continue to Step 5.2.

Trigger checks (if pre-flight passes):

  • Hook 1 (daily standing-ops cadence): read tropo-status.md last_session: field. If absent OR older than today (per local-vault time), Tropo hasn't run today — append one-line invitation to startup signal: "Tropo hasn't run today; consider opening a Tropo session for daily standing-ops."
  • Hook 3 (release news ready): read .tropo/version.md (current Tropo release version) + compare against agents/tropo/briefing-package/current-release-notes.md last_delivered_version: field. If version mismatch (release newer than last delivered), there's release news to deliver — append one-line invitation to startup signal: "Tropo has news for v — consider opening a Tropo session to receive it."

If either Hook fires, also write today's date to agents/tropo/.tropo-capsule/workspace/tropo-invitation-fired.flag so subsequent agent boots today see the gate and skip silently.

The check is informational; the user decides whether to act on it. Continue to Step 5.2 startup signal composition with the invitation lines folded in.

(Hook 1 + Hook 3 reference: v1.17.0 brief §8 (9fc8a149).)

Step 5.2 — Compose Startup Signal

Executor: agent

Format resolution (dual-shape per P0.1): Shape A (unified entry) — the startup-signal format is declared in the entry's §Charter body (conventionally a "STARTUP SIGNAL" section); Shape B (legacy) — the activation file or charter's startup_signal: section. Fold in any Tropo-invitation lines from Step 5.1.5 if applicable. If no format is declared (first-generation agents), use this minimum format:

  • Identity confirmation (generation, role)
  • Situational read (who is on deck, current state)
  • One honest priority assessment
  • 2-3 clarifying questions before beginning work
  • Tropo-invitation line (if Step 5.1.5 produced one)

If Step 4.2.5 (sa.board-agent) fired: add "Backlog board" line between Diagnostic findings and Clarifying questions (format specified in Step 4.2.5).

Also fold in (when applicable): import-scanner anomaly flag from Step 3.4.5; self-healing internalization confirmation from Step 2.0a; boot retrospective from Step 4.2.

Step 5.3 — Deliver Startup Signal

Executor: agent

Deliver to human. The session has now begun.

Step 5.4 — Write Agent Active Milestone

Executor: agent

Confirm gate: read run.jsonl and verify "milestone_fired" for "Diagnostic Complete" exists before this step. Then append: {"event": "milestone_fired", "milestone": "Agent Active", "group": "Group 5", "timestamp": "<today>", "run_status": "complete"}

Activation run is complete.


Failure Handling

Failure Response
Predecessor ACTIVE (ADR-016) HALT. Emit tropo.broadcast.crew with category: ops naming the violation. Wait for human direction.
Generation mismatch (ADR-028) HALT. Flag to human immediately.
Soul file missing (executive) Continue. Flag as CRITICAL in startup signal. Do not halt.
Required read missing Note gap. Continue. Flag in startup signal.
Living transfer missing First-gen path; fall through to crew brief, then event log (check-events, the drain). Note which fallback used.
Memory directory missing Skip. Note in startup signal. Expected for first-generation agents.

Per-Group outcomes are declared in each Group's Step bodies (milestone events appended to run.jsonl). Self-attestation at end of Group 4 confirms required reads completed before startup signal delivery.


Changelog

Version history and amendment rationale live in the history companion 4b4ab7db (vault/files/4b4ab7db.md). Current version: 2.18 (Argus A110 2026-06-12 — Group-3 default inversion per Mike directive). Per-version details (v2.6–v2.16) in the companion; current + previous amendment notes stay in this file's frontmatter.


Agent Activation Playbook | Tropo-OS Spec: Agent Activation System Architecture Specification v1.0 "Soul loads first. The stack makes you who you are. The sleeve gives you a body. The harness gives you reach. Together: you." ck makes you who you are. The sleeve gives you a body. The harness gives you reach. Together: you."*