Orchestration Triggers

Description

Orchestration triggers are events that cause the system to invoke, resume, or re-invoke an agent. They span the full range of system operation from work intake to autonomous recovery and are not limited to human-initiated actions.

Triggers are the primary mechanism by which the system continues operating without constant human intervention. A well-defined trigger layer is one of the required conditions for minimal bootstrap.

Trigger Categories

Work Item Triggers

Fired when tracked work changes state in the issue or project system.

Issue created or transitioned to a state that signals readiness for execution.
Enrichment completed and approved by a human reviewer.
Issue label or tag applied by an automated classifier or operator.
Milestone or sprint boundary reached with open work items.

These are the entry points for planned, goal-directed work.

Scheduling and Heartbeat Triggers

Fired on time, independent of any external event or human action.

Periodic heartbeat to check goal progress and identify stalled work.
Scheduled synthesis run to update the knowledge base from recent outputs.
Timed re-evaluation of open issues against current system state.
Scheduled audit of execution ledger for anomalies, cost overruns, or drift.

Heartbeat triggers are what allow the system to stay active and self-checking even when no external events arrive.

Webhook and External Signal Triggers

Fired by external systems pushing events into the orchestration layer.

Version control events: push, PR opened, PR review submitted, check run completed.
CI/CD events: build failure, test regression, deployment complete or failed.
Monitoring and alerting events: threshold breach, error rate spike, service degradation.
External API callbacks or integration events from connected tools.

These connect the agent system to the world it is operating on, allowing it to react to real outcomes rather than only to planned work.

Recovery and Continuity Triggers

Fired when the system detects incomplete, failed, or stalled execution.

Agent invocation exits without a successful completion signal.
Expected artifact (PR, commit, report) not produced within a defined window.
Subagent failure propagated to the parent orchestrator.
Heartbeat detects an invocation that started but never resolved.
Manual recovery directive issued by an operator to resume a stalled run.

Recovery triggers are what prevent silent failures from being treated as completions. They are essential for autonomous operation over extended time horizons.

Feedback and Learning Triggers

Fired when an outcome signal is available to inform future behavior.

PR review feedback submitted with substantive changes or rejection.
Evaluation run produces a quality signal below acceptance threshold.
Human operator annotates an execution with explicit feedback.
Repeated failure on a class of task crosses a frequency threshold.

These triggers route back into the goal and issue system, generating new work items or updated context rather than just logging the outcome.

Trigger Contracts

Each trigger should define:

Source what system or process emits it.
Payload what information the trigger carries to the invoked agent.
Target which agent type or pool handles it.
Idempotency whether duplicate events are safe to re-deliver.
Failure behavior what happens if the triggered invocation fails.

Concrete contracts for each trigger type are not yet fully documented. This page reflects the intended trigger model; specifics should be added as each trigger type is implemented.

End-to-End Orchestration - Consumes and emits trigger events across the delivery loop.
Ticket Enrichment - Produces work item trigger conditions via the enrichment process.
Planning and Execution - Depends on correctly timed entry into the execution path.
Minimal Bootstrap - Trigger and re-invocation mechanism is one of the required bootstrap conditions.
Execution Ledger - Trigger events and invocation outcomes are recorded here.