SIM-ONE Alpha uses workers as governed specialist executors. The main orchestrator decides when work should be delegated, supplies the applicable protocols and trusted context, and evaluates the returned evidence before a response or action is accepted.
Workers are internal subsystems of SIM-ONE Alpha. They are not standalone products, public endpoints, or independent authorities.
Admitted event
-> Orchestrator
-> Protocol and context loading
-> Worker selection
-> Flue child session
-> Worker tools, skills, and internal subagents
-> Structured result and progress events
-> Orchestrator synthesis
-> Response, revision, or rejection
The orchestrator remains between the user-facing connector and every worker. A worker performs the delegated task, but it does not admit the original request, redefine the active protocol bundle, or approve its own result.
Each worker is a Flue subagent profile with a distinct execution context. A profile can own:
Delegation opens a child session under the orchestrator’s run. This keeps a worker’s working context separate while preserving the parent-child execution relationship and the orchestrator’s final review boundary.
The Researcher performs source-backed web research. It owns the
web_research tool and returns evidence that includes source URLs, retrieved
context, confidence, cache statistics, budget use, and provider failures.
The orchestrator can decide that current or source-backed information is needed, but web research is delegated to the Researcher. The orchestrator does not directly own the web-search path.
The Coding Worker is a lead worker for repository tasks. It runs a bounded loop with approval-gated Git and GitHub mutations:
Triage
-> Plan
-> Implement
-> Verify and debug
-> Review
-> Git and GitHub actions when requested
-> Structured completion result
The worker owns the tools needed for repository inspection, code intelligence, planning, task memory, file changes, verification, Git operations, GitHub operations, and schedules. Commit, push, and GitHub mutation tools pass through the approval service. Current write and patch tools use workspace and sandbox boundaries but do not call the approval service; that enforcement remains a release gate. The model cannot create its own approval.
The Coding Worker also persists task checkpoints and uses structured task memory, including notes, todos, and checklists, to maintain execution state outside the prompt.
The Coding Worker coordinates five worker-local profiles:
| Profile | Responsibility |
|---|---|
| Triage | Classify the task, inspect the repository, and establish the plan |
| Implementer | Produce scoped file edits |
| Test/Debug | Run verification, diagnose failures, and propose corrections |
| Code Review | Evaluate correctness, regressions, risk, and missing tests |
| GitHub | Prepare and execute approved repository publication actions |
These profiles are private to the Coding Worker. They are not registered as top-level orchestrator workers and cannot be selected directly by a connector or user request.
A worker’s profile defines the capabilities available inside its execution boundary:
Possessing a tool does not grant unconditional authority to use it. Trusted event scope, active protocols, command policy, sandbox boundaries, and approval records still apply.
Workers can also be installed through the runtime capability system. A runtime-added worker is stored in the capability registry and materialized under:
<configured-capability-directory>/workers/<id>/
The configured capability directory defaults to ~/.gorombo/capabilities/.
GOROMBO_CAPABILITIES_DIR overrides it; GOROMBO_CAPABILITY_DIR is the
fallback override.
Installed workers are disabled until explicitly enabled. At startup, enabled worker records are validated and attached through the same Flue subagent surface as built-in workers. Invalid or unavailable records are reported as capability load failures rather than silently exposed.
Runtime installation does not bypass the orchestrator. Added workers remain delegated executors under the same protocol, progress, trust, and validation boundaries.
The standalone Coding Worker loop defines structured progress events for:
That loop can return status, summary, plan, subagent results, verification
evidence, public events, artifacts, and a task checkpoint. The live Flue Coding
Worker profile currently constructs its tools without a reporter or task id,
so coding_progress_emit reports unavailable and those checkpoint events are
not forwarded to the active connector. Wiring the reporter into the live
profile and connector transport is a release gate. The orchestrator still
receives the Flue task result for final synthesis.
Worker execution follows these rules:
This separation prevents the same model context from both performing work and acting as the final authority over that work.
The release contract adds complete protocol scoring and orchestrator/critic validation across each returned result. That enforcement remains a release gate.
| Area | Source |
|---|---|
| Orchestrator registration | src/agents/orchestrator.ts |
| Researcher profile | src/engine/workers/researcher/researcher.ts |
| Coding Worker lead | src/engine/workers/coding-worker/coding-worker.ts |
| Internal coding profiles | src/engine/workers/coding-worker/subagents/ |
| Worker skills | src/engine/workers/coding-worker/skills/ |
| Coding execution loop | src/engine/workers/coding-worker/workflow/ |
| Approval service | src/engine/workers/coding-worker/approvals/ |
| Progress events | src/engine/workers/coding-worker/events/ |
| Runtime worker loading | src/engine/capabilities/worker-loader.ts |