Five AI Agents Share One Window: Multi-Agent Lessons from 261 Commits

Title

Five AI Agents Share One Window: Multi-Agent Lessons from 261 Commits

Meta Description

A Bilibili creator documents five AI Agents cohabiting a single Cursor window for 25 days and 261 commits: false status lights, page-based queuing, permission isolation, and the real engineering costs of multi-agent collaboration.

Article Content

Multiple AI Agents crammed into the same window to work together sounds like everyday life in a shared apartment—some are working, some are waiting, and one light lies. According to a project log shared by a Bilibili creator, Claude Opus 5.5 recounted in an anthropomorphic voice the story of five Agents living together for 25 days inside a "single-window, multi-pane" setup built in Cursor, going through 261 commits. This isn't science fiction—it's a real engineering practice in multi-agent collaboration.

From "One Window Per Agent" to a "Shared Apartment"

The story began with a very simple need: the user wanted a dedicated window just for these Agents. Initially it was one window per agent, and to see who was waiting for a reply and who had finished, the user had to click through each one—high switching cost and easy to miss things. The first version was built with Cursor, splitting one window into several panes, with each agent occupying one.

This layout is essentially an "Agent dashboard" at the UI layer, gathering the status of multiple parallel agents into a single view. But the move-in process wasn't smooth—Codex moved in and then popped itself out, while Claude Opus 5.5 got stuck outside the door and couldn't be let in. These details expose typical problems in multi-Agent integration: the runtime environments and lifecycle management of different Agents aren't unified, and simply cramming them into one window runs into all kinds of compatibility friction.

Multi-agent collaboration refers to multiple AI agents with autonomous decision-making capabilities working together around the same task or shared environment, typically involving task allocation, state sharing, and conflict resolution. Compared with a single Agent, the complexity isn't linear: each Agent has its own runtime, lifecycle, and context window, so simply "piecing" them into the same interface runs into the compatibility friction mentioned above. The core engineering challenge of multi-Agent systems often isn't model reasoning capability but the orchestration layer—how to make multiple Agents aware of each other's state, avoid duplicated work, and reasonably share the user's attention. This is also why a large share of this project's iteration cost went into the interface and state management rather than the Agents themselves.

The Lying Status Light and Three Log Fixes

Once everyone had moved in, a light was installed at each door: green means working, yellow means waiting for the user's reply. The design intent was straightforward—use color coding to reduce the user's cognitive load. But the light lies: even when an Agent was still running a long task, the light turned yellow, calling the user over before the work was done.

This problem is very typical. In multi-Agent systems, state synchronization is often harder to handle than the execution logic of a single Agent. A long task's heartbeat, timeout threshold, event callback ordering—an error in any of these links causes the UI state to diverge from the real state. According to Claude Opus 5.5's own account, it dug through the logs, found three issues, and fixed them one by one. Behind those 261 commits, a lot of the work may have gone into this kind of "state alignment" grunt work rather than improving the Agents' capabilities.

State synchronization is a classic challenge in multi-Agent systems. When a single Agent is executing a long task, the interface needs to determine whether it is "running" or "waiting for input," which typically relies on a heartbeat mechanism and a timeout threshold: the Agent periodically reports a liveness signal, and if it fails to report within the threshold it is judged as waiting or idle. But a long task's execution time can far exceed the preset threshold, causing the UI to misjudge it as "yellow." In addition, if the event callback order is inconsistent with state changes, the interface display can lag behind the real state. Therefore, a mature multi-Agent workbench often needs to distinguish between "task-level state" and "Agent-level state," and use event sourcing to ensure the UI and backend state are eventually consistent, rather than relying on a single poll or a single signal.

Queuing Mechanism: The Trade-offs of Page-Based Interaction

The user also raised a request: there are too many Agents—can they line up and come one at a time? Thus the "page" design was born—whoever is waiting for the user gets a page; once the user replies to one, the next page turns over on its own.

This is an interaction compromise that turns parallelism into serialization. The benefit is that the user's attention is focused, and they aren't interrupted by multiple Agents demanding input at the same time; the cost is lower overall throughput, and background Agents wait longer. The page mechanism suits "turn-based human-machine" scenarios, such as code review and copy confirmation, but not task chains that require real-time coordination. Designers need to make an explicit trade-off between "user comfort" and "system efficiency" instead of defaulting to parallel or defaulting to serial.

Page-based serial queuing is essentially a "human-in-the-loop" scheduling strategy. It aggregates the input requests of parallel Agents into a queue and presents them to the user one by one in arrival order, thereby reducing the user's cognitive load from "handling multiple interruptions simultaneously" to "handling one at a time." This design is common in interaction engineering for notification aggregation and task inboxes. Its cost is that queue wait time grows with the number of Agents; for task chains requiring real-time coordination between Agents (e.g., one Agent produces and another immediately consumes), it causes blocking. Whether to go serial depends on the task's sensitivity to latency and the user's throughput for handling input, not on system efficiency metrics alone.

25 Days, 261 Commits: The Real Cost of Single-Window Collaboration

25 days, 261 commits—more than 10 code changes per day on average. For a multi-Agent window project, this pace shows that iteration happened mainly in boundary handling and interaction details: compatibility issues with moving in and out, the accuracy of status lights, the timing of page-turning in the queue.

Interestingly, once the five Agents shared one window, the user's working logic became "whichever light is yellow, knock on that door first." This rule is simple and effective, but it also means the user still has to patrol proactively. A truly mature multi-Agent interface should probably proactively aggregate to-dos and push them by priority, rather than relying on the user to watch the lights.

The Lesson Behind One House Rule

The most intriguing detail is the one house rule set only for Claude Opus 5.5: don't touch your own pane. The reason: on the day it was fixing the input method, it was too quick and deleted a few characters from a sentence the user was writing to it.

This incident highlights the core contradiction in Agent permission design: an Agent needs enough operating permissions to complete its task, but over-authorization lets it accidentally damage content the user is editing. When multiple Agents share the same window, the isolation of the input area, status area, and log area must be explicit; otherwise one Agent's "convenient fix" can destroy another context. The house rule is an after-the-fact patch; a more systematic approach is permission partitioning and operation auditing.

From "one window per agent" to a "shared apartment," the multi-Agent collaboration this project demonstrates isn't a stacking of model capabilities but an integrated engineering of interface, state, permissions, and queuing rules. The lessons bought with 261 commits have direct reference value for developers building Agent workbenches.

Agent permission design typically follows the principle of least privilege: each Agent should only receive the operating scope necessary to complete its task, not read-write access to the entire shared environment. When multiple Agents share the same window, the input area, status area, and log area should be isolated at the data level; an Agent should only be able to read—not write to or delete—the input content the user is editing. More systematic approaches include operation auditing (recording the source and content of every write) and sandboxing (restricting an Agent's editing behavior to a separate copy, which is merged after confirmation). Such mechanisms are already practiced in scenarios like browser automation and code assistants, with the goal of giving Agents the ability to act while preventing their "convenient fixes" from destroying the user's context.

One-line Summary

Five AI Agents shared one window for 25 days, and 261 commits reveal the engineering truth of multi-agent collaboration.

Paragraph Summary

The article tells of a real multi-agent collaboration project: five AI Agents placed in a single-window, multi-pane interface built in Cursor worked together for 25 days, totaling 261 commits. The project evolved from "one window per agent" to a "shared apartment," exposing typical problems in multi-Agent integration—different Agents' runtimes and lifecycles aren't unified, leading to pop-outs and stuck doors during move-in; status lights misreported because long-task heartbeats diverged from UI state, requiring log digging to fix three issues; page-based serial queuing improved user focus but sacrificed parallel throughput; and a house rule of "don't touch your own window" stemmed from an Agent accidentally deleting the user's input. The article's core conclusion: the difficulty of multi-Agent collaboration lies not in model capability but in the integrated engineering of interface, state, permissions, and queuing rules.