AMBIENT AGENTS · WORKING DOCUMENTS · PART 1 OF 3 · 5 MIN

The blocking task

Source article for ambientagents.net regeneration. Author: Jeff Sylvan. Items marked [FILL] or [CONFIRM] must be resolved by me before anything derived from this ships.

The pipeline works. That's the problem.

Since [CONFIRM: early 2026] I've been building Black Skies solo: a real-time multiplayer tactical space card game with a design target of 10,000 concurrent players in one persistent battle space. I've shipped this genre before (Alteil Horizons, an online card game with its own distributed backend), so I know roughly where the bodies are buried. What's different this time is that most of the code is written by agents. The pipeline mixes Claude Code driving a forked spec-first framework (gsd-pi), Codex, and cloud coding agents [CONFIRM: current tool mix]. Task-level throughput stopped being my constraint months ago. Hand an agent a well-specified task and it comes back with a credible PR. That part is solved enough.

Worth being concrete about what shipping this genre used to cost, because it's the before picture. Alteil Horizons took a funded company: [CONFIRM: dozens of] people working under me, B2B money, and a Kickstarter to get it over the line. And here's the part that took me a decade to see clearly: most of what that team absorbed wasn't typing. It was deltas. Design changes fanning out into task lists, bug reports invalidating assumptions mid-sprint, the publish schedule drifting from reality. Producers, leads, and QA triage were a reconciliation loop, run on humans, and they earned their pay doing it. Black Skies is a harder target than Horizons was [CONFIRM: the honest axis, e.g., one persistent battle space at 10,000 concurrent players versus session-scoped play] and the headcount is one. Agents replaced the hands. Nothing replaced the coordination layer. The gap between those two sentences is the product. One asymmetry stays on the table: Horizons shipped and Black Skies hasn't yet, which is exactly why this site is framed as an experiment with a kill date instead of a victory lap.

Here's what a normal week does to the plan instead. I ratify a design change to the engine's fan-out path. Three in-flight tasks were written against the old interface and don't know it. A reviewer flags a real defect in a PR, which spawns rework that should preempt two queued tasks. Six GitHub issues arrive: two are duplicates of things already fixed, one quietly invalidates an assumption inside a mission that's currently executing. My working architecture document and the published devblog drift apart again, and the alignment matrix between them grows another row.

None of that is code generation. All of it is plan maintenance. Every delta partially invalidates a DAG of planned work, and every tool I use keeps cheerfully executing the stale version until a human re-plans. That human is me. I automated the typing and became the scheduler. For a solo founder, plan freshness is the blocking task.

Naming the pattern

The shape of the fix is familiar from infrastructure. Kubernetes doesn't run scripts. It reconciles observed state toward desired state through a control loop: a watch stream of events, a declared desired state, and a controller that closes the gap.

Apply that to development work. The plan graph is desired state. The delta queue is the watch stream: GitHub issues, PR reviews, ratified design documents, roadmap changes, budget events. The orchestrator is the controller. It consumes deltas, mutates the DAG at safe points while work is in flight, and dispatches ready nodes to whichever runtime fits them.

The distinction that matters: task-level automation reacts when a trigger fires. Plan-level reconciliation decides what that trigger means for everything else in flight. Those are different products, and the first one is already crowded.

Why the existing tools don't do this, and mostly can't

Task-level triggering is being commoditized as I write. Cursor's Automations configure always-on agents with GitHub and Slack triggers from a plain-language description. OpenClaw grew from a viral personal assistant into a runtime with durable multi-step flows, a unified task ledger, and multi-agent workflow definitions. OpenHands and GitHub's Agent HQ host and assign agents against repository events. All of it is real, all of it is useful, and all of it reacts at the task level.

None of it mutates a live plan, and structurally none of it can, for one reason: re-planning is only meaningful if you have authority over all in-flight work, and no vendor governs its competitors' agents. Cursor can't preempt a Claude Code session. OpenClaw's task ledger doesn't see Cursor's cloud agents. The seat above the runtimes is empty because every vendor is disqualified from sitting in it.

Four capabilities live in that empty seat. Cross-runtime authority: one plane that can dispatch, budget, preempt, and kill work regardless of which vendor executes it. Adversarial verification as a blocking gate: cross-model-family review with dissent capture that can hold a merge, not best-of-n sampling inside one harness. An economic control plane: global budgets, kill authority, and reentrancy guards across vendor bots that each only police themselves. And one human-in-the-loop inbox: park-for-days semantics tied to durable workflows, with decision requests aggregated fleet-wide instead of scattered across per-tool sidebars.

This is the same positional logic as Temporal versus each cloud's native workflow service. A neutral layer, not a feature. The honest corollary: it's a position, not a technical moat, and the price of holding it is integration surface. Which is why events get consumed at the Git layer, where the vendors already converge, rather than through N proprietary APIs.

About the name

"Ambient agents" is LangChain's term, introduced in January 2025. Harrison Chase defines them as agents that "listen to an event stream and act on it accordingly," in contrast with chat agents that wait for a human message. The ecosystem built on that: event-driven initiation, background operation, human-in-the-loop checkpoints through an agent inbox.

My system deviates from that definition at exactly one point, and the deviation is deliberate. You start it in the foreground: you compile explicit intent into a campaign. But the artifact that compilation emits is a standing ambient system: event subscriptions, handlers, budgets, human gates, kill authority. Launch is the bootstrap, not the product. The system you're left with listens, reconciles, and interrupts you only at gates.

You don't build ambient agents. You compile them.

Status, honestly

This is a design in progress, not a product. The site is the spec, and the spec is public because writing it in public keeps it honest. Black Skies is the design partner and the test harness: every pattern in the catalog was extracted from real interventions on a real project, not imagined from a whiteboard.

The dogfood campaign has a hard date of [CONFIRM: January 2] and a defined kill condition. The measurements that decide it: interventions per week before and after, and the quality delta with the adversarial review gate on versus off. And the falsifier, stated up front: if one vendor's best agent, run well, beats the governed fleet on those numbers, then this product reduces to a feature in someone's changelog, and I'll say so. The measurements get published either way.

References