State of the Work: August 2026

Overtone taught me a lot. It was a fairly simple agent, but running it continuously for a few weeks exposed a different class of problems than getting an agent to work once.

The stack degraded surprisingly quickly. Local GPU instability crashed the host and left backing git repositories in bad states. The hand-rolled memory system accumulated errors and needed periodic correction. As I added capabilities—and tried to separate those capabilities from where they happened to run—more and more infrastructure leaked into what had started as a simple agent loop.

None of these problems were especially exotic, but long-running agents seem to turn ordinary concerns—durability, recovery, isolation, state, trust boundaries—into forefront concerns.

At the same time, I've been relearning how to build software with coding agents. At times it feels like trying to mow the lawn with a plasma cannon. The amount of work they can produce is extraordinary, to the point that it is hard to keep the system legible in my head. I eventually put whiteboards up in my office just to keep the important questions persistent off the screen.

After weeks of acting as a meat proxy between Opus and Sol—copying one agent's review into another agent's session—I realized the development process had exactly the same problem: I needed a more durable way to organize long-running work.

Metawork

I’ve landed on a lightweight planning pipeline that produces roughly day-sized units of work. One of the major benefits of this is that the build loop can get enough coherent, scoped, planned work to execute without supervision; and I can continue to iterate on subsequent epoch shapes without interfering with that work.

sequenceDiagram
    autonumber

    actor Ver
    participant Product@{ "type": "control", "alias": "Product loop" }
    participant Scope@{ "type": "control", "alias": "Scope loop" }
    participant Build@{ "type": "control", "alias": "Build loop" }
    participant Repo@{ "type": "database", "alias": "Repo (jj)" }

    Note over Ver,Repo: One active Epoch. Always work the lowest-numbered Change.

    rect
        Note over Ver,Product: Product — define the next body of work
        Ver->>Product: State product problem
        Product->>Repo: Shape Epoch
        Product->>Ver: Propose outcome and acceptance criteria
        Ver-->>Product: Agree / revise / reject
        Product->>Repo: Record settled product model
        Product->>Product: Review
        Product-->>Scope: Hand down shaped Epoch
    end

    rect
        Note over Scope,Repo: Scope — turn the Epoch into executable Changes
        Scope->>Scope: Resolve ordering and dependencies
        Scope->>Repo: Record ordered Changes
        Scope->>Scope: Verify each Change is independently executable
        Scope->>Scope: Review
        Scope-->>Build: Hand down ordered Changes
    end

    loop Lowest-numbered Change
        rect
            Note over Build,Repo: Build — answer one Change
            Build->>Build: Define model, smallest change, and evidence
            Build->>Repo: Implement and test
            Build->>Repo: Land one reviewable commit
            Build->>Build: Review

            alt Accepted
                Build->>Repo: Mark Change done
            else Change-local issue
                Build-->>Build: Correct and re-review
            else Scope/model gap
                Build-->>Scope: Escalate
            else Non-blocking finding
                Build->>Repo: Shelve finding
            end
        end
    end

    alt Scope exposes product-level gap
        Scope-->>Product: Escalate
    else Product requires principal decision
        Product-->>Ver: Request ruling
    end

Some important lessons from the first few weeks:

• Cross-model reviews are materially better than same-model reviews. When Claude is driving, it invokes codex to review its work, and vice versa.
• If you bias to letting reviewers block, they will block. Position reviewers to sharpen ideas, spot opportunities for simplification, and to generally look for ways to improve the design.
• I use reviewers at every single step: epochs get adversarial review, sequenced change plans get reviewed, and the builder goes through a full mini-RFC process on the implementation, each with review loops.

I suppose it’s worth discussing what I’m using this workflow for, though.

ATRT

I’ve been working on something I’m calling ATRT : a runtime, ostensibly for agents, built using ATProto primitives. Some of the core concepts include:

• local-first
• durable execution
• WASM runtime modules
• dynamic runtime topologies/policies
• ATProto-style extensibility (XRPC, Lexicons)

It’s still fairly early in the process of proving out the fundamental ideas behind the project. I’ll share more as the work progresses.

On that note…

A thought on Open Source Software

I don’t know what to make of OSS anymore. I want to share ATRT with people, and I want to find ways to build and collaborate with others, especially in the design space. But I’m not particularly motivated to go put my work up on GitHub, either. There’s a delightful utilitarian simplicity in self-hosting what I need for the time being. You don’t need Actions to integrate. You don’t need Issues to organize. You don’t need to be MIT to be free.

I have been thinking a lot about the opportunity to change how OSS communities organize. Cost incentives are changing. Our OSS institutions were designed for a world in which producing software was scarce; but we’re entering one in which deciding what should exist, who to trust, and what deserves attention are scarcer.

These changes are, naturally, causing maintainers of all sorts of projects to revisit their relationship to OSS communities. It would be irrational to ignore them. But, a retrenchment to a proprietary software regime cannot be the outcome, for those of us who value the promise of sovereign computing. It is a conundrum.

My greatest aspiration is for this work to find resonance with the narrow community of people who see an opportunity to build tomorrow's systems differently. I want someone to encounter ATRT and make something with it that I couldn't have imagined. That simply can't happen while it remains isolated on my workstation.

I don't yet know what organization should replace the default assumptions of contemporary OSS. But I'm increasingly interested in the alternatives: System Societies. Computation Clubs. Inference Unions. Small groups with enough shared intent to build complementary systems deliberately, without requiring either a corporate boundary or a global GitHub commons.