Autonomous Orchestrator¶

autonomous_orchestrator -- G6 Autonomous Multi-Agent Orchestration System.

Cluster: Experience & Autonomy | Type: component | MCP Tools: 27

Overview¶

24/7 autonomous multi-agent orchestration system that continuously processes a JSON todo list using a six-slot agent pool (design, execution, evaluation, and three proxy agents) with rate limiting, session logging, and human-review queuing. Wraps AgentPool, TaskManager, and RateLimiter into a single AIBlock with graceful shutdown via signal handling.

When to use:

Running an unattended agent loop that picks up tasks from a structured todo file and executes them autonomously
Distributing work across specialised agent roles (design → execution → evaluation) with token accounting
Integrating continuous background processing into G6 with HITL review hand-off

Example:

from mvp.autonomous_orchestrator import AutonomousOrchestratorBlock, OrchestratorInput

block = AutonomousOrchestratorBlock()
result = block.infer(OrchestratorInput(
    todo_path="components/mvp/workspace_manager/claude_todo_list.json",
    dry_run=True,
    stop_on_empty=True,
))
# result.ok → True; result.value → OrchestratorOutput with tasks_completed, summary

Works well with: recursive_architect, hat_orchestrator, autonomy_governor

OrchestratorInput safety-relevant fields:

op — Literal["describe", "status", "start_daemon"] (default start_daemon). describe/status are read-only shims that never enter the dispatch loop; only start_daemon launches the 24/7 daemon. Registry-invoked bogus ops fail validation cleanly.
production_mode — bool (default False). With op="start_daemon" and production_mode=True, the direct JSON-backed path is refused with degraded=True, degradation_reason="json_unsafe_in_production". The JSON TaskManager has no file-locking contract, so concurrent writers can corrupt the todo file. Use the SQLite-backed orchestrator_mcp store in production.

Split-brain note: the direct daemon (JSON) and the orchestrator_mcp plane (SQLite) are separate sources of truth. The MCP plane is management/inspection only — it cannot start, stop, or inspect the live daemon. ao_get_pool_status reports active SQLite sessions (not live AgentPool slots), ao_configure_limits mutates shadow state (not a running RateLimiter), and ao_capabilities reports live_control_available: false. Cross-package enrichment fallback in ao_complete_task and bad-JSON / agentic degradation in ao_run_failure_guard are surfaced via degraded/degradation_reason.

Pilot-ready, not multi-worker production hardened

The autonomous orchestrator is suitable for local development, dry runs, and early pilot workflows where a single process owns the task queue. It is not yet hardened for multi-worker production operation.

The direct AutonomousOrchestratorBlock path uses JSON-backed todo and human-review files, which are not safe for concurrent writes from multiple orchestrator processes. Runtime dollar-cost tracking is also process-local, so production deployments should rely on a single orchestrator instance, explicit token limits, the kill-switch file, and human review until durable shared spend accounting is added.

For paid self-serve or unattended production use, run an end-to-end MCP install/run smoke test first and prefer the SQLite-backed orchestrator_mcp operations for task/session inspection. Do not treat successful task completion as a proof of business or regulated-domain correctness without human review.

Public API¶

`AgentPool`¶

Manages 6 concurrent agent slots for dispatching tasks.

Constructor:

Parameter	Type	Default
`task_manager`	`TaskManager`	required
`rate_limiter`	`RateLimiter`	required
`config`	`OrchestratorInput`	required
`governor`	`'AutonomyGovernorBlock \\| None'`	None
`hitl`	`'HITLDispatcher \\| None'`	None
`safety_policy`	`'RuntimePolicy \\| None'`	None
`pricing_catalog`	`Any \\| None`	None

Methods:

`dispatch(stop_event: asyncio.Event) -> dict`¶

Run the dispatch loop until stop_event is set or no tasks remain.

`GuardSignals`¶

Derived signals from the 20 failure-guard answers.

Field	Type	Default
`stuck`	`bool`	False
`waste`	`bool`	False
`no_value`	`bool`	False
`sanity_failed`	`bool`	False
`degraded`	`bool`	False
`degradation_reason`	`str`	''

`GuardVerdict`¶

The outcome of a Ralph Wiggum loop iteration.

Field	Type	Default
`signals`	`GuardSignals`	field(default_factory=GuardSignals)
`next_action`	`str`	'continue'
`iteration`	`int`	0
`passed`	`bool`	True

`FailureGuard`¶

Asks each of the 20 questions via a cheap LLM and logs answers.

Constructor:

Parameter	Type	Default
`logger`	`SessionLogger \\| None`	None

Methods:

`ask_questions(context: str, task_title: str = '', dry_run: bool = False) -> list[tuple[int, str, str]]`¶

Ask all 20 questions about the current step.

`extract_signals_from_json(json_str: str) -> 'GuardSignals'`¶

Parse structured JSON answer list into GuardSignals.

`extract_signals(answers: list[tuple[int, str, str]]) -> GuardSignals`¶

Derive 4 signals from key question answers.

`RalphWiggumLoop`¶

Orchestrates the full failure-guard + verdict pipeline per step.

Constructor:

Parameter	Type	Default
`logger`	`SessionLogger \\| None`	None
`dry_run`	`bool`	False

Methods:

`set_guard_signal_planner(planner: object) -> None`¶

Inject an agentic failure-signal planner (test seam).

`review_step(context: str, task_title: str = '', attempts: int = 0) -> GuardVerdict`¶

Run the full 20-question review and determine next action.