Skip to content

roadmap.md

Latest commit

 

History

History
150 lines (127 loc) · 7.91 KB

roadmap.md

File metadata and controls

150 lines (127 loc) · 7.91 KB
Raw

Roadmap

Product stages (what a user can do) map onto engineering phases (what ships in the crate). Each phase is independently shippable and leaves main releasable. Terms: glossary.md.

Stage 0 — Host (today)

The current state: a thin Axum host (/healthz, /spec, /tiny), a clap CLI, a cargo shell-out launcher for OpenHuman, and 18 example companies whose agents.toml manifests are printed but not executed.

Stage 1 — Company of One

An Operator boots a real company from a manifest and works with it daily.

  • Phase 0 — Spec + manifest. This spec; src/company/manifest.rs parses company.toml/agents.toml with validation; opencompany check <dir> lints manifests. Examples stop merely printing TOML.
  • Phase 1 — Kernel + fs store + stub brain. src/ports/ traits, file-based default stores, CompanyRuntime/CycleRunner, event log, operator chat route backed by a single-call stub Brain (via TinyAgents) so the plumbing ships and is testable offline.
  • Phase 2 — Hosted Medulla brain. HostedMedullaBrain speaking the /orchestration/v1 wire contract: HTTP event ingestion plus the Socket.IO effect/device-tool channel. Compressed traces land in MemoryStore; budget ledger starts. Requires a TinyHumans credential (runtime/config.md).
  • Phase 3 — Tools, channels, approvals via OpenHuman. ApprovalGate mapped to OpenHuman policy tiers; cron schedules; the feedback loop files its first GitHub issues. Delivered by a revised route: rather than ToolProvider/ChannelAdapter over JSON-RPC to openhuman-core serve, the harness embeds openhuman_core as a library (AgentBuilder) — one openhuman Agent per manifest [[agent]], with memory, inference provider, tools, skills, and approval policy injected through the builder's seams (integrations/openhuman.md). The JSON-RPC launcher/wire path is legacy (behind openhuman-rpc).

Stage 2 — Public Company

The company earns: it is discoverable and hireable on tiny.place.

  • Phase 4 — tiny.place economy. TinyplaceEconomy adapter (crate tinyplace): keypair identity, handle claim, Agent Card publish, inbound /a2a/{handle} with SIWX verification and x402-priced skills, outbound hiring under [budget] caps, delegated signers.

Stage 3 — Learning Company

The product improves itself and companies remember.

  • Phase 5 — Platform mode. Multi-company registry, POST /api/v1/companies provisioning, per-company auth, sqlite store, the operator-pluggable store guide, export/import migration between local and hosted.
  • Phase 6 — Memory maturity + alternate brains. TinyCortex MemoryStore / ContextStore implementations; SidecarBrain; feedback triage agent; Signals and the Opportunity Engine arrive as a venture-studio Template, not kernel code.
  • Phase 7 — Agentic setup + Manager. The agentic company: the Architect's Blueprint flow generalizes the onboarding interview (its conversational core can ship as early as Phase 2, since it only needs the hosted brain); the Manager tick and the Change Proposal pipeline land on top of approvals and the event log. Templates become the Architect's priors and the offline fallback.

Stage 4 — Venture Factory

The AVI vision: autonomous opportunity discovery, venture spawning, compounding knowledge graph. Horizon, not commitment.

Delivered by the console/API train (WS1–WS8)

The implementation train tracked in docs/plans/ landed the console-facing surfaces of Stage 1 plus the platform-mode reads/writes that Phases 3/4/5 anticipated. What is now real:

  • Read plane (GraphQL). Every console view fetches from /graphql, rooted at a Company aggregation object, built once at startup (runtime/api.md): team, desks/chats, inboxes, tasks, skills, workspace, memory facts, workflows, usage, finances, connections, domain, and SMTP status.
  • Write plane (REST). The src/server/ops/ router family (dual-scoped /api/v1/companies/{id}/… and /api/v1/company/…) writes tasks, memory facts, workspace files, skills, team overlays, inbox read-state + ingest, and — under their features — connections (OAuth), custom domain/DNS, and SMTP credentials.
  • Harness (Phase 3). openhuman_core embedded as a library; approval policy mapped 1:1 onto its security tiers.
  • Metering (Phase 4/5 surfaces). A UsageMeter port + a pure usage/finances projection back the Usage and Finances views. Partial: real inference cost awaits the upstream usage-accessor PR (tinyhumansai/openhuman#4940); until it lands the cost hook records a zero-usage turn (integrations/openhuman.md).
  • Storage (Phase 5). sqlite and mongodb backends implement the full port set; the mongodb backend is the multi-tenant platform store (runtime/storage.md).

Still deferred: SSE surfaces (/chat streaming, /events work feed) remain request/response for now; team overlays are roster-only in v1 (operator-added teammates get no harness Agent yet).

Candidate upstream workstreams

Documented here, executed as PRs against the owning repos — never forked locally:

  • TinyHumans backend: API-key authentication for headless hosts (today: session JWT only); company-scoped orchestration v2 (multi-company routing, richer effects, tool namespacing) — see integrations/medulla.md.
  • OpenHuman: headless multi-workspace mode; library-crate split of the tool/channel/credential domains (realized — the harness links openhuman_core directly); a public turn-usage accessor (tinyhumansai/openhuman#4940) so a host crate can read real token/cost totals after a turn; external approval hook; namespaced credentials; documented /events schema — see integrations/openhuman.md.

Non-goals

  • Not a model host. Medulla and all model routing are hosted by TinyHumans; no local-LLM or BYO-model support.
  • Not a general agent framework. openhuman_core (embedded as a library) is the harness; OpenCompany grows no graph engine of its own. (TinyAgents remains an optional StubBrain for offline tests only, not the harness.)
  • Not a fork of OpenHuman. Gaps go upstream as PRs.
  • Not multi-human companies. Exactly one Operator per Company.
  • Not the AVI venture factory (yet). No autonomous opportunity discovery or venture spawning; vision/ only.
  • Not custodial finance. No fiat, no custody beyond the delegated-signer model; x402 USDC only.
  • Not a legal-entity service. Incorporation, tax, and compliance stay with the human.
  • No private feedback backend, and no telemetry from an install that did not ask for it. Feedback goes to public GitHub issues or stays local, and never rides any other channel. Product analytics (runtime/analytics.md) is a separate and deliberately narrow thing: shape and outcome only — counts, durations, enum-valued fields — never message text, prompts, file names, ledger values, tool arguments or addresses, under an opaque id rather than a company name, and only for tenants the hosting platform provisions and operates. A desktop or self-hosted default build sends nothing and cannot: the network client is behind a cargo feature that build does not compile, and leaving that state takes a recompile plus an explicit OPENCOMPANY_ANALYTICS=on rather than anything a shipped binary reads at runtime. That gate is also what keeps the offline lane (runtime/offline.md) honest.
  • No prosumer-visible runtime internals. UI or product text exposing "agent graph", tiers, or dispatch is a spec violation (glossary, translation table).