Three spatial IDE projects launched within weeks of each other: VoiceTree, AgentBase, and Cate. Each replaces the traditional file tree and docked terminal with a 2D canvas where code, terminals, and agent output live as draggable, resizable panes. This is not a UI trend. It is a response to a specific problem: agents produce artifacts (logs, intermediate files, execution traces) that do not fit cleanly into the hierarchical folder model that VSCode and JetBrains inherited from the 1990s.
The Problem with Docked Terminals
Traditional IDEs assume a single human developer who switches context linearly. You open a file, edit it, run a command in the terminal, check the output, and repeat. Agents break this model in two ways:
- Parallel artifact generation: An agent might spawn three terminal sessions, write to five temporary files, and update two configuration files simultaneously. A docked terminal shows one process at a time. The rest are hidden behind tabs.
- Non-hierarchical relationships: An agent’s execution trace might reference a log file, a database query result, and a code snippet from three different directories. The file tree forces you to navigate up and down the hierarchy to see related artifacts.
Spatial IDEs solve this by letting you arrange artifacts in 2D space. If an agent writes a log file and a code snippet, you can place them side by side on the canvas. If it spawns three terminals, you can tile them vertically. The canvas becomes a spatial index of the agent’s work.
How Spatial State Serialization Might Work
When an agent pauses or crashes, the IDE must serialize the canvas state so the agent can resume. This is harder than saving a list of open files. You need to capture:
- Pane positions and sizes: Each terminal, editor, or output view has x, y, width, and height coordinates.
- Pane types and content: A terminal pane stores the shell process ID and scroll buffer. An editor pane stores the file path and cursor position. An output pane stores the agent’s stdout stream.
- Inter-pane relationships: If an agent created a log viewer pane to monitor a specific log file, the IDE must serialize that binding so the viewer reconnects on resume.
A plausible serialization schema would look like this (hypothetical architecture, not confirmed in the three projects):
{
"canvas": {
"zoom": 1.0,
"pan": {"x": 0, "y": 0}
},
"panes": [
{
"id": "pane-1",
"type": "terminal",
"position": {"x": 100, "y": 100},
"size": {"width": 600, "height": 400},
"process": {
"pid": 12345,
"cwd": "/home/user/project",
"scrollback": 1000
}
},
{
"id": "pane-2",
"type": "editor",
"position": {"x": 750, "y": 100},
"size": {"width": 600, "height": 400},
"file": "/home/user/project/src/main.py",
"cursor": {"line": 42, "column": 8}
}
],
"links": [
{
"source": "pane-1",
"target": "pane-2",
"type": "watches"
}
]
}The links array would encode relationships that agents create. If an agent runs a test in pane-1 and opens the failing test file in pane-2, the IDE could restore that connection when the agent resumes.
Potential Coordination Primitives for Multi-Agent Collaboration
Spatial IDEs could expose primitives that traditional file trees do not, though the three projects have not yet publicly documented these features:
- Spatial locks: An agent could claim a rectangular region of the canvas. Other agents cannot create panes in that region until the lock is released. This would prevent two agents from overwriting each other’s terminal output.
- Broadcast zones: An agent could mark a pane as a broadcast zone. Any agent that writes to that pane appends to a shared buffer instead of overwriting it. Useful for shared log viewers.
- Anchor points: An agent could create an anchor point at a specific canvas coordinate. Other agents can reference that anchor by name instead of hardcoding pixel positions. If the first agent moves the anchor, all linked panes move with it.
These primitives would address multi-agent collision problems, but none of the three projects have confirmed implementing them yet. The design space is open.
Merge Conflicts in Canvas Space
When two agents modify overlapping canvas regions, the IDE must resolve the conflict. Traditional merge tools assume a 1D text buffer. Canvas conflicts are 2D. Three strategies:
- Last-write-wins: The agent that commits last overwrites the previous state. Simple but lossy.
- Spatial rebase: The IDE detects overlapping panes and shifts one agent’s panes to an empty region. Preserves both agents’ work but breaks hardcoded positions.
- Manual resolution: The IDE flags the conflict and asks a human to choose which agent’s layout to keep. Safest but requires human intervention.
How the three projects handle this is not yet documented. Spatial rebase is the most likely default, but it assumes agents do not rely on absolute positions.
Architecture Comparison
| Component | Traditional IDE | Spatial IDE |
|---|---|---|
| State model | File tree + open tabs | 2D canvas with positioned panes |
| Serialization | List of file paths | JSON with coordinates, sizes, and links |
| Agent coordination | None (single-agent assumption) | Potential for spatial locks, broadcast zones, anchors |
| Merge conflicts | Line-based diff | 2D overlap detection + rebase |
| Context switching | Tab navigation | Pan and zoom |
| Artifact visibility | One terminal at a time | All terminals visible simultaneously |
Deployment Shape
Spatial IDEs run as Electron apps or web apps. The canvas is an HTML5 <canvas> element or a React component tree. Terminals are embedded using xterm.js. Editors are Monaco (VSCode’s editor component) or CodeMirror.
The backend is a Node.js server that manages terminal processes, file watchers, and agent communication. Agents connect via WebSocket or HTTP. The server broadcasts canvas state changes to all connected agents.
The three projects likely use variations of this stack, but specific implementation details are not yet public.
Likely Failure Modes
These are predictable risks given the architecture, not yet observed in the three projects:
- Canvas state explosion: If an agent creates 100 panes, the JSON state file grows to megabytes. Serialization and deserialization become slow. Solution: garbage-collect closed panes and limit the number of active panes per agent.
- Coordinate drift: If agents hardcode pixel positions, the layout breaks when the canvas is resized or zoomed. Solution: use relative positions or anchor points.
- Lock starvation: If Agent A holds a spatial lock indefinitely, Agent B cannot create panes in that region. Solution: add lock timeouts and automatic release on agent disconnect.
- Overlapping panes: If two agents create panes at the same position, one pane obscures the other. Solution: detect overlaps and auto-tile or stack panes with z-index.
Current Observability Limitations
Spatial IDEs do not yet expose metrics for agent behavior. Useful metrics would include:
- Pane churn rate: How often does an agent create and destroy panes? High churn suggests the agent is exploring many execution paths.
- Canvas utilization: What percentage of the canvas is occupied by panes? Low utilization suggests the agent is not using the spatial layout effectively.
- Lock contention: How often do agents fail to acquire a spatial lock? High contention suggests agents are competing for the same canvas regions.
None of the three projects currently log these metrics. They focus on basic functionality: create panes, serialize state, and avoid crashes.
Technical Verdict
Use a spatial IDE if:
- You run multiple agents that produce parallel artifacts (logs, intermediate files, execution traces).
- You need to see all agent output simultaneously without tab-switching.
- Your agents benefit from spatial context (e.g., placing related files side by side).
Avoid a spatial IDE if:
- You work with a single agent that produces linear output.
- Your workflow fits the traditional file tree model (one file at a time, sequential edits).
- You need mature tooling with extensive plugin ecosystems (spatial IDEs are experimental and lack LSP support, debuggers, and version control integration).
The key differentiator to watch: which project first implements reliable multi-agent spatial locks and exposes them as a coordination primitive. That will determine whether spatial IDEs become a standard layer in agentic infrastructure or remain niche developer experiments.