Pathfinder 4.4.0 is live: it can now run several AI agents at once

Pathfinder is the workflow kit I use to build software with AI agents. Until now it did one thing at a time, on purpose. Version 4.4.0 is live, and it can run several agents at once without giving up the part that makes it safe.

Here is what that actually means.

The slow part was never the thinking

The kit exists because an agent can write code far faster than anyone can responsibly approve it. So I put a human at every point where a decision had consequences: approve the plan, accept the work, merge it, release it.

That worked. It also got slow, for a slightly silly reason.

Two tickets touching completely unrelated parts of a codebase would still run one after the other, because there was one session and I was sitting in it. The queue was not waiting for me to think. It was waiting for me to be available. That is not a human in the loop, it is a human as a scheduler.

The new mode

A project now says how it wants to run, in one line of one file:

<!-- pathfinder:execution-mode orchestrator -->

human-in-the-loop is the old behaviour: one ticket, one session, you drive. orchestrator lets Pathfinder work on several tickets at the same time, give each one its own agent, and interrupt you only when something genuinely needs a person.

A project with no mode file at all keeps the old behaviour. There is nothing to migrate.

npx create-pathfinder@4.4.0
npx create-pathfinder --mode orchestrator

Every agent gets its own copy of the repository

This is the idea the whole thing rests on, and it is simpler than it sounds.

Git has a feature called a worktree. One repository can have several working directories checked out at the same time, each sitting on its own branch. Pathfinder gives every claimed ticket one of those, on a branch named after the ticket.

So two agents are never editing the same files in the same folder. They are not coordinating, or taking turns, or being careful. They are somewhere else entirely.

What stops two agents grabbing the same ticket is not a lock file I invented. It is a Git reference that Git creates only if it does not already exist. Of any number of agents trying to claim a ticket in the same moment, exactly one wins, and Git is what decides. No database, no background service, nothing running that you have to keep alive.

How it decides who does what

Before dispatching anything, Pathfinder sizes up each ticket and writes down what it found:

complexity:      medium      # 5 bullets under ## Changes
context:         small       # 3 paths named under ## Context
parallel-safety: isolated    # no other ticket is in flight
risk:            unassessed  # no risk rule applies

Each of those is a count over the ticket's own text rather than a guess. Complexity counts the bullet points describing the work. Context counts how many file paths the ticket names. The same ticket gives the same answer every time.

The interesting one is parallel-safety. It compares the files this ticket says it will touch against the files every other in-flight ticket says it will touch, and reports one of three things: isolated when there is no overlap, shared-surface when they share a directory, and serialize when they name the same file, which means do not run these two together.

That is the check that makes starting two agents feel less like a gamble.

Then a routing policy turns those findings into an assignment: which role the agent plays, which model it runs on, how much reasoning effort it gets.

The boring version, on purpose

Here is the entire routing policy that ships:

role:   session === "review" ? "tester" : "developer"
model:  "inherited"
effort: "inherited"

It reads none of the estimate. inherited means the agent simply runs on whatever the session that dispatched it was already using.

So Pathfinder measures four things and then ignores them. That is deliberate. Those measurements exist to be a stable input for a smarter policy later, and to sit visibly in every profile so I can find out whether they were any good in the first place. Nothing has tested those thresholds against real outcomes yet, and I would rather ship a policy whose behaviour I can predict than let an unvalidated number start choosing models for me.

Swapping in a different policy later means one new file and one line in the mode file. That socket was the actual deliverable.

Then both agents died

The best evidence came from an accident.

During the acceptance run, Pathfinder dispatched two agents and correctly held a third ticket back, because it depended on the other two. Both agents then hit their usage limits and stopped, in the middle of their work.

Nothing was lost. The branch, the working directory, the uncommitted changes and the assignment all live in Git and the ticket tracker, not in the agent's memory. Fresh sessions picked up the same claims exactly where the dead ones left them, and the run finished.

An agent is the cheapest part of the system. It is the one piece you should be able to lose.

To be straight about the limits: those two agents never hit a human approval gate or a file conflict, so both of those were tested separately in throwaway repositories. And nothing in this release measures whether running agents in parallel is actually faster, so I am not claiming that it is.

What it will not do

It does not merge anything. It does not skip review. It does not launch unlimited agents. A ticket whose status it cannot read clearly is never eligible to run, and never unblocks anything else.

Pathfinder can now run several agents at once. It still cannot approve, accept, merge or release anything. That is the whole point.

Pathfinder on GitHub: https://github.com/rikilamadrid/pathfinder

🧭 The kit owns the workflow. The project owns the stack.