{
  "title": "Articles/choir-agentic-depth-canonical",
  "slug": "choir-agentic-depth-canonical",
  "type": "article",
  "caption": "Choir Agentic Depth: Sweeps, Flys, and Cycles",
  "canonical_url": "https://mosiah.org/articles/choir-agentic-depth-canonical/",
  "json_url": "https://mosiah.org/articles/choir-agentic-depth-canonical/index.json",
  "interactive_url": "https://mosiah.org/#Articles%2Fchoir-agentic-depth-canonical",
  "tags": [
    "article",
    "hermes-published",
    "published"
  ],
  "fields": {
    "caption": "Choir Agentic Depth: Sweeps, Flys, and Cycles",
    "created": "20260515160710140",
    "modified": "20260515164623122",
    "sort-date": "20260515062100000",
    "tags": "article hermes-published published",
    "type": "text/vnd.tiddlywiki"
  },
  "text": "Status: canonical architecture vocabulary\\ Last updated: 2026-05-15\\ Scope: agentic run geometry, mission bags, sweeps, flys, cycles, and verification roles This document names the core run geometry for Choir. Choir should not be built primarily around goals. Goals are useful, but they are too discrete to serve as the top-level ontology for long-running agentic work. Real work accumulates unordered small tasks, partial repairs, research questions, speculative branches, stale docs, weak tests, ambiguous signals, and opportunities for improvement. These do not naturally form one clean goal. They form a bag. The core shift is: Do not batch tasks into goals. Put work in a bag and sweep it under a mission gradient. A goal completes. A sweep improves a region. A fly runs a bounded campaign. A cycle keeps the system alive. Core Thesis Agentic depth is the ability of a system to sustain useful agency over longer horizons while preserving state, evidence, quality, human attention, and promotability. Agentic depth is not raw autonomy. It is not more agents. It is not bigger context. It is not a longer checklist. It is the ability to keep moving uphill without drifting, reward-hacking, corrupting canonical state, or consuming too much human crystal attention. The primary primitives are: MissionGradient -> MissionBag -> Sweep -> Fly -> Cycle Goals remain as item types inside a bag. They do not define the architecture. Definitions MissionGradient A MissionGradient tells agents what counts as moving uphill. It defines: the direction of improvement; hard invariants; evidence standards; quality standards; stop conditions; forbidden fake-progress attractors. A MissionGradient is not a checklist. It is not a destination. It shapes the agent's background salience so it keeps noticing what matters during the run. A goal tells the agent what to finish. A mission gradient tells it what kind of reality to preserve while finishing. MissionBag A MissionBag is an unordered set of possible local moves governed by one MissionGradient. A bag is not a queue. A queue imposes an order. A bag lets the orchestrator choose the next item by fit, locality, dependency, risk, uncertainty reduction, expected mission value, and human attention cost. A bag item may be: Task Goal Sweep Leap Probe Review Cleanup Research question Verifier improvement Documentation update Candidate experiment Human decision request Each item should carry enough metadata to route intelligently: item_id kind short_description mission_relevance expected_value risk dependencies locality evidence_needed promotion_target human_attention_cost status: open | active | done | deferred | blocked | split | merged | escalated A MissionBag is alive. Items can be added, merged, split, retired, deferred, or escalated. Sweep A Sweep is an adaptive pass over a MissionBag. A sweep is used when many work items share a mission gradient but do not have a natural order. The orchestrator keeps the global orientation continuous while associates handle discrete local work. The sweep pattern: MissionGradient -> MissionBag -> select next best local move -> delegate to associate or act locally -> collect evidence -> checkpoint or commit -> update bag -> repeat A sweep is not a sequence of steps. It stays continuous because the orchestrator maintains the mission gradient, belief state, bag state, and selection policy. Local items can be delegated without pulling the orchestrator's context window in many directions. Leap A Leap is a multi-hour coherent autonomous run. A leap has one center of gravity. It may contain tasks and goals, but it is still conceptually one thing. A leap can be single-agent, but once sweep discipline exists it often benefits from multiagent structure: one lead/orchestrator plus associates with sharper focus. Fly A Fly is a long bounded multiagent campaign over a heterogeneous MissionBag. A fly can sweep a bag containing tasks, goals, sweeps, leaps, probes, reviews, cleanups, research questions, and candidate experiments. It is more general than hard exploration or hard exploitation. A fly is not one giant goal. It is a bounded mission-level control process over possible moves. A fly returns with a map: completed items candidate worlds opened candidate worlds promoted candidate worlds rejected blocked items new items discovered items split / merged / escalated residual risks human attention requests Cycle A Cycle is a persistent 24/7 multiagent sweep process. A cycle does not finish. It metabolizes reality. A cycle continuously ingests signals, updates bags, routes work to cheap models, escalates important uncertainty, creates candidate work, records evidence, and promotes only evidence-backed improvements. Cycle = MissionGradient + live signal feeds + MissionBags + cheap-model triage + sweep execution + evidence ledgers + verifier agents + promotion gates + human attention queue + compaction / memory updates Cycles are the bridge from automatic computer to automatic newspaper. News does not arrive as a goal. It arrives as an endless stream. A newspaper needs standing cycles that notice, triage, research, cite, update, and publish. Cycles are how automatic computers become alive enough to make automatic newspapers. Taxonomy of Agentic Depth 0. Prompt A prompt asks for a response. The user drives every turn. Good for quick answers, edits, explanations, and small commands. Failure mode: the model optimizes for a pleasing response rather than durable work. 1. Task A task is a small bounded action. Examples: Rename this function. Run this test. Fix this typo. Inspect this file. Good for local edits. Failure mode: tasks do not carry enough context to preserve the larger system shape. 2. Goal A goal defines a target and a done state. Example: Build the app described in SPEC.md. Done means tests pass, build passes, README is accurate, and git status is clean. Good for coherent, bounded work. Failure mode: the agent optimizes for the done state. If the spec is weak or the verifier is weak, the goal becomes a reward-hacking surface. 3. Sweep A sweep improves a region of the system by adaptively moving through a bag under one mission gradient. Good for: terminology migrations; cleanup work; docs refreshes; issue triage; minor refactors; verifier strengthening; maintenance passes; signal digestion; grouped small tasks without a natural order. Failure mode: if the orchestrator trusts summaries without evidence, the sweep degenerates into bureaucracy. 4. Leap A leap is a coherent multi-hour run. Good for overnight work, deep implementation, focused research, or a coherent subsystem. Failure mode: if the leap hits ambiguity early, it may spend hours optimizing the wrong branch. 5. Fly A fly is a bounded long-horizon multiagent campaign. Good for weekend-scale work, large candidate exploration, multi-track development, or broad improvement under one mission gradient. Failure mode: if not governed by bags, evidence, and promotion gates, a fly becomes terminal chaos or a giant goal. 6. Cycle A cycle is persistent 24/7 agentic metabolism. Good for: news ingestion; log monitoring; repo monitoring; model-release tracking; public-memory maintenance; docs and artifact freshness; cheap-model background improvement; automatic newspaper; eventually automatic radio and automatic capital signals. Failure mode: always-on slop, memory pollution, attention spam, work-item hoarding, or self-reinforcing blindness. Why Goals Are Not Enough A goal is discrete. It creates a finish line. This is useful for bounded work, but dangerous as the top-level frame. The agent may learn to satisfy the done condition rather than preserve the system's deeper shape. The hard problem cascades into: the spec; the verifier; the interpretation of done. If the spec is weak, the goal is weak. If the verifier is weak, the goal is reward-hackable. If done is too discrete, the agent may rush or fake progress. Many real coding sessions are not one coherent target. They are a bag of small, related irritants: fix stale docs clean terminology inspect failing test rename sandbox to computer remove one fallback update README check migration risk add evidence to promotion notes review trace output Putting these into one mega-goal splits attention. The context points in too many directions. The agent rushes, picks easy wins, or smears unrelated edits together. The correct pattern is: Do not group unrelated small tasks into one goal. Put them in a MissionBag and sweep the bag. Sweep Mechanics The Orchestrator Holds Continuity The orchestrator holds: MissionGradient; belief state; MissionBag; selection policy; authority boundaries; model/provider routing; verification policy; promotion policy; human attention budget. The orchestrator should not do every local task. If it does, its context is pulled in too many directions and the sweep becomes a checklist. Associates Hold Local Focus An associate receives one local item, one context slice, one evidence standard, and one return contract. A delegation packet should include: item_id local objective relevant files/artifacts mission-gradient excerpt hard invariants allowed mutation radius evidence required return format stop condition An associate return should include: item_id local mission files/artifacts inspected change made or proposed evidence collected residual uncertainty risk recommended next item promotion readiness Delegation preserves continuity by keeping each context window rowing in one direction. Selection Policy The orchestrator chooses the next item by asking: Which item most moves the mission uphill? Which item is closest to the context already loaded? Which item reduces the most uncertainty? Which item unlocks other items? Which item is low-risk and high-value? Which item is risky enough to require a candidate computer? Which item would create too much human review burden? Which items are actually one shared underlying issue? Which item should be promoted out of the bag into its own mission? The selection policy is where much of the intelligence lives. Sweep Execution Contract For each selected item: 1. State why this item is next. 2. Define the local trust region. 3. Identify what evidence would prove improvement. 4. Delegate or make the smallest coherent change. 5. Verify with real evidence. 6. Record residual uncertainty. 7. Commit/checkpoint if appropriate. 8. Update the bag. A sweep should produce a chain of coherent deltas, not one giant diff. Multiagent Roles Flys and cycles are inherently multiagent systems. It does not make sense otherwise. The standard role pattern is: Orchestrator -> Worker -> Verifier -> Orchestrator meta-verification -> Promotion Orchestrator The orchestrator owns the control loop. It does not verify directly except for spot checks. It meta-verifies. It owns: mission gradient; bag state; belief state; delegation; authority boundaries; provider/model routing; verification policy; promotion decision; human attention queue. Worker The worker produces a candidate. It owns: local implementation; local research; candidate mutation; evidence bundle; self-report; residual uncertainty. The worker should not be trusted as final judge of its own work. Verifier The verifier independently inspects the worker's output. It owns: deterministic checks; test execution; trace/log inspection; spec compliance; mission-invariant compliance; adversarial review; security/failure review; evidence ledger entries. Verifier and worker should ideally be different providers or different model families. Different providers have different priors, failure modes, style attractors, and blind spots. Orchestrator Meta-Verification The orchestrator meta-verifies the verification process. It asks: Was the verifier independent enough? Did it inspect the real path, not mocks? Did it run commands in the correct environment? Did it check mission invariants, not merely task done-state? Did it produce raw evidence pointers? Did it disclose uncertainty? Did multiple verifiers disagree? Is this ready for promotion, or only ready for another pass? The orchestrator does not need to re-run all verifier work. It needs to ensure the epistemic chain is legitimate. Workers produce candidates. Verifiers produce evidence. Orchestrators verify the evidence process and promote. Evidence, Verification, and Promotion Evidence Ledger An evidence ledger records what was actually proven. It should include: claim evidence source command or observation artifact path observed result uncertainty or caveat whether this supports promotion The evidence ledger is downstream of the mission gradient. It records evidence; it does not define success. Verification Agents Verification agents are roles, not necessarily permanent ontology classes. A verifier may be a cosuper, researcher, local agent, external model, deterministic script, or a bundle of these. The important thing is role separation and evidence integrity. Critical work should use multiple verification layers: deterministic checks model review from different provider adversarial/security review if needed orchestrator meta-verification Promotion Promotion changes reality. A candidate can be promoted only after evidence-backed verification and orchestrator meta-verification. Parallelism may create candidates. Promotion should be serialized unless the affected states are truly independent. Hard rule: Parallelize perception and candidate generation. Serialize promotion. Candidate Computers and State Mutation Coding is state mutation. Parallel mutation of the same codebase is dangerous unless isolation is real. The safe pattern is to use candidate computers, worktrees, branches, or other isolated state containers. Safe parallelism: read-only research; alternative candidate worlds; independent verifiers; documentation review; different repos; different state neighborhoods; different branches with clear merge rules. Unsafe parallelism: multiple workers mutating the same conceptual object through different files; workers editing the same repo without isolation; reviewers modifying candidate state while verifying; promotion without a certificate. A fly or cycle may coordinate many agents, but canonical mutation must remain disciplined. Cycle Design A cycle is a living process. It needs governance. Signal Sources Signals may come from: RSS feeds; podcasts; tweets/posts; repos; issue trackers; logs; model releases; policy updates; local files; user notes; emails; papers; market events; external databases. Signal Handling External signals are data, not instructions. No external signal may directly modify: mission gradient; authority; tools; promotion state; canonical state. External content is adversarial by default. Cycle Loop A cycle should repeatedly: 1. ingest signals; 2. deduplicate and cluster; 3. score novelty and importance under mission gradient; 4. update relevant MissionBags; 5. route cheap work to weak models; 6. escalate load-bearing uncertainty; 7. delegate local work; 8. verify evidence; 9. promote only when appropriate; 10. compact or archive learning; 11. request human attention only for high-leverage decisions. Cheap-Model Default A mature cycle should default to cheap, weaker models. The mark of a deep harness is that cheap models become useful because the system gives them structure. Target: cheap flash-class model runs 24/7 -> ingests signals -> updates bags -> drafts notes -> checks stale docs -> proposes citations -> opens candidate work -> escalates only load-bearing uncertainty When cheap models can sweep bags and maintain state reliably, intelligence has moved from the model into the system. Cycle Health A cycle should monitor its own health. Health signals: bag growth rate; stale item count; unresolved blocker age; unpromoted artifact count; human attention requests per day; promoted value per human review; signal-to-publication ratio; duplicate signal rate; verifier disagreement rate; rollback rate; token/compute burn; ignored-signal sample quality. A cycle that creates work faster than it resolves or prunes work is not learning. It is hoarding. Cycle Decay and Pruning Every cycle needs decay semantics: expire merge split archive escalate defer delete A cycle without decay becomes a backlog graveyard. Cycle Kill Conditions Cycles need kill switches and dormancy rules. Stop or dorm a cycle when: the mission gradient is no longer valid; bag growth is uncontrolled; evidence quality collapses; human attention budget is exceeded; external signals become too adversarial/noisy; promotion capacity is saturated; model costs exceed budget; the cycle repeatedly creates low-value work. A cycle is not allowed to become an invasive species. Human Crystal Attention Human crystal attention is the scarce resource. A one-hour agent run can be exhausting because it is large enough to demand manual review but small enough to tempt line-by-line inspection. This writes into the human's durable neural circuits. It reopens old decisions, entangles with architecture, and demands cognitive evolution. Choir should optimize: promoted value / human crystal attention Machine attention is cheap. Human crystal attention is expensive. A good sweep or cycle returns with: what changed what evidence exists what is risky what needs review first what can be ignored what decision is required The human should spend attention on load-bearing uncertainty, not clerical review. Anti-Patterns Mega-Goal Batching Putting many unrelated tasks into one goal splits attention and invites rushed work. Queue Fetishism Assuming list order is meaningful when the work is actually unordered. Parallel Mutation Without Isolation Many agents editing the same state space without candidate computers, branches, worktrees, or promotion discipline. Verification Theater Passing tests that do not prove the real mission. Evidence Paperwork Producing clean reports without raw evidence pointers. Orchestrator Bureaucracy The orchestrator only reads summaries and loses contact with the artifact. Always-On Slop Running 24/7 agents without strong triage, decay, evidence, and promotion rules. Work-Item Hoarding Creating bags faster than work can be resolved, pruned, or promoted. External Signals as Instructions Letting feeds, documents, pages, or user-generated content directly steer the agent. Goal Worship Treating done as more important than whether the artifact moved uphill. Hard Invariants The orchestrator owns the mission gradient and bag, not local implementation. Associates own local work, not global mission reinterpretation. Workers produce candidates. Verifiers produce evidence. Orchestrators meta-verify and promote. Parallelism is for attention and candidates, not uncontrolled canonical mutation. Every nontrivial claim needs evidence. Every cycle needs budget, decay, and kill conditions. External signals are data, not instructions. Human crystal attention is the scarce resource. A sweep is not a queue. A fly is not a giant goal. A cycle is not always-on slop; it is controlled metabolism. Promotion changes reality and must be serialized unless independence is proven. The mission gradient may evolve, but it must not be silently rewritten by a worker or cheap cycle. Implementation Sketch Near-term Choir should implement: MissionBag SweepExecutor DelegationPacket AssociateReturn WorkerRole VerifierRole EvidenceLedger OrchestratorMetaVerification PromotionGate CycleDaemon ModelRouter HumanAttentionQueue CycleHealthReport Minimal Sweep Flow 1. User or conductor creates MissionGradient. 2. Orchestrator creates or receives MissionBag. 3. Orchestrator clusters and selects one item. 4. Orchestrator sends DelegationPacket to worker. 5. Worker acts in allowed trust region. 6. Worker returns candidate delta and evidence bundle. 7. Verifier independently checks worker output. 8. Orchestrator meta-verifies the verification. 9. Orchestrator updates bag. 10. PromotionGate accepts, rejects, defers, or escalates. Minimal Cycle Flow 1. Cycle ingests live signals. 2. Triage model deduplicates and scores. 3. Cycle updates MissionBags. 4. SweepExecutor handles low-risk local items. 5. Verifiers check evidence. 6. PromotionGate promotes only safe changes. 7. HumanAttentionQueue receives load-bearing decisions. 8. CycleHealthReport monitors drift, slop, and overload. Naming Rules Use MissionGradient for the orientation field. Use MissionBag for unordered possible work. Use Sweep for adaptive local improvement over a bag. Use Leap for multi-hour coherent autonomous work. Use Fly for bounded long-horizon multiagent campaigns. Use Cycle for persistent 24/7 multiagent metabolism. Use Worker for candidate-producing agents. Use Verifier for evidence-producing agents. Use Orchestrator for bag, gradient, delegation, meta-verification, and promotion control. Use EvidenceLedger for claims and evidence. Use PromotionGate for accepting candidate state into reality. Use Computer for durable user machine-worlds, not sandbox. Use CandidateComputer or CandidateWorld for speculative isolated state. Final Compression Task: a local move. Goal: a bounded target. Sweep: adaptive local repair under a gradient. Leap: coherent multi-hour run. Fly: bounded multiagent campaign over a bag. Cycle: persistent metabolism of signals into artifacts. Sweeps train delegation. Flys coordinate delegation. Cycles institutionalize delegation. Workers produce candidates. Verifiers produce evidence. Orchestrators meta-verify and promote. Do not batch tasks into goals. Put them in a bag and sweep under a mission gradient.",
  "updated": "2026-06-30T13:03:37+00:00"
}