Roadmap
This roadmap describes the public status of AgentHub capabilities. It is intentionally conservative: a capability is marked stable only when implementation, tests, docs, and visible verification evidence all 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 are out of scope for 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 be completed 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 MDX, 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 in progress; do not promise availability.
When a feature moves forward, update the owning docs page and search index, sync sitemap/llms if routes change, and update the changelog in the same PR.
Near-Term Documentation Focus
The priority is not to add more empty pages, but to make the existing pages usable:
- Quickstart, Installation, Desktop, Run Lifecycle, and Adapters should jointly support the local preview path.
- Hub/Web, Collaboration, and Feishu/Lark should clearly state 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 poorly in public docs.
Suggested evidence fields for issues, PRs, 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 |