FredrinYou do not do it by working five times faster. You do it by making sure no engagement requires you to be present for the parts a machine can do unattended, and by keeping each one in an isolated workspace so switching between them costs a glance instead of a twenty-minute rebuild of context. The scarce resource stops being your typing speed and becomes your attention, so the whole workflow gets rearranged around spending attention well.
This post describes the workflow generically first — it works with git, a terminal, and any coding agent — and then shows what it looks like when the surface is built for it.
Why does parallel client work break down?
Not for the reason people expect. The failure is rarely that the code takes too long to write. It is that each engagement carries a resumption cost: the time between deciding to work on client B and actually being useful to client B.
That cost is made of small things. Which branch was I on. What did the agent do while I was gone. What did they say in Tuesday's call that changed the plan. Which of the four things in flight is actually blocked on me. Individually they are thirty seconds each. Across five engagements and a dozen context switches a day, they are most of the day.
Add a second failure: silent stalls. An agent that finished twenty minutes ago and an agent waiting on a confirmation prompt look identical from the outside — which is to say, both look like nothing. Every hour that an engagement sits finished-but-unnoticed is throughput you paid for and did not collect.
Neither problem is solved by a faster model. Both are solved by structure.
What does an engagement need to be independently workable?
Four things, and if any is missing you will pay for it in resumption cost:
- Its own checkout. Not a branch you switch to — a directory that exists simultaneously with the others.
- Its own running environment. Its own dev server, its own port, its own database. Anything shared becomes a serialization point.
- Its own agent session, scoped to that engagement's code and conventions.
- Its own written state — what is in flight, what is blocked, what was decided. Written down, not remembered.
The last one is the one people skip, and it is the one that actually determines whether five engagements is sustainable or just briefly survivable.
How do you isolate an engagement cheaply?
Git worktrees. A worktree is a second working directory backed by the same repository, checked out to a different branch, existing at the same time as the others.
git worktree add ../client-acme-ingest feature/ingest
git worktree add ../client-borealis-auth feature/authTwo directories, two branches, one repository, no stashing and no branch switching. Each gets its own node_modules, its own .env, its own dev server on its own port. An agent working in one cannot touch the other's files, which matters enormously the moment you run more than one at a time.
For separate clients with separate repositories the isolation is free — they are already different checkouts. Worktrees matter most within a client, where you have three streams of work in one codebase and no desire to serialize them behind a single branch.
Two practical notes learned the hard way. Copy the environment file into each new worktree; a fresh worktree has no .env and the failure is confusing. And give each one a distinct port, because two dev servers fighting over one port produces an error message that has nothing to do with the actual problem.
How many agents can one person actually supervise?
In practice, most people top out between three and six concurrent streams, and the ceiling is set by review capacity rather than by anything technical.
The arithmetic is unforgiving. If an agent produces a reviewable change every 25 minutes and a careful review takes 10 minutes, one person sustains roughly five streams before the queue grows faster than it drains. Push past that and you are not running more work, you are accumulating unreviewed work, which is worse — it looks like progress and is actually risk.
The lever that matters is therefore not agent count. It is review cost per change. Halve the time it takes you to decide whether a diff is acceptable, and you have doubled your real capacity without touching a model setting. That is why the next post in this series is entirely about making changes cheap to review.
Two things push in the wrong direction, and both are worth resisting. Fanning one task across several agents multiplies review burden without multiplying output. And letting an engagement run unattended for a long stretch produces a large diff, which is the most expensive artifact to review that exists.
What does the daily loop look like?
Roughly this, and the ordering is deliberate:
- Drain the review queue first. Anything finished is blocking a stream. Reviewing it restarts that stream; writing new tickets does not.
- Answer the blocked ones. An agent waiting on a question is a stopped machine.
- Start new work last — filling every lane before draining the queue is how you end the day with six unreviewed branches.
- Write the decision down where the work is, not in your head or a private note. This is what makes tomorrow cheap.
- Ship the small things immediately. A merged change is throughput; an approved-but-unmerged one is inventory.
The whole discipline is: finish before you start.
What breaks first when you scale this?
Three things, in this order.
Context evaporates. Each client has conventions, constraints, and a history of decisions. Held in your head, that knowledge is lost across a weekend and completely gone across a month. The fix is to keep it in the client's repository — a conventions file, a decision log — where any agent on any future task reads it without you re-explaining. Files are the durable medium because they outlive the tool and travel with the code.
Review becomes rubber-stamping. When the queue is long, approval becomes the path of least resistance, and the quality of your engagement quietly becomes the quality of the model's default output. The fix is structural: smaller diffs, stated acceptance criteria, and a bright line for what you will not approve while tired.
Clients blur. Applying client A's architectural convention inside client B's codebase is the embarrassing failure mode, and it happens most when the two engagements share a window. Isolation is not just a technical convenience — it is what keeps them separate in your head too.
Where does a tool fit?
Everything above works with git, a terminal, and any agent. Plenty of people run it exactly that way, and if you are running two engagements you probably should.
What breaks at four or five is not capability but visibility. You can create the worktrees by hand. You cannot easily look at fifteen terminal windows and answer "which of these needs me right now" — which is the question you ask fifty times a day and the one a wall of terminals is worst at answering.
That is the gap Fredrin was built for. A ticket carries its own branch, its own worktree, and its own agent session, created together and torn down together, so isolation stops being something you maintain by hand. The board answers the visibility question directly: what is running, what is waiting on you, what is ready to ship. Review is a column, not an archaeology exercise across scrollback.
The distinction from an editor is worth stating plainly, because it is the most common confusion. An editor optimizes one person editing one repository; that is a genuinely different problem from supervising several agents across several clients, which is why we treat it as a different category rather than a better editor — the argument is in Fredrin vs Cursor. It is also not an autonomous agent that takes a ticket and returns a finished PR; a human still reviews and ships every change, and Fredrin vs Devin covers why that bet is deliberate.
For the wider role context — what forward deployed engineering is and what the market pays for it — start with the role breakdown.
FAQ
Is five engagements realistic, or a marketing number? Five streams of work is realistic for an experienced engineer with good isolation and small diffs. Five clients each expecting daily synchronous presence is not, and no tooling fixes that — it is a scheduling problem, not an engineering one.
Does this need a specific AI tool? No. The workflow is agent-agnostic and works with Claude Code, Codex, Cursor, Gemini CLI, or whatever replaces them. Keeping it that way is deliberate: the surface you run work through should outlive any particular model vendor.
What about client security requirements? This workflow is compatible with strict environments because the isolation is local — worktrees are directories on your machine, and the code stays in the client's repository. Where clients differ is whether their code may be sent to a model provider at all. Establish that before the first ticket, not after.
How do you bill for agent-assisted work? Most FDEs are salaried, so this mainly matters for contractors. The honest framing is that you are billing for outcomes and judgment rather than keystrokes. Clients who buy hours will eventually notice; clients who buy shipped software will not care.
Do I need worktrees if my clients are in separate repositories? Not for separating clients — separate repositories already give you that. Worktrees earn their keep within a single client when you have several streams in one codebase.
What is the first thing to fix if this is not working? Diff size. Almost every symptom — slow review, rubber-stamping, growing queue — traces back to changes that are too large to evaluate quickly.
Fredrin is a desktop kanban for running many AI coding agents in parallel — every ticket gets its own branch, worktree, and agent session, so one engineer can keep several engagements moving at once. Free on macOS and Windows, on the AI subscription you already pay for: fredrin.com.
