OSS Coordinator

Coordinator is part of the open-source engine. It is not a managed-only feature and does not require enabling it through the workspace UI. The workspace calls the same public assistance and fleet APIs that your program can call.

Your own agents continue running in their existing runtimes. Coordinator uses a model you configure to select permitted specialists, send different questions or tasks to them and summarize their replies. It is a communication coordinator, not a replacement runtime for those agents.

Configure and enable independently

1. Configure a server-side model provider, including DeepSeek or a compatible local endpoint.
2. Read assistance() and inspect overseer_configured.
3. Call update_assistance(overseer=True, version=current_version) as a person authorized to manage workspace assistance.
4. Call coordinate using that person’s credential.

The retained SDK/API name overseer means Coordinator. It is a compatibility name, not a second feature. An operator token is useful for setup, but Coordinator’s context and contact actions are still bound to the caller’s authorized person/fleet scope.

Automatic delegation

coordinate(prompt, key=...) can select multiple specialists and send different instructions to each without a review step. For example, ask Builder 7 to prepare a migration and DevOps 2 to check the staging window. The model proposes communication; the engine verifies the selected agents, operations and current policy before durable dispatch.

The returned plan identifies operation, context_agent_ids, sources, optional per-agent instructions, dispatches and current replies. A status operation can answer without dispatching. An accepted dispatch is not proof a specialist finished.

Optional review workflow

Use plan_overseer if your application wants to review before dispatch. Read the saved plan and confirm its id with confirm_overseer. The engine rechecks enablement, expiry and current authorization. It uses the saved plan rather than trusting an arbitrary instruction pasted into confirmation. Repeating confirmation reuses its dispatch.

overseer_plans lists the caller’s plans; overseer_plan reads one. Pass previous_plan_id for a permitted continuation. An optional target narrows the context to an agent or directory group. Read only currently authorized context; prior plans do not freeze old access forever.

Replies and summaries

Specialists reply through normal request/decision APIs. summarize_overseer collects currently authorized replies and returns an updated plan. Pending, failed and missing responses remain distinct. Inspect reply_summary, reply_digest and any summary_error; a summary is not independent verification or permission to run a business action.

Limits and failures

Configure the model explicitly; there is no implicit default paid provider. Model calls are bounded, with two concurrent assistance calls, a one-second per-person interval and a 1,000-call hourly process budget. SDK assistance calls allow a longer local timeout; your cancellation can be shorter.

The engine supplies bounded authorized context and validates structured output. Invalid/provider-failed plans send no instructions. Provider billing occurs on your selected account. Do not assume a transport error means a model call was free or unissued; retain operation keys and inspect saved plans before repeating an unknown result.

Coordinator cannot grant contact permission, change identities, approve a business action or bypass an agent’s tool safeguards. A compatible model must return the expected structured result; merely exposing an OpenAI-shaped URL is not a quality guarantee.

Python Coordinator example · TypeScript Coordinator example · Go Coordinator example · HTTP operations

---

Read this page as Markdown