Skip to main content

Roadmap

What to build first, in order. Resist over-splitting and over-building.

MVP — build these first​

  1. Nexus Core in Rust with axum.
  2. MongoDB collections: agents, skills, tasks, runs, memories.
  3. Nexus UI: Agents + Skills + Board + Runs.
  4. Taiga adapter.
  5. Telegram command gateway.
  6. Kubernetes job launcher.
  7. One generic agent-runner container.

First useful command:

/nexus create goal "Build authentication system for my app"

Response:

Goal created.
Drafted 8 tasks.
Waiting for approval in Nexus UI.

Then in the UI: approve plan → create Taiga user stories → assign planner/implementer/tester agents → run Kubernetes jobs.

Repos for MVP​

Create only:

nexus-platform
nexus-agent-images
nexus-gitops

Add nexus-examples and split nexus-docs public later.

After MVP​

  • Memory retrieval upgrade — add a vector store (Qdrant / Atlas Vector Search) once text + tags hits its limits.
  • Blueprints — templates to stop repeating agent config.
  • Auto-approval for low-risk memory and actions.
  • Jira adapter — second BoardProvider.
  • More agent images — devops, solana, and language-specific toolchains.
  • Executable skills — tool / workflow / verification skill kinds beyond instruction skills.
  • SSE event stream wiring across the UI for live run logs.

Capability target — feature parity with Hermes​

A deep analysis of NousResearch/hermes-agent (agent isolation, communication, and the self-improving learning loop) and the concrete capabilities Nexus should add to be as robust — grouped into proposed tiers. Timing is undecided; this is the target spec.

→ Capability parity (Hermes gap analysis)

Two focused target specs drill into the highest-value areas:

  • → Goal lifecycle engine — turn the one-shot decompose into a staged pipeline (clarify → classify → decompose → replan → close) in a new nexus-orchestrator crate.
  • → Kanban board parity (Hermes) — the board feature surface specifically: task fields, live updates, dispatcher self-healing, and the command surface.

HARVEST (Solana accumulation) — live​

The on-chain treasury module is built and running (armed since 2026-08-29): laddered SOL/cbBTC accumulation, lending yield while waiting, JitoSOL staking and LP positions decided by an AI desk and executed by the nexus-solana venue service within mechanical caps.

→ HARVEST — as built — what runs, its contract, API, and what is still missing (start here)

→ HARVEST (design spec) — the target spec it was built from, annotated where the build diverged

→ Accumulation desk — repurposing the perp trading-desk + dream mobs into an intelligent accumulator that trades rebounds inside a bounded sleeve beside the ladder.

→ Measuring success — the USDT-NAV objective, return and attribution accounting, the benchmark suite and the scenario table the 2026-09-05 audit asks for (specified, not implemented).

Audit status registers live under Audits.

And an operational target spec that spans the whole fleet:

→ Monitoring & alerting — the UI redesigned around a fleet health grid, with rule-based Telegram alerting for every component.

Explicitly not yet​

  • GraphQL API (REST suffices).
  • Cursor-based pagination (defaults are generous).
  • Per-agent custom runner binaries (the generic runner is the whole point).