HAPI in the agent control-plane landscape (Happy, T3 Code, vendor IDEs)

[heavygee]

HAPI in the agent control-plane landscape (2026)

Companion to #1258 (ecosystem thesis) and #1332 (A2A RFC). The Happy-only FAQ remains #41 and Why HAPI?.

This is positioning, not a roadmap commitment. Facts are what ships today. Direction is only what has already been agreed in Discussions.

What HAPI is today (upstream)

HAPI is a local-first remote control plane for official coding agents:

• wraps Claude Code / Codex / Cursor Agent / Grok / OpenCode / ... instead of replacing them
• hub on your machine (SQLite, single binary); optional relay / self-host tunnels
• seamless local <-> remote handoff without restarting the agent
• multi-session hub, runner remote-spawn, web/PWA, Telegram
• permissions, terminal, files, and notifications while AFK

The public one-liner that still holds:

Your agents keep working on your machines while you stop being chained to the desk.

The landscape in one picture

Product class	Examples	Scarce resource they optimize	Stance toward native CLIs
Vendor verticals	Claude / Codex / Cursor ecosystems	Model + harness lock-in, cloud execution, org policy	Own the harness
Personal agent IDEs	T3 Code, Conductor-like apps, Codex desktop	One human's coding loop (threads, diffs, PRs, worktrees)	Drive CLIs from a GUI control plane
Managed remote sessions	Happy	Phone/remote access with centralized cloud storage	Remote window onto agents
Self-hosted session hub	HAPI	Continuity + multi-session ops on machines you own	Native-first; hub coordinates

Same niche on a store shelf. Different jobs.

Happy (closest historical sibling)

Already documented: decentralized hub vs Happy's centralized encrypted store; plus HAPI's local/remote switch, slash commands, remote terminal, and richer tool rendering (#41, why-hapi).

Choose Happy if you want a managed multi-user cloud product.
Choose HAPI if you want data on your machine and a hub you operate.

T3 Code and personal agent IDEs (closest new peer)

T3 Code is an open-source agent harness control surface: Electron/desktop + native mobile + hosted web client pairing to your backend. Same bring-your-own subscriptions (Claude / Codex / Cursor / Grok / OpenCode). It is strong at:

• GUI-first threads and projects
• worktree-per-thread isolation
• per-turn workspace checkpoints / revert
• one-click commit -> push -> PR
• polished multi-environment remote (Tailscale, SSH launch, pairing)

HAPI is stronger when the unit of work is many native sessions on machines you own, not one personal IDE:

• terminal-native agents remain the primary workplace
• hub + runner as a multi-session / multi-machine control plane
• Telegram / PWA AFK approvals without adopting a second desktop
• collaboration path is hub-mediated (see A2A), not "nest everything inside one app"

Honest split:

• If you want Conductor / Codex-desktop energy, T3 is the gravity well.
• If you want fleets of real CLIs you already run, with phone/Telegram continuity, HAPI is the gravity well.
• Running both as daily drivers usually means two session identities and two ops models - fine experimentally, expensive as a lifestyle.

Where HAPI intentionally does not try to win

Community feedback on #1258 is useful here: HAPI's web/mobile UI will probably never match official TUIs or desktop IDEs, and that is fine. HAPI should remain the connection and coordination layer, not a second place that re-implements every MCP, skill, or tool the local agent already has.

So we should not compete with T3 on "best coding GUI." We should compete on continuity, ownership, and cross-agent coordination.

Direction already agreed in Discussions (not yet "the product")

From #1258 and the follow-up #1332:

• vendors build vertical agent empires
• HAPI's opportunity is horizontal fabric across them
• pragmatic first step: an Agent-to-Agent control plane
  • artifact-based handoffs (not endless model chatter)
  • route collaboration through HAPI so humans keep audit and interrupt control
  • unified work advertisements / receipts on a hub ledger
• Layer 0 already exists upstream (inspect_peer / ping_peer / session citations); Layer 1 is the durable work graph

From #691:

• a full conversational voice agent inside each coding session is the wrong long-term home
• build an attention / event layer first (for example: permission request > blocked > completion), then treat voice as one transport for that layer

That maps cleanly onto the landscape:

Cap	Vendor IDEs / T3	HAPI direction
Drive one agent beautifully	Strong	Good enough remote; native CLI remains primary
Many heterogeneous agents on owned machines	Secondary	Core
Cross-agent handoffs with audit	Inside one product, if at all	Hub A2A (proposed)
Attention across many sessions	Thread / project list UX	Event / attention substrate first

Kill criteria (so this stays engineering, not fog)

HAPI is winning the right game if, over the next year:

1. Users can keep preferring official CLIs and still get better AFK continuity than Happy-class tools.
2. A2A Layer 1 makes multi-session handoffs reconstructable (artifacts + receipts), not just chat pings.
3. An attention / event substrate exists before any heavier fleet-facing chrome.
4. We do not ship a second harness that re-owns skills, MCPs, and tools the local agents already provide.

HAPI is losing if we chase T3 feature-for-feature on desktop IDE polish, or if "horizontal fabric" becomes cloud multi-tenant Happy-with-extra-steps.

Ask

Does this framing match how you actually use HAPI?

• mostly single-agent remote continuity?
• multi-session coordination already?
• evaluating T3 / desktop IDEs for the coding loop while keeping HAPI for AFK?

Feedback welcome - especially corrections to the T3 / Happy rows from people who daily-drive more than one of these.

[bobleer]

I maintain BitFun, which sits awkwardly across your "personal agent IDE" and "self-hosted session hub" rows. The split feels real, but I don't think it has to create two session identities.

What made the overlap tractable for us was letting the runtime own session identity. Desktop and CLI are clients of that contract; the self-hosted relay moves commands and events for mobile control, but it does not become another harness that re-owns MCP, Skills, or tools. The UI can change without the task becoming a new session.

That makes your "horizontal fabric" direction feel right, but I think HAPI will need more than a remote window: stable session id, actor/client id, revisioned event cursor, and an artifact receipt for each handoff. Otherwise the moment a desktop IDE and HAPI both touch a task, chat history becomes the accidental source of truth.

The kill criterion I'd add: can a GUI/runtime hand a live task to HAPI and back without inventing a second session or replaying the transcript? If yes, the fabric is real. If not, users still pay the two-ops-model tax you called out.