Intent Next

A memory-safe macOS control plane for reliable fleets of coding agents.

Comment

Inspiration

Coding-agent CLIs are powerful, but a single agent session is still a fragile place to run a serious engineering project. Context gets lost, parallel work collides, verification is often performed by the same agent that wrote the code, and a crashed process can take the state of the run with it.

We wanted the experience of giving one outcome to a trusted technical lead: it writes the spec, assembles the right team, keeps every specialist in bounds, gathers evidence, independently verifies the result, and can resume after a restart.

What it does

Intent Next is a local-first, memory-safe macOS control plane for coding-agent fleets.

Its durable workflow is:

Task → Spec → Coordinator → N Agents → Verification → Done or Redispatch

A user creates one task and selects a workspace, harness, model, effort level, connector policy, and optional custom specialist. Intent Next persists the task and shared spec, then gives a coordinator the tools to delegate bounded work to any number of developer and verifier agents.

Key capabilities include:

  • Provider-agnostic agents: run Codex, Claude Code, Pi, Grok, an offline mock harness, or a custom ACP adapter.
  • Three dependable roles: coordinator, developer, and verifier prompts are composed by the server; custom specialists can add domain behavior without changing role authority.
  • Durable N-agent orchestration: live concurrency is bounded, overflow work enters a persistent FIFO queue, and queued runs recover safely after restart.
  • Independent verification: verifiers receive an evidence-first contract and, on macOS, run inside a fail-closed Seatbelt profile that kernel-denies writes to the selected workspace.
  • A real Control Room: inspect the task tree, shared spec, fleet state, queued children, transcripts, evidence timeline, usage, terminals, checkpoints, and session controls from one native UI.
  • Safe process supervision: cancellation, circuit breakers, memory gates, bounded output, orphan reaping, PID ownership, graceful shutdown, and pause/resume behavior are implemented in Rust.
  • Reviewed connectors: optional MCP tools use canonical native executables, SHA-256 trust pins, Keychain secret references, and per-role enablement.
  • Portable evidence: tasks can be exported and imported as secret-scanned, hash-manifested .intentpack files.

Intent Next does not replace the coding models. It makes multiple external harnesses behave like one inspectable, recoverable engineering system.

How we built it

The canonical product is a Rust workspace with a Tauri desktop shell and React/TypeScript Control Room. The core is separated into crates for domain policy, ACP sessions, providers, supervision, durable storage, MCP, task packs, notes/specs, the authenticated local server, CLI, mock fault-injection agent, and the native app.

Harnesses communicate over ACP (Agent Client Protocol, JSON-RPC over stdio). The local Rust server exposes token-authenticated HTTP, SSE, and WebSocket boundaries to the UI. Persistent task, session, queue, report, and process-ledger state lets the orchestrator recover honestly instead of pretending a dead session is still live.

How we used Codex and GPT-5.6

We built Intent Next as an orchestration project using the same orchestration principles it productizes. Codex with GPT-5.6 acted as the primary coordinator and spawned parallel architect, implementation, test, and adversarial-verification agents with bounded deliverables and explicit done criteria.

Codex accelerated:

  • decomposing the product contract into independent Rust, ACP, supervisor, storage, UI, packaging, and verification lanes;
  • implementing non-trivial failure handling and generating targeted regression tests;
  • tracing cross-crate invariants such as queue recovery, process ownership, cancellation, and verifier isolation;
  • reviewing the exact integrated source tree and redispatching issues until the final independent review was clean;
  • keeping architecture, API, supervisor contracts, tests, and shipped behavior aligned.

GPT-5.6 was especially valuable for maintaining system-level context while specialist agents worked in parallel, and for reasoning adversarially about failure modes that happy-path demos usually miss.

Challenges we ran into

The difficult part was not spawning another process. It was making “N agents” dependable.

We had to distinguish accepted work from live concurrency, persist a complete queued request before returning success, prevent a recovered queue item from replaying twice, bind remote ACP sessions to both provider and workspace, and make shutdown terminate only the process tree Intent Next actually owns.

Verifier isolation also required a stronger boundary than a prompt. We added a macOS Seatbelt policy that fails closed if workspace write denial cannot be applied.

Finally, the UI had to present honest state. A queued task is not shown as a fabricated live session, and session actions stay disabled until a session truly exists.

Accomplishments that we're proud of

  • A packaged Apple Silicon macOS app and DMG, not just a browser proof of concept.
  • A complete local workflow from task and shared spec through parallel delegation, evidence collection, verification, and redispatch.
  • Full Rust workspace verification, including 99 server integration tests, plus 151 Node/UI tests and 25 browser end-to-end tests.
  • A four-worker, 20-minute orchestration soak completed 2,775 cycles with zero leaked child processes and bounded memory growth.
  • An independent final review of the integrated tree returned no findings.
  • MIT-licensed, documented architecture and contracts, with an offline mock agent so judges can exercise the core workflow without paid model credentials.

What we learned

Reliable agent orchestration is a systems problem, not a prompt trick. The most important primitives are durable state, explicit authority, bounded concurrency, independent evidence, honest recovery, and ownership of every process and capability.

We also learned that roles, harnesses, and specialists must remain separate concepts. A “verifier” is an authority boundary; “Codex” is a provider; a security specialist is reusable behavior. Keeping those axes independent makes the system understandable and extensible.

What's next

Next we will add a machine-enforced verifier-PASS transition before a task can enter Done, move MCP connectors from probe-only health checks into supervisor-owned runtime domains, complete accessibility and long-duration native certification, and ship a Developer ID signed and notarized macOS release.

Built With

Share this project:

Updates