Roadmap
The Akan.js roadmap
Six milestones behind us — the first interface, multi-build output, a Bun-first stack, mobile and desktop packaging, the agentic surface, and the v3 agentic framework. Next comes an agent network across sessions, people and apps, Akan Cloud, context-side rendering as the step after SSR and CSR, and then Autopilot.
- Current stage
- v3 · Agentic framework
- Release
- akanjs 3.0.0
- Committed stages
- 2
- Proposed stages
- 2
- Next stage
- 01 · Agents across sessions, people and apps
- Then
- 02 · Akan Cloud
Stages so far
v1 · Interface
Conventions on a borrowed stack
NestJS, Next.js and Vite underneath, MongoDB by default. It proved that one business declaration could drive the server, the web and the data at once.
Multi-build · SSR / CSR / Server
One route, three outputs
A route stopped being a single artifact: server-rendered HTML for SEO, a client bundle for the app, and a server process, all built from the same source.
v2 · Bun-first
Bun-first, Akan-owned
Bun became the one runtime, Akan took over the lower framework layers, and SQLite became the first database. Fewer moving parts, one path from dev to production.
Mobile · iOS / Android
Mobile from the same page
The web build packages into iOS and Android, reusing the list-detail flows, overlays and context transitions the framework already ships.
Desktop · Linux / macOS / Windows
Desktop without a second codebase
The same workspace builds a desktop app for Linux, macOS and Windows, with the client bundle and screen transitions reused as they are.
Agentic · MCP · in-page agent
The surface opens to agents
Every signal became an MCP server and an in-page agent started driving the screen through the controls people already use. Agents reached the app without a second API or a second UI.
Committed stages
Decided. These are the next stages.
01 · Committed · session ↔ session ↔ app
Agents across sessions, people and apps
A v3 agent works inside one browser session. The next stage lets agents cooperate across sessions, across people and across apps — still stopped by the same guards.
- Session to session: hand a running task from one tab or device to another
- Person to person: invite an agent, or a teammate's agent, into your session with explicit, revocable consent
- App to app: an agent in one app calls another app's MCP server over OAuth, so apps compose through agents
- An audit trail for every action that crosses a boundary: who asked, which agent, what it touched
Real work spans more than one person and one app, and the guard model already knows who may do what.
02 · Committed · git push → production
Akan Cloud
A deploy target built for Akan: cloud.akanjs.com runs what akan build produces, with the operational pieces a small team should not have to assemble.
- A preview environment for every branch
- Managed DB with replication, backup and point-in-time restore
- Logs, traces and metrics from akan logs, in the browser
- Secrets and env managed beside the app
The framework already owns the build; owning the landing closes the loop from one line to a live product.
Proposed stages
Candidates under review. The order is a proposal, not a schedule.
03 · Proposed · SSR → CSR → context-side
Context-side rendering
SSR renders on the server, CSR renders in the browser, and context-side rendering assembles the screen for the person in front of it. Instead of declaring pages, the app ships a UI toolkit — components and tools — and an agent composes them into a user flow in real time.
- A UI toolkit of components and tools, with no page declared per flow
- Screens composed per context instead of routed per path
- Every generated control still behind the same guards, tools and audit trail
- The declared page as the fallback when a composition is refused
The agentic rendering step after SSR and CSR: the stack already exposes an MCP server and agent tools, so the next surface to generate is the screen itself.
04 · Proposed · issue → diff → reviewed PR
Autopilot
Autopilot stops assisting and starts developing the repository. Given an issue, it edits the code itself, works through the diff and drives the pull request — changing and extending features on its own, with a person reviewing the result rather than writing it.
- Issue-to-diff runs that edit the workspace inside the workflow allowlist
- Repo-level changes: new fields, endpoints, screens and migrations, not just patches
- Validation, abstracts and agent guides updated in the same run
- An evaluation suite on real workspaces, published every release
Strict conventions are exactly what let a repository engine change and extend features unattended and still leave a reviewable pull request.
One person, a whole product.
Every stage removes something a small team would otherwise build or run. The end state is a product — web, desktop, mobile, server, data and the agents working inside it — that one developer can own.