Objective
Design a governed Actor Bus layer that lets LifeOS actors communicate across COO, EA, and AA roles, with Oracle as the first Advisory Agent (AA) adapter for ChatGPT/Gemini/Claude consults.
This is the missing layer above the current COO↔EA work. The target is not a free-form direct mesh. The target is a policy-mediated actor bus where every actor can message other actors, but command authority remains constrained by LifeOS governance.
Background
Related work:
#62 covers the COO→EA execution path. This issue covers the broader communication layer needed for COO↔AA, EA↔AA, AA↔COO, and future actor-to-actor coordination.
Oracle reference:
Relevant Oracle capabilities:
- Bundles prompts and files for model consults.
- Supports GPT, Gemini, Claude, and multi-model runs.
- Supports API mode, browser mode, manual copy fallback, and session replay.
- Provides MCP tooling (
consult, sessions) for Codex/Claude-style agents.
- Supports Windows-hosted browser session bridging to Linux clients, useful for current LifeOS operating setup.
Core design position
Oracle should be treated as an AA adapter, not as the LifeOS architecture.
Correct invariant:
Every actor may message every other actor.
Only authorised actors may command other actors.
All commands become typed requests on a governed bus.
All outcomes require validated receipts.
Direct all-to-all command/control is forbidden because it would break the authority model.
Target actor model
| Source |
Target |
Allowed meaning |
| CEO → COO |
command |
Authoritative instruction |
| COO → EA |
dispatch |
Governed execution request |
| COO → AA |
consult |
Advisory model call |
| EA → COO |
receipt/status/blocker |
Evidence, not authority |
| EA → AA |
consult |
Advisory assistance while executing |
| AA → COO |
recommendation/challenge |
Advisory only |
| AA → EA |
proposed instruction |
Must route through COO/policy gate |
| AA → AA |
cross-check |
Allowed only if budget/policy permits |
Hard rule:
AA → EA direct execution is forbidden.
AA → COO → EA proposal path is allowed.
Proposed architecture
CEO / User
↓
COO Orchestrator
↓
Actor Bus
├── EA Adapter: Codex
├── EA Adapter: Claude Code
├── AA Adapter: Oracle → ChatGPT
├── AA Adapter: Oracle → Gemini
├── AA Adapter: Oracle → Claude
└── future adapters
The Actor Bus owns:
- Actor registry
- Message envelope schema
- Routing policy
- Idempotency keys
- Attempt IDs
- Budget enforcement
- Authority checks
- Receipt validation
- Loop prevention
- Audit storage
Oracle is one transport adapter under the bus.
Proposed schemas
actor_message.v0
Canonical envelope for all actor-to-actor communication.
schema_version: actor_message.v0
message_id: msg_...
correlation_id: corr_...
parent_message_id: null
source_actor: coo.hermes
target_actor: aa.chatgpt.pro
intent: consult
authority_class: advisory_only
requires_response: true
idempotency_key: ...
budget:
max_cost_usd: 5
max_runtime_seconds: 3600
max_context_files: 20
context_refs:
- github_issue: 62
- repo_path: docs/...
payload_ref: artifacts/actor_bus/msg_.../prompt.md
expected_receipt_schema: aa_receipt.v0
status: queued
created_at: ...
aa_receipt.v0
Advisory-agent equivalent of the EA receipt.
schema_version: aa_receipt.v0
message_id: msg_...
attempt_id: aa_attempt_...
target_actor: aa.chatgpt.pro
transport: oracle
engine: api | browser | copy
model: gpt-...
oracle_session_id: ...
status: succeeded | failed | blocked | timed_out
output_ref: artifacts/actor_bus/msg_.../answer.md
output_hash: sha256:...
structured_output_valid: true
cost:
estimated_input_tokens: ...
estimated_output_tokens: ...
estimated_usd: ...
blockers: []
created_at: ...
Invariant:
An AA answer is never authority. It is evidence/advice attached to a COO decision.
Proposed actor policy shape
schema_version: actor_policy.v0
actors:
ceo:
class: human_authority
coo.hermes:
class: orchestrator
ea.codex:
class: execution_agent
ea.claude_code:
class: execution_agent
aa.chatgpt:
class: advisory_agent
aa.gemini:
class: advisory_agent
aa.claude:
class: advisory_agent
edges:
ceo -> coo.*:
intents: [command, approve, reject]
coo.* -> ea.*:
intents: [dispatch, status_query, retry]
requires: [delegation_envelope_check]
coo.* -> aa.*:
intents: [consult, review, challenge, compare]
requires: [budget_check]
ea.* -> aa.*:
intents: [consult]
requires: [task_scope_bound, budget_check]
aa.* -> ea.*:
intents: [proposal_only]
requires: [coo_gate]
aa.* -> coo.*:
intents: [advice, objection, blocker, review_result]
Oracle adapter sketch
Minimal API-mode invocation shape:
oracle \
--engine api \
--model gpt-5.4-pro \
--slug "$ATTEMPT_ID" \
--write-output "artifacts/actor_bus/$MESSAGE_ID/answer.md" \
-p "$(cat artifacts/actor_bus/$MESSAGE_ID/prompt.md)" \
--file "docs/**/*.md"
Browser/Pro-account mode shape:
oracle \
--engine browser \
--browser-manual-login \
--browser-auto-reattach-delay 30s \
--browser-auto-reattach-interval 2m \
--browser-auto-reattach-timeout 2m \
--slug "$ATTEMPT_ID" \
--write-output "artifacts/actor_bus/$MESSAGE_ID/answer.md" \
-p "$(cat artifacts/actor_bus/$MESSAGE_ID/prompt.md)" \
--file "docs/**/*.md"
MCP route:
- Install Oracle MCP in Codex/Claude Code.
- Expose
consult and sessions as advisory tools.
- Persist all advisory outputs through the same
aa_receipt.v0 path.
Proposed split from #62
Recommended sequencing:
#62 = COO→EA automated dispatch pipeline
this issue = Actor Bus + AA consult lane
future issue = Oracle adapter proof
future issue = cross-actor policy matrix + schemas
First production-capable slice
Smallest useful slice:
COO can ask one AA for advisory review through Oracle,
store request/output/receipt,
validate receipt,
attach summary to GitHub issue,
and never treat the answer as authority.
Acceptance criteria for the first slice:
Risks and controls
| Risk |
Control |
| Authority confusion |
AA receipts marked advisory_only; COO remains decision point |
| Runaway model loops |
max hop count, max fanout, cost budget, per-correlation lock |
| Browser fragility |
API mode default; browser mode fallback; --copy manual fallback |
| Secret/session exposure |
no cookies in repo; local ~/.oracle; bridge token treated as secret |
| Non-deterministic output |
hash answer artefact; require structured response schema where possible |
| Cost explosion |
budget in actor_message.v0; no automatic multi-model fanout unless policy allows |
| Prompt injection through repo/docs |
context manifest + explicit system boundary in prompt template |
| False success |
receipt validation mirrors #61 pattern; no wrapper-exit success assumption |
Deliverables
Explicit non-goals
- Do not implement unrestricted actor mesh.
- Do not allow AA output to directly command EAs.
- Do not treat Oracle browser success as task success without receipt evidence.
- Do not make Drive/Workspace canonical for actor state.
- Do not change CEO/COO authority rules without separate governance approval.
Research note
This does not need Pro-level research before the first slice. The immediate implementation path is clear enough: schema → adapter → receipt validation → policy-gated routing.
A Pro-level research pass may be valuable later, after #62 and the first Oracle AA lane are proven, to compare long-term protocol options: direct mesh, brokered bus, MCP-only, A2A-style protocol, and GitHub-mediated control plane.
Objective
Design a governed Actor Bus layer that lets LifeOS actors communicate across COO, EA, and AA roles, with Oracle as the first Advisory Agent (AA) adapter for ChatGPT/Gemini/Claude consults.
This is the missing layer above the current COO↔EA work. The target is not a free-form direct mesh. The target is a policy-mediated actor bus where every actor can message other actors, but command authority remains constrained by LifeOS governance.
Background
Related work:
#62 covers the COO→EA execution path. This issue covers the broader communication layer needed for COO↔AA, EA↔AA, AA↔COO, and future actor-to-actor coordination.
Oracle reference:
Relevant Oracle capabilities:
consult,sessions) for Codex/Claude-style agents.Core design position
Oracle should be treated as an AA adapter, not as the LifeOS architecture.
Correct invariant:
Direct all-to-all command/control is forbidden because it would break the authority model.
Target actor model
Hard rule:
Proposed architecture
The Actor Bus owns:
Oracle is one transport adapter under the bus.
Proposed schemas
actor_message.v0Canonical envelope for all actor-to-actor communication.
aa_receipt.v0Advisory-agent equivalent of the EA receipt.
Invariant:
Proposed actor policy shape
Oracle adapter sketch
Minimal API-mode invocation shape:
Browser/Pro-account mode shape:
MCP route:
consultandsessionsas advisory tools.aa_receipt.v0path.Proposed split from #62
Recommended sequencing:
First production-capable slice
Smallest useful slice:
Acceptance criteria for the first slice:
actor_message.v0targetingaa.chatgpt, runner invokes Oracle.aa_receipt.v0is emitted.Risks and controls
advisory_only; COO remains decision point--copymanual fallback~/.oracle; bridge token treated as secretactor_message.v0; no automatic multi-model fanout unless policy allowsDeliverables
actor_message.v0schema proposalaa_receipt.v0schema proposalactor_policy.v0routing/authority matrixExplicit non-goals
Research note
This does not need Pro-level research before the first slice. The immediate implementation path is clear enough: schema → adapter → receipt validation → policy-gated routing.
A Pro-level research pass may be valuable later, after #62 and the first Oracle AA lane are proven, to compare long-term protocol options: direct mesh, brokered bus, MCP-only, A2A-style protocol, and GitHub-mediated control plane.