Gavin Bintz ← Writing
Writing · 02

The Black Hole Architecture

A guide to serverless, conflict-free agent loops using gravity, time, and strict separation of concerns.

Gavin Bintz 11 min read
For humans

Readable narrative version restored from the first complete draft.

A guide to serverless, conflict-free agent loops using gravity, time, and strict separation of concerns.

TL;DR: This architecture is a divergence in approaches from orchestrator models to true fully autonomous growing systems with no orchestration layer or human in the loop at all. You give a high level vision doc and system design—more high level than a PRD—and then step out of the way, letting agents define tasks themselves.

From Single Agents to Systems That Evolve

Early AI coding workflows treated the model like a very smart intern. You asked it to do something, it did its best, and you reviewed the output. That worked for small tasks, but it breaks down quickly once you try to scale beyond a single change at a time.

The industry responded with orchestration. Trees of agents, managers managing managers, state machines coordinating handoffs. Powerful, but brittle. Expensive to reason about. Easy to deadlock. Hard to debug.

The Black Hole Architecture is a rejection of that complexity.

Instead of coordinating agents directly, you design an environment that pulls work toward completion. Agents are stateless, disposable, and narrowly scoped. They wake up, observe the system, do one kind of thinking, leave artifacts behind, and disappear.

No central brain. No long-lived memory. No runtime coordination.

Just gravity and time.

Gravity as Architecture

The core idea is simple: the repo itself defines the future.

A strong Vision document (usually a README or AGENTS.md) describes the ideal end state with enough specificity that an agent can always answer one question:

"What is missing right now?"

That question is the event horizon.

Every agent invocation compares Vision to Reality. Whatever falls between those two gets pulled inward.

This is why the architecture works without orchestration. You are not assigning tasks. You are defining gravity.

Defying Gravity

Time Replaces Coordination

Traditional systems coordinate agents spatially: locks, queues, ownership, leases.

Black Hole systems coordinate agents temporally.

Agents are assigned "roles" and each role does both planning and execution, but not at the same time. They run in scheduled waves. Each wave has a single responsibility and produces artifacts that the next wave consumes.

Time is the mutex.

This is what allows you to scale the system horizontally without merge conflicts or race conditions.

Separation of Roles Is the Primitive

The most important design primitive in this architecture is not Cron. It is not Jules. It is hard separation of concerns.

The "secret sauce" here is the separation of ROLES by file ownership.

The separation between planning and execution happens within each role. So each role (e.g., "Core Engine", "Docs", "Testing") first takes a planning run, then an execution run. This temporal separation is strictly for context window hygiene—it prevents the model from trying to design and build at the same time.

However, the structural safety comes from role separation. Each planner/executor pair owns the same distinct set of files.

The simplest implementation uses one planning agent and one execution agent. But this becomes ineffective as the codebase grows.

In a production Black Hole loop, you do not run one planner and one executor.

You run many planners and many executors, but they never overlap in responsibility.

A typical high-throughput cycle looks something like this:

  • 5 planning agents
  • 5 execution agents
  • zero merge conflicts

That sounds impossible until you understand the constraint model.

The Planning Layer

Planning agents never write code. Ever.

Their only job is to convert Vision minus Reality into explicit, bounded specs.

Each planner has a distinct concern. For example:

  • Planner A: Core engine correctness
  • Planner B: Developer experience and APIs
  • Planner C: Documentation gaps
  • Planner D: Performance and architecture
  • Planner E: Testing and reliability

All five planners run in the same planning window. They all read the same Vision and the same codebase. None of them modify source files.

Instead, each planner writes plans into a dedicated namespace, such as:

.sys/plans/core/
.sys/plans/dx/
.sys/plans/docs/
.sys/plans/perf/
.sys/plans/tests/

The rule is simple:

One planner, one folder, one kind of plan.

Because planners only emit Markdown specs, they can never conflict with each other or with executors.

Plans Are Contracts, Not Suggestions

A plan is not a brainstorm. It is a work order.

A good plan:

  • references specific files
  • defines clear success criteria
  • limits scope to something finishable in one execution cycle
  • explicitly states what should not be changed

This is critical. The tighter the plan, the safer parallel execution becomes.

Loose plans create thrash. Tight plans create throughput.

The Execution Layer

Execution agents are builders. They do not reinterpret Vision. They do not invent new scope. They do not argue with the plan.

Each executor watches exactly one plan namespace.

For example:

  • Executor A only reads .sys/plans/core/
  • Executor B only reads .sys/plans/dx/
  • Executor C only reads .sys/plans/docs/
  • Executor D only reads .sys/plans/perf/
  • Executor E only reads .sys/plans/tests/

This is the key to zero merge conflicts.

Each executor owns a disjoint surface area of the repo. Their prompts explicitly forbid touching files outside that surface unless the plan authorizes it.

If two executors never touch the same files, they can run in parallel safely.

Why This Scales Without Collisions

Most merge conflicts are not caused by parallelism. They are caused by overlapping authority.

Black Hole Architecture removes overlap by construction.

  • Planners overlap in analysis, not output
  • Executors overlap in time, not files
  • Vision overlaps with everything, but is read-only

The result is a system where you can add more agents without increasing coordination cost.

Five planners do not make the system noisier. They make it sharper.

Five executors do not make it riskier. They make it faster.

Memory Lives in the Repo

Because agents are stateless, memory must be externalized.

Instead of a vector database, Black Hole systems use flat files:

  • .sys/plans/ for intent
  • .jules/logs/ for lessons learned
  • optional .sys/decisions/ for architectural records

This has two advantages:

First, memory is inspectable by humans.

Second, memory participates in gravity. If a mistake keeps recurring, planners will see it and adapt.

Failure Is Harmless

If an executor fails, nothing breaks.

The plan remains. The next cycle will try again. A planner may rewrite the plan with better constraints. Another executor may pick it up.

There is no global state to corrupt.

The system converges instead of cascading.

Black Hole vs Orchestrators

Orchestrators assume you must control agents to get reliable outcomes.

Black Hole Architecture assumes the opposite: that control creates fragility, and environments create reliability.

You are not telling agents what to do.

You are creating conditions where the only stable outcome is progress.

Anti-Patterns That Break the Black Hole

The architecture is simple, but it is not forgiving. Certain mistakes will collapse gravity or introduce chaos immediately.

Mixing Planning and Execution

The fastest way to destroy convergence is to let planners write code or executors reinterpret vision.

Avoid too much pseudocode in plans. The problem is if you let them decide both what to do and how to do it, you erode the context window and quickly end up in the dumb zone. The executer agent can figure out the code. If the planner creates pseudocode that the executer changes, the other executer agents running in that cycle are now operating based on outdated assumptions.

Result:

  • plans drift
  • scope balloons
  • parallelism turns into conflict

Hard rule: planners write intent, executors write code, and neither crosses the boundary.

Shared Ownership of Files

If two executors are allowed to touch the same files, you have reintroduced coordination.

This usually sneaks in "just for convenience" when adding a new agent.

Result:

  • flaky merges
  • silent overwrites
  • growing fear of parallel runs

Fix it structurally. Give each executor an explicit file surface. Enforce it in the prompt.

Central Orchestrators and Shared State

Introducing a long-lived coordinator agent or shared runtime memory defeats the point.

You will spend more time debugging the coordinator than shipping code.

If something needs to be remembered, write it to the repo. Let it participate in gravity.

Overlapping Schedules

Running planners and executors at the same time feels faster but causes subtle race conditions.

Time is the mutex. Respect it.

Always separate planning windows from execution windows.

Lessons Learned From Running This in Jules

This architecture works extremely well in Jules, but there are practical constraints you need to design around.

Scheduled Tasks Are Expensive to Set Up

Today, Jules does not offer a clean way to programmatically create or manage scheduled tasks.

In practice, our loop runs on two hour cycles with explicit spacing between agents. So 5 planning agents run at 12am, 2am, 4am, etc. and 5 planning agents run at 1am, 3am, 5am, etc.

That means the real setup cost looks like this:

  • 5 planning agents × 12 schedules
  • 5 execution agents × 12 schedules
  • Total: (5 × 12) + (5 × 12) scheduled tasks

That's a lot of CRUD forms to fill out manually. Given this setup cost, you only want to have to configure schedules once and in an ideal world never touch them again.

Do Not Put Instructions in the System Prompt

Editing system prompts in Jules is painful when you have many scheduled agents.

If your agent logic lives in the system prompt, changing behavior means:

  • editing dozens of scheduled tasks
  • risking inconsistency
  • burning time on mechanical work

Instead, keep system prompts minimal and static.

Point every agent to a local prompt file in the repo, for example:

.sys/prompts/planner-core.md
.sys/prompts/executor-docs.md

The system prompt should simply say: read your instruction file and follow it.

This turns prompt iteration into a normal git workflow. Edit, commit, observe convergence.

Two Operating Modes: Autonomous and Supervised

In practice, there are two stable ways to run this system.

Fully Autonomous Mode

  • 2 hour cycles: planning then execution
  • ~1 hour spacing between individual agents
  • GitHub Actions auto merge all passing PRs
  • minimal human involvement

This mode embraces the idea that the work is never truly finished. The Vision is a living document, and the repo continuously falls toward it.

Progress compounds quietly. The system keeps moving even when you are offline.

Each agent is intentionally offset by roughly one hour. This gives the active agent enough time to finish, open a PR, and merge before the next agent wakes up.

The result is inevitable idle time between cycles. Jules allows you to schedule tasks every 30 minutes but I've been using an hour gap just to ensure there's plenty of time for the agent to run tests and things and create the PRs.

Compared to continuous "Ralph Loops" that hammer the repo until a PRD is exhausted, this system trades raw speed for guaranteed convergence.

Because the system runs unattended, that tradeoff is usually positive.

Supervised Mode

  • longer gaps between cycles
  • manual PR review
  • human signoff before merge

This mode feels safer, but it dramatically slows convergence.

Most of the actual thinking already happened during planning. Supervision mainly satisfies human comfort rather than improving correctness.

If you have spare execution budget, letting the system run autonomously and auditing outcomes later is usually higher leverage.

Growing Software Instead of Managing It

This architecture changes how software feels to build.

You stop asking "what should I work on next?"

You start asking "is the gravity strong enough?"

In a true Black Hole Architecture, the work is never finished.

There is no terminal state where the system is "done." You simply keep adding clarity, constraints, and ambition to the Vision.

If the Vision is clear, the system moves.

If progress stalls, the answer is never more time manually iterating on implementation plans and PRDs. It is always better separation of concerns.

That is the real lesson of the Black Hole Architecture.

Design gravity. Get out of the models way. Let time do the rest.