[ product direction ]
Explain: the product roadmap
From isolated agents
to AI employees.
A common isolated runtime and installed-host onboarding first. Then coding-agent acceptance, employee profiles, controlled business connections, durable workflows and a company console.
Planning baseline 2026-10-05 · GitHub snapshot · Source e21be47 · Read as Markdown
Delivery stages
M01–M02
Runtime & coding acceptance
Planned- M01Add an agent on an installed host without changing security code
- M02Two different agents perform repository work inside the same enforced boundary
M03–M04
Employees & isolated contexts
Planned- M03Manage people, teams, personas and permissions
- M04One employee can safely perform many roles
M05–M07
Connections & collaboration
Planned- M05Controlled business access and external effects
- M06Useful coverage of everyday company programs
- M07Autonomous multi-step work with human participation
M08–M10
Operations, console & release
Planned- M08Observable and recoverable unattended operation
- M09One place to manage employees and business work
- M10Clearly documented, tested support and upgrades
How to read the status
Planned and in progress describe work tracking. Completed means the milestone is closed. Verified needs acceptance evidence; released needs a published release. Closed issue counts describe tasks, not a percentage of product readiness. This is a dated snapshot; GitHub carries the latest work status.
Explain: Common isolated runtime and simple onboarding
Explain Common isolated runtime and simple onboarding with
Common isolated runtime and simple onboarding
Add an agent on an installed host without changing security code.
Delivery gates: Existing adapter foundation. These are dependencies, not calendar deadlines.
Acceptance criteria
- An installed-host fixture adds a generic image/command workload and a supplied
- Unknown versions/options, unpinned artifacts, forbidden mounts and unsupported
- CLI discovery and generated support facts agree with the versioned catalog;
- Existing consumers and state ownership remain compatible; mixed-version and
- No company service, OIDC, employee persona or new backend is required. Real
2 / 2 issues closed
Explain: Coding-agent acceptance and policy enforcement
Explain Coding-agent acceptance and policy enforcement with
Coding-agent acceptance and policy enforcement
Two different agents perform repository work inside the same enforced boundary.
Delivery gates: M01 contracts and onboarding. These are dependencies, not calendar deadlines.
Acceptance criteria
- Forged identities, labels, roles and tool paths cannot increase authority.
- Allowed jobs execute without per-call confirmation; prohibited effects do not.
- Duplicate IDs, oversized/full queues, disk failure and crash points preserve
- Existing broker streaming, cancellation, credential and Research boundaries
- Both coding references edit a repository and run its focused checks through
- Management-provider and optional worker work remains tracked here but does not
2 / 8 issues closed
- #106 · [P1] Define a provider-independent private management contractopen
- #108 · [P1] Support private SSH policy across Tailscale and Headscale managementopen
- #110 · [P1] Integrate the independent Research client and extraction fixes through a reviewed pinclosed
- #111 · [P1] Exercise the actual pinned Hermes and ZeroClaw runtime integrationsopen
- #113 · [P1] Harden worker queue claims, crash recovery and aggregate capacityclosed
- #116 · [M02] Enforce capability-specific admission for isolated agent runtimesopen
- #136 · [M02] Accept two coding agents through the common isolated runtimeopen
- #141 · [P1] Integrate selectable WireGuard and exit-node readiness evidence for Research egressopen
Explain: Company identity and employee editor
Explain Company identity and employee editor with
Company identity and employee editor
Manage people, teams, personas and permissions.
Delivery gates: M01, M02. These are dependencies, not calendar deadlines.
Acceptance criteria
- Different users can see and edit only their assigned employees/resources.
- Seeded persona and memory import safely; a changed profile is demonstrably
- Running tasks retain their revision. Concurrent edits, invalid native options
- Profile/role edits cannot bypass Nix ceilings or gain host authority.
0 / 1 issues closed
Explain: Employee contexts, memory and runtime acceptance
Explain Employee contexts, memory and runtime acceptance with
Employee contexts, memory and runtime acceptance
One employee can safely perform many roles.
Delivery gates: M02, M03. These are dependencies, not calendar deadlines.
Acceptance criteria
- One employee performs non-coding and coding tasks using different roles.
- Public contexts cannot read confidential memory, profile fragments or another
- Configured low-to-high transfers proceed automatically; unauthorized reverse
- A mock runtime cannot establish vendor acceptance. Unsupported adapters remain
0 / 2 issues closed
Explain: Connections, actions and event foundation
Explain Connections, actions and event foundation with
Connections, actions and event foundation
Controlled business access and external effects.
Delivery gates: M02, M03, M04. These are dependencies, not calendar deadlines.
Acceptance criteria
- Agents never receive provider tokens; revoked or wrong-resource connections
- Post-approval mutation, destination changes and malicious Git metadata cannot
- Duplicate/forged events do not create duplicate logical work or new authority.
- Tests cover rate limits, timeouts, partial responses and uncertain write results.
0 / 2 issues closed
Business integration catalog
Useful coverage of everyday company programs.
Delivery gates: M05; delivered in waves. These are dependencies, not calendar deadlines.
Acceptance criteria
- Acceptance per operation includes schema validation, scoped resources, pagination, rate-limit handling, authentication/refresh/revocation and effect recovery. A verified release requires an explicitly selected provider test-account exercise as well as local contract tests. New connectors may not introduce a general web transport or arbitrary credential-bearing endpoint access.
0 / 5 issues closed
- #122 · [M06] M06-A: Accept communication and scheduling connector operationsopen
- #123 · [M06] M06-B: Accept document and knowledge connector operationsopen
- #124 · [M06] M06-C: Accept work-management and development connector operationsopen
- #125 · [M06] M06-D: Accept customer and support connector operationsopen
- #126 · [M06] M06-E: Add reviewed business-system and SDK/OpenAPI/MCP extensionsopen
Explain: Tasks, processes and collaboration
Explain Tasks, processes and collaboration with
Tasks, processes and collaboration
Autonomous multi-step work with human participation.
Delivery gates: M04, M05; a verified event connector. These are dependencies, not calendar deadlines.
Acceptance criteria
- A mixed business workflow researches, processes information and performs an
- Roles can be arbitrary text; task execution is not tied to a coding profession.
- Allowed branches continue autonomously; approval waits are localized.
- Task/event deduplication, dependency failures and budget reservations survive
0 / 1 issues closed
Continuous operation and recovery
Observable and recoverable unattended operation.
Delivery gates: M04, M05, M07. These are dependencies, not calendar deadlines.
Acceptance criteria
- Acceptance includes dependency loss, repeated transient failures, hanging processes, reboot, quota exhaustion and fresh-host restore. Reuse existing recovery/backup foundations rather than replacing them unnecessarily.
0 / 5 issues closed
- #107 · [P1] Add optional Headscale enrollment and configurable tailnet preferencesopen
- #109 · [P1] Report management enrollment, readiness and recovery evidenceopen
- #112 · [P1] Add bounded application health checks and hung-agent recoveryopen
- #114 · [P2] Add Research and management readiness metrics with tested alert deliveryopen
- #128 · [M08] Restore consistent organization, employee, queue and connection stateopen
Complete company console
One place to manage employees and business work.
Delivery gates: M03, M05, M07, M08; released M06 connectors. These are dependencies, not calendar deadlines.
Acceptance criteria
- Acceptance includes accessible keyboard operation, login/session behavior, unauthorized object access, malicious content, long-running task states and honest unsupported/stale/unknown indicators. The console must make the difference between employee roles, runtime capabilities and technical rights understandable.
0 / 1 issues closed
Explain: Release, migration and operational acceptance
Explain Release, migration and operational acceptance with
Release, migration and operational acceptance
Clearly documented, tested support and upgrades.
Delivery gates: M01-M09 for the selected release scope. These are dependencies, not calendar deadlines.
Acceptance criteria
- Acceptance requires verified reference scenarios for an individual employee and a company workflow, corresponding documentation and examples, and recorded residual limitations. Distinguish source checks, simulated providers, real pinned runtimes, provider test accounts and production-host evidence. Do not assign a calendar deadline or version promise solely from this roadmap.