A CEO with scoped authority.
The CEO is a native AI role that can use permitted DELEGATOR tools. Its useful behavior depends on the capabilities and grants actually available.
What has been demonstrated
On 22 October a finite native Codex turn used ordinary MCP to read the scoped board and post an attributed report. On 23 October further finite turns produced an authentic reply and a fresh board assessment, each with a verified stored report. The owned processes ended and the temporary actors were revoked. These are real native experiments, not a continuously running service.
In that read/report scope, the CEO can identify a gap, explain the evidence and name the responsible next actor. Posting a recommendation does not implement its fix, delegate a child, accept a task or prove a recipient consumed the note.
The intended working behavior
- Inspect current project tasks, linked sessions and evidence.
- Reconcile an existing task before creating another for the same gap.
- Perform an available, permitted action when it can; otherwise give a concrete recommendation, blocker or question.
- Choose a bounded continuation or a fresh session with a durable handoff when the outcome or context calls for one.
- Respect native permissions, allowance and the project’s concurrency limits.
This is the accepted direction. General automatic reconciliation, managed code execution and delegation still require product implementation and verification.
Permissions and limits
The policy is one autonomous child per project and no grandchildren, with scoped grants, native permissions and allowance holds. The proven finite MCP route uses normal native provider permissions and server-side board authorization. A custom custody or attestation framework is not a prerequisite for the first read/report proof.
An account’s reset time or remaining allowance must come from supported current evidence; it is not inferred from a calendar or a device heartbeat. A finite permission does not renew an earlier scheduler or authorize an indefinite loop.
Can the CEO start a chat on my Desktop?
The supported native provider building blocks can create or message conversations. The remaining product work is to route an authorized request through DELEGATOR to the enrolled destination client, use its local native endpoint and return the right receipts.
- DELEGATOR accepts the specific request.
- The destination’s native provider creates or locates the chat.
- The native session actually replies.
- The chat is separately visible and opens correctly in Desktop.
Not yet a generally available route. A desktop chat created by an explicit owner bridge does not prove autonomous worker-to-Desktop messaging. Repeated requests must reconcile to the original request before another chat is created. The fresh board assessment was delivered through an explicit owner bridge; this does not establish a client-routed Desktop push.
Notifications and reconnect
A client notification or reconnect can synchronize accepted state. It does not replay a model turn, prove a note was read or wake a native AI automatically. Recurring CEO timers and event-driven delegation are not claimed shipped.