A Control Plane for Agents, and the Loop I Use to Build With Them

Plan Before Execution

Every substantial piece of work starts with a conversation. The first artifact is not code. It is a plan.

I define the outcome, constraints, dependencies, and acceptance criteria before dispatching anything. This separates two questions that agents often collapse: what should happen, and how should it be implemented?

Once approved, the plan becomes durable project state. The goal is simple: make the decisions before execution so the execution itself can become boring.

flowchart LR
    A["Chat"] --> B["Plan"]
    B --> C["Decompose"]
    C --> D["Dispatch"]
    D --> E["Execute"]
    E --> F["Validate"]
    F --> G["Review"]
    G --> H["Promote"]
    G --> A

Turn Plans Into Bounded Work

Guava OS decomposes a plan into scoped tasks with explicit dependencies. Independent tasks can run in parallel. Dependent work waits until its prerequisites are complete.

Each worker receives more than an issue title. It gets the task, relevant repository context, applicable skills, constraints, and a definition of done.

Agents fill gaps. Give one an underspecified task and it will invent the missing assumptions. The unit of delegation is therefore not just a task. It is the task plus the context required to execute it correctly.

Make Parallelism Safe

Parallel agents create a shared-state problem. If several workers modify the same environment, speed quickly turns into collisions and difficult reviews.

Guava OS isolates work so agents can execute independently. The dependency graph determines what can run concurrently and what must wait.

The objective is not maximum parallelism. It is safe parallelism. Running more agents only helps when ownership, dependencies, and promotion rules remain clear.

Give Agents the Right Context

Model capability is only part of agent performance. The surrounding context determines how effectively that capability gets applied.

A database migration, frontend component, test suite, and deployment change should not receive identical instructions. Guava OS can attach task-specific skills and context before execution.

The model provides general reasoning and implementation ability. The harness provides local knowledge: repository conventions, architectural decisions, tools, constraints, and validation requirements.

Use Models for Judgment, Code for Rules

If I can express a requirement deterministically, I would rather encode it once than ask a model to remember it on every run.

Guava OS surrounds probabilistic workers with deterministic controls. Hooks load required context. Tests, type checks, formatting, and structural checks catch predictable failures. Repository rules control what can move forward.

The division is deliberate: models handle judgment and implementation; code enforces invariants.

flowchart TD
    A["Output"] --> B["Checks"]
    B -->|Fail| C["Fix"]
    B -->|Pass| D["Review"]
    D -->|Reject| C
    D -->|Approve| E["Promote"]

Separate Execution From Authority

An agent finishing a task does not make the task complete. The worker that writes the code does not decide whether that code should ship.

Completed work moves through deterministic checks and review before promotion. The system can verify the diff against the task, catch known failure modes, and require approval where judgment still matters.

This separation lets me increase execution autonomy without giving agents unrestricted delivery authority. More autonomy requires stronger controls around what happens next.

Make the Work Visible

Autonomous work becomes difficult to manage when its state disappears inside terminals and chat sessions. A control plane should make it obvious what is running, blocked, failed, or waiting for review.

Guava OS keeps plans, tasks, dependencies, status changes, validation results, and handoffs in durable project state. Today, Linear provides much of that state. Issues represent work, dependencies describe sequencing, comments preserve the execution trail, and statuses help drive workflow transitions.

Turn Friction Into Infrastructure

Repeated failures are signals. If I keep correcting the same problem, the harness is missing something.

A recurring correction can become a skill, hook, validation check, stronger task template, or better context. Instead of remembering the lesson myself, I move it into the system.

flowchart LR
    A["Execution"] --> B["Friction"]
    B --> C["Review"]
    C --> D["Skill, hook, or rule"]
    D --> A

Each project can therefore improve both the software being built and the system that builds the next project.

The Control Plane Is the Product

Guava OS currently exposes much of this workflow through developer tooling, but the interface is not the important part.

The system is the combination of durable planning, bounded delegation, dependency-aware execution, context injection, deterministic controls, visible state, validation, and explicit promotion authority.

The direction is progressively more autonomous execution with clear boundaries around validation and production. Agents can take on more implementation, testing, debugging, and coordination while the control plane governs how that work moves forward.

The goal is not autonomous coding for its own sake. It is to increase execution autonomy without losing control of software delivery.

Stack Notes

Guava OS is built primarily in TypeScript. Keeping orchestration and worker tooling in the same language reduces the contract surface across the system.

Linear currently provides durable project state through its GraphQL API. Issues represent work, dependencies describe sequencing, comments preserve execution history, and statuses participate in workflow transitions.