Flow state for software.

The psychologist Mihaly Csikszentmihalyi spent his career on one question: when are people fully, happily absorbed in what they're doing? His answer is the idea called flow, and its core is a simple diagram — the flow channel. On one axis, the difficulty of the task. On the other, the skill of the person. Flow happens in the narrow channel where the two match.

Above the channel: the task is harder than your skill, and you feel anxiety. Below it: the task is easier than your skill, and you feel boredom. Only in the channel — challenge meeting skill — are you absorbed, effective, learning. I want to argue that this diagram, drawn for human psychology, describes a multi-agent system with almost no translation — and that designing for it is a real engineering discipline. We do it at GOGOGO LLC.

An agent has a flow channel too

Give an agent a task far above its capability and it doesn't get 'anxious' — but the failure has the same shape as anxiety. It flails. It loops, retries, burns tokens, produces confident nonsense, or fails outright. An overmatched agent behaves exactly like an overmatched person: badly, expensively, and without the self-awareness to stop.

Give an agent a task far below its capability and you get the agent equivalent of boredom — not suffering, but waste. You've put a powerful, expensive generalist on a job a tiny classifier would have done faster, cheaper, and more reliably. The agent succeeds, but the system is sloppy: latency you didn't need, cost you didn't need, a heavyweight tool on a lightweight job.

So an agent has a flow channel. Above it: overmatched, failing. Below it: undermatched, wasteful. In it: the task fits the agent, and the whole system runs the way flow feels — efficient, reliable, nothing strained and nothing wasted.

The orchestrator as a flow director

In a game, keeping the player in the flow channel is the job of dynamic difficulty — the design quietly adjusts the challenge to track the player's growing skill. In a multi-agent system, that job belongs to the orchestrator, and it reframes what the orchestrator is for.

An orchestrator is usually described as a router: it sends each task to an agent. The flow lens sharpens that. The orchestrator's real job is to keep every task in the flow channel — to match each task to the agent whose capability fits it. A trivial classification goes to the small fast classifier, not the heavyweight reasoner. A genuinely hard, multi-step problem goes to the powerful agent, not the cheap one that will flail. The orchestrator is a flow director, and a good one holds the whole system in the channel.

This also tells you when to decompose a task. A task above every available agent's channel shouldn't be forced onto the strongest agent and hoped for. It should be broken into sub-tasks, each of which lands inside some agent's channel. Decomposition isn't only an architecture move — it's how you pull an impossible task down into the flow channel of the agents you actually have.

“Csikszentmihalyi drew the flow channel to explain human absorption. It turns out to be a control diagram for a multi-agent system: match the task to the agent and the system flows; mismatch it and the system either flails or wastes. The orchestrator's real job is to keep every task in the channel.”

Designing for the channel

Practically, this means you measure two failure modes, not one. Track the tasks that landed above the channel — the flailing, the loops, the overruns — and either route them to a stronger agent or decompose them. And track the tasks that landed below it — the powerful agent doing trivial work — and route those down to something cheaper. Both are flow violations. A system tuned only against failure drifts into expensive over-provisioning; a system tuned only against cost drifts into unreliable under-provisioning. Flow is the discipline of watching both walls of the channel at once. Build the orchestrator to hold the system in the middle. More of how we think at gogogollc.com.