Roadmap
This roadmap explains the public status of AgentHub capabilities. It is intentionally conservative: a capability is marked stable only after implementation, tests, docs, and visible verification evidence exist.
Current Line
The current public line is:
- AgentHub Home and docs are live public surfaces.
- Desktop, Web, Hub Server, Edge Server, and runtime adapters are active development surfaces.
- Local Desktop -> Local Edge -> runtime adapter preview is the smallest useful validation path.
- Feishu/Lark, Remote/Cloud Edge, and full Web + Hub + Edge routing remain in development until runtime evidence is complete.
Milestones
| Milestone | Goal | Public status | Current evidence | Gap before next status |
|---|---|---|---|---|
| M1 Local Pipeline | Desktop UI -> Edge -> mock run -> events | Preview-ready | Local preview path, Desktop mock, docs, and smoke-test shape exist | Keep screenshots and run-event evidence aligned with current Desktop UI |
| M2 Edge Persistence | Run state, artifacts, diff, event fanout | In progress | Run lifecycle, artifact/diff, and event contracts are documented | Need durable persistence proof, replay behavior, and failure-state tests |
| M3 Runtime Adapters | Claude Code, Codex, OpenCode, custom adapter contracts | Contract shaped | Adapter event vocabulary, profile boundary, and example contracts exist | Need public package boundary, compatibility policy, and real-runtime conformance tests |
| M4 Hub/Web Collaboration | Projects, devices, Hub sessions, Web routing, audit | In progress | Hub/Web responsibility split and Web Workbench boundary are documented | Need Web + Hub + authorized Edge routing evidence and audit screenshots |
| M5 IM Integration | Feishu/Lark messages, cards, H5/workbench, binding loop | In development | Integration boundary, webhook shape, and TokenDance ID ownership are documented | Need production ingress proof, queue handling, card actions, and binding failure coverage |
| M6 Remote/Cloud Edge | Device proof, relay/provisioning, remote workspace policy | In development | Product boundary and required evidence are defined | Need device identity, target authorization, relay/provisioning, workspace policy, and audit evidence |
Each milestone should carry four public-safe fields before it is promoted: owning repo or subsystem, latest evidence type, missing proof, and the next verification action. Private deploy paths, server inventory, and rollback steps stay out of this page.
Milestone Acceptance Checklist
| Milestone | Minimum acceptance | Failure states that must be covered |
|---|---|---|
| M1 Local Pipeline | Desktop connects to Local Edge; mock run emits structured events, transcript, diff/file, or artifact | Edge offline, runtime unavailable, workspace unauthorized |
| M2 Edge Persistence | Runs/events/artifacts are queryable and replayable; refreshing UI keeps critical state | Invalid event schema, missing artifact, timeout/cancelled |
| M3 Runtime Adapters | Each runtime has conformance examples, error mapping, and permission mapping | CLI missing, not logged in, unparseable output, permission denied |
| M4 Hub/Web Collaboration | TokenDance ID -> Hub session -> project/device -> authorized Edge target -> audit can be inspected | Unauthenticated, no project permission, target offline, unauthorized target |
| M5 IM Integration | Feishu/Lark event/card -> queue -> Hub task/action -> visible user state | Callback timeout, account not bound, duplicate event, card action failure |
| M6 Remote/Cloud Edge | Device proof, relay/provisioning, workspace allowlist, target authorization, and audit all hold | Relay failure, expired device identity, workspace denied, missing audit |
These checks do not require every capability to finish at once, but every public status promotion must point to matching evidence. UI alone does not promote backend status; API alone does not promote user-visible status.
Feature Status
| Capability | Status | Notes |
|---|---|---|
| Public website | Live | Product positioning, docs, SEO, llms.txt |
| Docs system | Live, expanding | Bilingual Markdown, sidebar, search, TOC, metadata |
| TokenDance ID entry | Integrated for site personalization | Not Hub API authorization |
| Desktop preview | Preview-ready | Local validation surface |
| Local Edge | Preview-ready for local flows | Requires workspace allowlist and runtime profile |
| Runtime adapters | Contract shaped | Public third-party SDK package not stable |
| Hub Server | In progress | Owns projects, devices, sessions, routing, audit |
| Web workbench | In progress | Hub-backed collaboration surface |
| Feishu/Lark | In development | Collaboration entry, not product login |
| Remote/Cloud Edge | In development | Not a stable public feature yet |
Not Yet Stable
Do not document these as generally available:
- Feishu/Lark production event ingress, queueing, card schema, and binding flow;
- Remote/Cloud Edge provisioning and device proof;
- full Web + Hub + Edge production E2E routing;
- database-backed Contacts, Docs, Tasks, Projects, and Settings workbench surfaces;
- public third-party Adapter SDK package and submission process.
Documentation Policy
Docs should use precise status words:
- Live: available on the public site or shipped user-visible surface.
- Preview-ready: can be run locally with documented verification steps.
- Contract shaped: implementation direction is clear, but public SDK/import paths are not stable.
- In progress: implementation exists but is not release-ready.
- In development: planned or being wired; do not promise availability.
When a feature moves forward, update the owning docs page, search index, dynamic sitemap/llms coverage if routes change, and changelog in the same PR.
Near-Term Documentation Focus
The priority is not to add more empty pages. The priority is to make the current pages usable:
- Quickstart, Installation, Desktop, Run Lifecycle, and Adapters should jointly support the local preview path.
- Hub/Web, Collaboration, and Feishu/Lark should clearly say what is in development and what evidence is missing.
- API, error codes, event envelopes, approval gates, and secret boundaries should be reusable by implementers.
- Design System, Visual QA, Release Checklist, and Deployment should form a release loop.
- FAQ, Troubleshooting, and Product Status should answer the public question: what can I actually use today?
Evidence Cadence
Use absolute dates in status updates. A useful roadmap update says what changed, what was verified, and what still blocks a stronger claim. Avoid relative phrases such as “recently” or “soon” because they age badly in public docs.
Suggested evidence fields for issue, PR, or release notes:
| Field | Example shape |
|---|---|
| Owner | AgentHub Desktop, Edge Server, Hub Server, Integration Gateway |
| Evidence | test output, screenshot set, event trace, route smoke, API contract check |
| Missing proof | persistence replay, permission denial state, Web routing audit, queue retry |
| Last verified | 2026-06-09 |
| Public wording | preview-ready, contract shaped, in progress, in development |