Skip to content

Roadmap

This page separates what works from what is next. The live plan, who owns which repository and what is waiting for whom are kept in HeyAira itself, in the open task tagged plan; this page is the public summary. A proposal stays a proposal until a HeyAira decision accepts it.

Where it stands (2026-10-04)

Working and verified in production:

  • Project memory and tasks over MCP for ChatGPT, Claude and Codex clients: continuity_context, memory_*, task_*, one address per project, OAuth 2.1 with PKCE.
  • Agents run tasks unattended. A task configured with a repository, a catalog agent and acceptance criteria is sent with workflow_send. The HeyAira Bridge on the owner's Mac runs Codex CLI or Claude Code in a sandboxed worktree; a separate verifier agent checks every criterion (unless the task sets verification to none); the worker corrects itself once if needed; the Bridge opens the pull request; the server checks it on GitHub and records CI; a CI failure on a pull request GitHub still shows open with the accepted head goes back to the agent or blocks the task with a reason; the phone gets a push for a blocked task. Several tasks run in parallel on one Mac. A re-sent or follow-up task starts on its pinned base without anyone tidying the Mac's working copy first.
  • Operations: Server Beat with an external watchdog and SES e-mail fallback, encrypted backups to R2 with freshness checks, retention in review-only mode.

The proof run on 2026-10-04: five real tasks at once and zero operator actions, four pull requests opened by the Bridge from the agents' accepted work (two after a self-correction), one task blocked with a reason and a push to the phone. Every agent pull request is still reviewed independently before merge.

See start here for the full list, architecture for the boundaries and task-version execution for the exact contract.

Now: stage 6, one execution path

Stage 6 leaves exactly one way to run agent work, the task version, and rewrites the documentation from what works.

  • Done on main: the task-version path is covered by tests and canaries; the inline-profile workflow_dispatch tool, the standalone execution routes and the legacy branches are removed from the code and contracts (POST /bridge/v1/executions answers 410 standalone_execution_retired); workflow_dispatch_catalog requires a task reference; dead broker code is removed.
  • In review: this documentation rewrite.

Records created by the retired paths stay readable.

What is still not one path: a task version can be sent with workflow_send or with the lower-level workflow_dispatch_catalog, and the Mac still needs its older /bridge/v1/pair registration and heartbeats next to enrollment, because every send checks the paired node (see Bridge project scope).

Next

Open work, in no fixed order. Each item is a HeyAira task; none of them blocks the agent loop that works today.

  • Server hardening: proof of key possession at Bridge pairing, a device bound per project, de-duplicated task-version snapshots, and safe parallel catalog writes.
  • OAuth consent that shows the project, the role and the exact grant before a code is issued.
  • Stricter verification. Independent reviews still find issues in work the verifier accepted; verifier instructions and criteria templates should catch more of them.
  • Backups: scheduled weekly restore rehearsals; retention stays review-only until the owner decides to let it delete.
  • iOS: more than one project in the app.

Not planned

  • Model routing or automatic choice of model. The task names its agent.
  • Agents that merge or deploy. workflow_send authorizes neither; merges are the owner's, deploys follow the DevOps procedure.
  • Storing conversation transcripts, source code or provider credentials in HeyAira. (Sending a task copies only the agent instruction files the catalog names, at most 60 KiB per agent.)
  • Bringing back standalone executions or inline-profile workflows.

History

Earlier plans are kept as history, not as the current state: MVP boundary, the FLOW-09 operating status, PROJECT_STATE.md in the repository, and the dated reports under docs/reports/.

Documentation rule

Every public behaviour change updates its source, tests, tool contract and the human and agent documentation in one pull request. This page changes when something ships or the order of work changes.