src/core/orchestrator.ts is the central turn-processing module, exporting the createOrchestrator factory, which wires together sessions, harness models, memory, skills, credentials, sandboxes, security screening, and delivery into a single Orchestrator instance.[1] src/core/orchestrator.ts re-exports egressClaimAllowingControlPlane, conversationLabelFor, filterConnectorSkills, and loadTapeImage from ./orchestrator/turn-helpers.ts, and re-exports the types Orchestrator, OrchestratorDeps, OrchestratorInput, and SurfaceContextPuller from ./orchestrator/types.ts — see Orchestrator types and deps and Turn helpers for the definitions those modules own.[1] src/core/wake-envelope.ts defines a WakeEnvelope type that wraps all externally-initiated resumes — webhooks, crons, and deep links — into a uniform shape for entry into the orchestrator run loop. The Auto-posture HiLO approval flow is a risk-tiered release mechanism in which tool results flagged as high or low risk are quarantined and suspended, awaiting explicit approval before execution resumes. src/core/orchestrator.ts routes tool-result quarantines triggered by the Auto-posture mechanism through a HiLO (High/Low risk) release approval flow; quarantined results suspend execution and await explicit approval before continuing. src/harness/mock-harness.ts supports the Auto-posture HiLO approval flow for testing, with coverage exercised in test/orchestrator.test.ts, test/pi-tools.test.ts, and test/slack-approval-cards.test.ts. src/types.ts carries additional fields on quarantined-content payloads to surface richer metadata; src/core/orchestrator.ts populates these fields when quarantining tool results through the Auto-posture HiLO flow. src/api/app-helpers.ts supports rendering of quarantined-content metadata; the web UI — plugins/web-ui/src/chat.ts, core-bridge.ts, and shell.css — uses this metadata to render expandable previews of blocked output. test/orchestrator.test.ts asserts on the expanded quarantined-content structure introduced by the richer metadata fields.
createOrchestrator falls back to in-memory stores when optional deps are absent: deps.approvals defaults to createMemoryMap<PendingApprovalRecord>(), deps.approvalGrants to createMemoryMap<CommandApprovalGrant>(), and deps.blobTransfer to createMemoryBlobTransferStore().[1]
Protocol-file constants are loaded once at module initialization: SHARED_CORE_MD, MODE_CONVERSATION_MD, MODE_AUTONOMOUS_MD, and MODE_FALLBACK_MD, each via loadProtocolFile.[1] The ACTIVITY_ENTRY_TYPES set classifies "tool_call", "tool_result", "approval_request", and "approval_resolved" as activity entries, distinguishing active-execution entries from conversational history.[1] First-block capture is capped at FIRST_BLOCK_CAPTURE_MAX_CHARS = 20_000 characters.[1]
The orchestrator maintains an LRU cache for the reachable-channel roster, keyed by principalId, with a TTL of 5 minutes and a maximum of INSTANCE_CACHE_MAX_ENTRIES (5,000) entries.[1] A separate LRU cache holds the directory member index, keyed by the string "org", sharing the same 5-minute TTL but capped at DIRECTORY_INDEX_CACHE_MAX_ENTRIES (100) entries.[1]
Sources