The Agents Worked in Parallel. My Attention Didn't.

TL;DR

• I usually have two or three OpenChair agent sessions active at once, with technical implementation moving in one while UX or product work continues in another.
• Model latency gives me enough time to recover context, steer one thread and move to the next. The gain comes from several objectives progressing at once.
• Agents can work in parallel. My attention cannot. I still have to manage dependencies, carry decisions between threads and decide when work is ready to converge.

---

Most days I have two or three OpenChair sessions open.

One agent might be tracing a technical implementation through the repository. Another is challenging a workflow and preparing UX recommendations. Sometimes a third is investigating the next problem while the first two keep moving.

When the implementation agent disappears into the codebase for a few minutes, I leave it there. I move to the UX thread, read back until I understand where we left it, answer the decision in front of me and redirect the work if needed. By the time I return to engineering, there is usually something new to inspect.

That loop has become a normal way of building OpenChair. I regularly use the full allowance on my 20x subscription this way.

The Wait Became Useful

With one session open, model latency feels like waiting. With several, those few minutes are enough to review a recommendation elsewhere or challenge an assumption that does not fit how a salon works.

I am not trying to hold three pieces of deep work in my head at once. Each session has a bounded objective and enough local context to continue without me watching every step. My attention moves. The execution I leave behind keeps going.

Ordinary multitasking interrupts one unfinished task with another. In these sessions, the first task can still make progress after I leave it.

I Have Never Hand-Written Code

I am not a traditional coder. I have never hand-written code, so I did not arrive at this workflow after years spent performing the implementation myself.

Building OpenChair means framing the problem, giving an agent the right context, reading its plan and following the technical consequences of what it proposes. When I return to a session, the thread contains the local implementation state: files inspected, checks run and the failure being resolved.

What I have to recover is the decision context: why the objective matters, which constraint came from a customer, what we have already rejected and whether the agent is still solving the problem I gave it.

That reading takes time. A change can be technically coherent and still move OpenChair in the wrong direction. If I skim the thread and approve the next step because the work looks tidy, I become the source of the bad assumption.

Separate Threads Drift Apart

Each session knows what happened inside it. Decisions do not automatically travel to the others.

An engineering agent can implement accepted behaviour while a UX agent explores a better version of the same workflow. If the UX recommendation changes an assumption already encoded in the implementation, parallel work has created rework. If engineering discovers a system constraint that stays inside its thread, UX can keep refining an interaction the product cannot safely support.

The difficult cases are two strong specialist answers, each persuasive inside its own brief while pointing towards incompatible decisions.

I carry the missing context between them. A product decision goes into the technical thread. An engineering constraint comes back to UX. If one finding invalidates the premise of another session, I stop that work rather than letting both agents continue neatly in opposite directions.

The Boundary Matters More Than the Agent Count

A contained technical fix can progress while a separate product question is being researched. UX recommendations for one workflow can continue while tests run against another. Those threads share a repository without depending on the same unresolved decision.

I get less value from running implementation beside UX work when the core interaction is still being challenged. The code may arrive sooner, along with the cost of unwinding it.

The boundary of each session matters more than how many I can keep open. It needs a clear objective, enough context to act and a point where it must return a decision instead of quietly making one. A consequential dependency needs an earlier stop point.

This is why the specialist modes around OpenChair have different permissions. Product and UX can investigate and recommend without rewriting the system underneath the discussion. Implementation starts inside an accepted direction. Review can challenge the result without inheriting the implementer's brief.

My Queue Is the Constraint

I can keep the agents busy. My 20x usage makes that obvious. The harder part is reviewing what comes back without dropping the thread.

Every session eventually returns with something that needs judgement: perhaps a plan, an unexpected constraint or a result that looks complete. Two or three active sessions can produce those moments faster than I can review them properly.

Starting more work is cheap. Reading it closely, comparing it with customer evidence and deciding what should happen next still takes time. A vague approval can let an untested assumption continue. A rushed correction can send the agent towards a new answer without resolving the old uncertainty.

I do not divide my attention evenly. Routine implementation can run for longer within an accepted plan. A product assumption affecting customer behaviour needs me earlier. Production waits until I can examine the evidence without also trying to hold two other threads in my head.

In The Agent Did the Work. I Owned the Outcome., I called this accountability compression. Execution spreads across agents while responsibility concentrates on the person approving what reaches production. Multithreading brings that pressure forward. Long before release, I am choosing which objective gets attention and carrying decisions between sessions.

I still like working this way. A UX question does not have to sit untouched because engineering is running tests. Technical work can continue without my eyes on every intermediate step. Several objectives stay alive at once.

Eventually two of them need the same decision, and they queue behind me. No subscription allowance changes that.

Then another session finishes. I open it, read back until I know where I am, make the next decision and move on.