mirrors/agenticmail-agenticmail
Watch
1
0
Fork
You've already forked agenticmail-agenticmail
 0
mirror of https://github.com/agenticmail/agenticmail.git synced 2026-10-10 01:52:33 +00:00
Code Issues Projects Releases Packages Wiki Activity
Page: Roadmap
Pages
Architecture Current Milestone Home Host Integrations Integration Codex Integration Grok Build Integration Hermes Operator Guide Release Process Roadmap
3 Roadmap
Ope Olatunji edited this page 2026-05-15 00:46:22 -04:00
Table of contents

Roadmap

What we plan to ship next, in priority order. Items marked Researched have a written plan in this wiki (see Host Integrations). Items marked Planned are committed-to but unspec'd. Items marked Exploring are open questions where the design isn't settled.

Near-term (the next 2-4 weeks)

1. Multi-host integrations — 2/4 shipping

The Claude Code integration (@agenticmail/claudecode) was the reference template; Codex shipped 2026-05-14 with ~90% architectural reuse. Two more on the agenda:

  • ✅ @agenticmail/codex — OpenAI Codex CLI. Shipped at 0.1.5 (2026-05-15). Codex deliberately mirrors Claude Code's hook ABI (the Rust crate is literally named ClaudeHooksEngine) and ships an official @openai/codex-sdk npm package that's a near-direct analog of @anthropic-ai/claude-agent-sdk. ~90% architectural overlap delivered as predicted. See Integration: Codex.
  • ⏳ @agenticmail/grok-build — xAI Grok Build CLI (shipped 2026-05-14, closed beta behind SuperGrok Heavy). Announced to support MCP, sub-agents, plugins, hooks, and skills "out of the box." Schema confirmed via the community proxy superagent-ai/grok-cli since the closed beta requires a $300/mo subscription to validate paths. ~80% architectural overlap. See Integration: Grok Build.
  • ⏳ @agenticmail/hermes — Nous Research Hermes Agent (the runtime, not the Hermes model family). Python-native, first-class MCP, lifecycle hooks (richer than Claude Code's), delegate_task sub-agent primitive, importable Python SDK. Distribution: pip install hermes-agent-agenticmail. Already ships an "email" gateway adapter we'll need to disambiguate against. See Integration: Hermes.

The two remaining integrations share roughly 70% of the work with what's already shipped. Now that two host packages exist side-by-side, the @agenticmail/host-toolkit shared library has earned its keep — pulling the dispatcher core / catch-up scan / persistence layer / wake-budget / capabilities-blurb generator into one place before a third copy appears is the immediate next refactor.

2. Dispatcher hardening carryovers from 0.9.x

Items deliberately deferred from the 0.9.x cycle because they weren't actively breaking production:

  • Persist wake-budget across restarts. Currently the rate limiter resets when the dispatcher restarts. Move the budget into dispatcher-state.json so a runaway thread can't reset itself by crashing the daemon.
  • IMAP receiver pool. Today there's one ImapFlow connection per agent. A flood of message-detail clicks serializes on the mailbox lock. Add a small per-agent connection pool (2-4 connections) and a fair-share scheduler.
  • Receiver-cache eviction under memory pressure. TTL-based today; add a hard upper bound so an idle host with 100+ agents can't accumulate connections indefinitely.

3. Web UI polish

  • Real-time worker output stream — the activity badges show "agent is working" but not WHAT the agent is producing. The dispatcher already streams worker output to disk (~/.agenticmail/worker-logs/); surface a live tail per worker in the badge popover.
  • Search across folders — current search filters the rendered page. Add a server-side SEARCH route that hits all folders and returns a unified result list.
  • Per-folder unread badges in the sidebar. We track unread per agent (the profile dropdown counter) but not per folder.

Mid-term (1-3 months)

4. Cross-host coordination

Two-host coordination shipped in 0.9.20 — Claude Code and Codex now run side-by-side on one machine, each watching only its own teammates. The interesting question for the next phase: can a Claude Code agent and a Codex agent and a Hermes agent collaborate on the same email thread, each running in its own native host? Already-shipped infrastructure:

  • ✅ metadata.host field on every account ('claudecode' | 'codex' today, 'grok-build' | 'hermes' as those integrations land), auto-stamped by MCP create_account via AGENTICMAIL_MCP_HOST env var.
  • ✅ Dispatcher cross-host filter (shouldWatch) so each daemon only watches its own inbox.
  • ✅ Web UI host badges + per-host avatars so the operator can see which host owns which agent at a glance.

Remaining work:

  • A single multi-host PM2 ecosystem file the user can drop into ~/.agenticmail/ to spawn every host's dispatcher in one shot.
  • Health-check parity so check_activity shows "vesper (claudecode) — working" vs "orion (codex) — working" in one view (the metadata is already on every account; the activity registry just needs to surface it).
  • Cross-host thread audit trail in the web UI: visualize which host took each turn in a multi-host thread, so the operator can spot misrouting.
  • Tighten dispatcher's shouldWatch from "watch unclaimed" to "watch only mine" once telemetry shows the MCP env-var auto-stamp is universally present.

5. Persistent agent personas + role library

create_account({ role }) already takes a role string but doesn't do much with it. Plan: a curated library of personas (designer, developer, reviewer, researcher, writer, planner, executor, critic) with pre-written subagent.md system prompts, default wake_on_cc preferences, and recommended tool tier-loadouts. The host integration packages would auto-install these into the right host-specific location at setup time.

6. Inbound webhook surface

Right now you can route external email INTO an agent's inbox via Cloudflare relay or a Gmail alias. We want the reverse: agents subscribe to webhooks that fire on incoming mail with specific shapes (a Slack-bound thread, a calendar invite, a GitHub notification) and the dispatcher routes those to the right pre-configured agent automatically.

7. Voice + SMS via the gateway

The MCP toolbelt already includes sms_send, sms_messages, sms_check_code, sms_record, etc. The dispatcher doesn't wake on SMS yet — only mail/tasks. Plan: add SMS as a third event class on the per-agent SSE channel, with the same dedup/budget primitives we have for mail.

Longer-term (3+ months) — Exploring

8. Federation / multi-host operator mode

For teams (or operators running AgenticMail for multiple users): a federation model where AgenticMail instances on different hosts can route between each other over standard SMTP. Each instance's accounts get a real domain (already supported via purchase_domain and Cloudflare relay), and inter-instance traffic flows through normal mail transport. Agents on host A can email agents on host B without any special API.

9. Cost + budget accountability

Each Claude/Codex/Grok turn the dispatcher spawns costs money. Today we surface no budget primitives. Plan: per-account spend tracking (token counts in the worker registry → cost estimates), per-thread budget caps (separate from the wake-rate cap), and a /system/budget endpoint surfacing "this account is at $X today, capped at $Y."

10. Persistent memory tier 2

AgentMemoryStore is per-(agent, thread) markdown. Agents save memory at end-of-turn via save_thread_memory. There's no GLOBAL agent memory (cross-thread, durable knowledge about the world). Tier 2 would add a vector store keyed by agent ID with semantic recall surfaced in the wake prompt.

Won't-do (explicit non-goals)

  • A hosted SaaS version. AgenticMail is intentionally self-hosted; the security model assumes the operator owns the box.
  • Web UI as the primary surface. The agents-coordinating-via-email model is the product; the web UI is a debugging / monitoring affordance, not the main UX. Native hosts (Claude Code, Codex, Hermes, Grok) are the primary surface.
  • Compatibility with closed-loop "agent platforms" that don't expose tool calling / MCP / hooks. If the host doesn't let us register an MCP server AND a lifecycle hook, the integration isn't viable.