Skip to content

Product · the work plane

The half that is not the access map

Most of this site is about what an agent can REACH. This page is about how agents and sessions coordinate the work itself — and about how far each piece actually reaches today.

Why it exists

Governance without a work plane is a dashboard with nothing to act on

Olivares AI has two halves and they ship in the same binary. One runs and connects the work; the other sees and governs it. Neither is decoration for the other — a work plane without governance is work nobody can account for afterwards, and governance without a work plane is a dashboard with nothing to act on.

The problem this half exists for is not hypothetical. It is the one this project spent its own development suffering: sessions that cannot see each other, state that diverges between them, work done twice, and decisions that live in one terminal and are lost when it closes.

What is real, and what is not

Each piece, with the reach it actually has

The boundary is enforced in code rather than promised in prose. Where a piece is narrower than the idea, the narrowing is stated here and a test holds it there.

Work items

Live, public API

A unit of work with a brief, provenance, dependencies, acceptance criteria, decisions, an owner and its own event history — durable, and driven by one command document shared by REST, the CLI and in-process callers.

modules/sessions/work_model.go · modules/sessions/work_api.go

Leases

Live, public API

Ownership as a fenced, expiring authority: acquire, renew, release, take over, revoke. A stale holder cannot keep acting on a work item, and concurrent acquisition yields exactly one winner.

modules/sessions/work_lease.go

Messages, acknowledgements and handoffs

Live, deliberately scoped

Durable conversation bound to a work item, with replay and stale-epoch rejection. The acknowledgement is the part worth pausing on: coordination breaks far more often because a message was seen and not acted on than because it was never delivered, and "read" and "answered" stop being the same word.

Real WITHIN an orchestration workflow. The general, cross-everything inbox is deliberately not wired, and that is enforced rather than promised: a boot test pins the authority sources boot binds, and their order, and fails on any of the four known preparatory activations. It is not an exhaustive allowlist — a future path with a different selector would need its own case — but wiring any of the wired-up ones by accident is a red test, not a surprise in production.

modules/sessions/communication_model.go (the shapes) · communication_ack_service.go and communication_ack_apply.go (the acknowledgement path and its epoch checks) · cmd/olivares/communicationauthorityboot_test.go (the boot test that keeps the public plane unwired)

Launch for work

Live, deliberately scoped

Reserve, take the lease, and only THEN spawn the session — persisting work, epoch, fence and execution so a retry is safe rather than a second run.

Through orchestration, not as a free-standing entry point.

modules/sessions/runtime_work_launch.go

Remote execution over A2A

Live, deliberately scoped

Plan, test, start, observe and cancel work on an authorized peer, with durable receipts for what was delegated and what came back.

Mounted ONLY when a destination is configured. With no authorized target the seam is not mounted at all — there is no path that dispatches work to an arbitrary peer because a configuration file asked nicely.

cmd/olivares/wire.go · cmd/olivares/orchremote.go

Shadow mode and final work authority

Not built

Dual-report against the system you already run, with a comparator, before this plane becomes the one that decides.

NOT "coming soon" and not "partial": absent. A deployment cannot today hand the work plane the last word over a session, and nothing in the product should be read as offering that. When it exists it will arrive with the evidence that it works — a comparison window against the existing sources, not a version bump.

design only

How to read this page

The honest version of “agents that talk to each other”

Work items and leases are ordinary API surface you can drive today. Conversation between agents is real and durable but scoped to an orchestration workflow — there is no general message bus for arbitrary agents. Remote delegation works, and refuses unknown peers.

What does not exist is not listed as coming soon in the interface. It is listed above, as absent. The alternative would cost you the afternoon you spent discovering it at integration time, which is the kind of claim this project refuses to make — see the Trust Center and how Claude Code is governed.