Bart van de Lint

Coding agents that carry a plan across many pull requests

Most agent tools take one issue to one pull request. The changes worth making in a package ecosystem are dozens of pull requests across many repositories, with releases in between, that land over weeks. I built and run a self-hosted platform for that: a plan names every pull request and what must merge before it, and the platform files each one the moment it can start. The platform's code is private, but its bot, 1-Bort-1, works in public: every number on this page links back to pull requests anyone can read.

183merged public pull requests
14public repositories
641reviews on public PRs
30 hmedian open to merge
4merged by other maintainers

One user: me. Every number here is my own use of the platform.

01Plans

A plan is a document the platform schedules from

A plan is a markdown file on its own branch. Each section is one pull request to make: which repository, what it should do, and which other sections must have merged first. An agent session owns the document for the plan's whole life, and the platform reads it every minute.

Eleven of the 39 units, across nine repositories, of a live plan, one kite system definition across the Kite packages, running since September. An arrow means "has merged before". The first column needed nothing and was filed at once; every later one was filed by the platform when its last arrow landed.

How a plan runs

  1. Draft

    I write the plan with an agent at a terminal. It pushes the document as it takes shape, so the plan is reviewable line by line as a pull request while we discuss it.

  2. Approve

    A plan starts paused. Taking one label off its tracking issue approves all of it; putting it back holds it without losing what is already underway.

  3. File

    A unit becomes an issue in its repository once everything it needs has merged. It starts earlier if those are open pull requests with green checks: then it builds on their branches, and its own pull request stays a draft until they merge.

  4. Work

    Each unit runs the same loop as any other task, below, and a person merges it.

    ↺ the task loop

  5. Release

    A unit can be a package release. The platform opens the release pull request once its needs have merged, and units that use the new version wait until the package registry serves it.

  6. Re-cut

    Every merge or dropped unit wakes the plan's session with what changed. It rewrites the units still ahead, and an edit to a unit already filed rewrites its issue and tells its agent. An agent that finds the plan wrong for its own unit can fix the document too.

    ↺ until every unit has settled

  7. Close

    Once every unit has merged or been dropped, the session writes what the plan set out to do, what landed and what it left undone.

Not a task list in one session

An agent splitting a task into steps keeps the plan in its context, which ends with the session. This plan lives on a branch for weeks, and every unit is a fresh agent that reads it.

Not an epic with sub-issues

Filing sub-issues up front makes a person the scheduler: each one waits for someone to notice its prerequisite merged. Here a merge files the next unit within a minute.

A dependency means merged

A unit never lands a draft of something another unit will rewrite, and an order that is only a preference is not written down. Units with nothing between them run in parallel.

02Why

Why I built it

I maintain open-source Julia packages for airborne wind energy simulation with a few other maintainers. There was always more work than people. Letting agents loose produced changes nobody wanted to review, and the work that mattered most, like changing a data format every package reads, never fitted in one pull request.

What I learned

Building the tooling was the relatively easy part. The hard part is defining how the agent should work and write: its rules, the code standard its reviewer checks against, and the shape of a pull request description. Feedback from the developers reviewing its pull requests made me rework those instructions, and that made the biggest difference: a reviewer can now judge a change from the description alone.

03Output

Merged pull requests over time

Cumulative public pull requests, by merge date. One user: all of it is my use of the platform. Work in private repositories, mostly the platform building itself, is not counted.

Table view

Pull requests merged per week

Public pull requests by the week they merged, weeks starting on Monday. The last week runs to the snapshot date.

Table view

Where the public work landed

Merged pull requests per public repository: scientific Julia packages for simulating airborne wind energy systems, plus a data standard and a browser viewer.

Merged by me Merged by another maintainer
Table view

Time from open to merge

Merged public pull requests by how long each stayed open, from the draft pull request opening to its merge. That includes agent review, CI and my review.

Table view
04Loop

How a task runs

Every unit of a plan, and every one-off issue, goes through the same loop. Agents never merge; a person does.

  1. Issue

    An owner labels an issue, assigns the bot, or tags it in any thread. It becomes a task within a minute.

  2. Plan

    Before writing code the agent rewrites its acknowledgement into a plan on the issue, so a wrong plan is caught in a minute rather than in a pull request.

  3. Implement

    In its own git worktree, inside a systemd unit with memory, CPU and idle limits, read-only mounts and a scoped token. Claude Code or opencode.

  4. Test gate

    The repository's tests and rules pass locally, then a draft pull request opens with a card explaining the change.

  5. Agent review

    A second agent on the other harness reviews it, so the two don't share blind spots. Each finding goes back to the implementer.

    ↺ back to implement

  6. CI and conflicts

    The first red check's log, or a merge conflict with the base, goes back to the agent to fix.

    ↺ until green

  7. Human review

    Out of draft, my review is requested. My comments reach the agent like any other. A maintainer of the repository merges it.

    ↺ until approved

  8. After merge

    Checks on the default branch are watched for twelve hours. A red merge becomes a priority task whose pull request is the fix or a revert.

Quota failover

When a harness runs out of quota mid-task, the other writes a handover note from the stopped session and picks the task up in the same worktree.

Slack with approvals

A Slack assistant answers about the fleet. Anything that writes, such as opening issues or running a command, waits for a thumbs-up on the exact action.

Inside the API budget

The notification feed, one aliased GraphQL query per pass and git transport for merge checks keep the whole fleet under GitHub's rate limits.

05Pull requests

Merged by other maintainers

Pull requests accepted by people with no stake in the bot.

    Longest review threads

    Design-heavy changes that went through many rounds of review before merging.

      06Also mine

      OpenFastChat

      Bring-your-own-key AI chat

      My own product since June 2026. Every answer runs through an editable, shareable flow: a graph of processing nodes. It has its own tool-calling loop, web search and document grounding, context compaction and streamed responses, and runs on any OpenAI-compatible provider. Go and PostgreSQL backend, React and TypeScript frontend. Open core under AGPL, plus a hosted service.

      Data from GitHub as of 26 October 2026.