Concurrent Agent Teams on the Canvas

Position this module against the previous three. Module 1 made the case that splitting work is a cost you pay deliberately; Module 2 gave the patterns — fan-out, pipelines, critic pairs; Module 3 chained the tools. This module deals with the surface where fan-out gets physical: a single shared canvas or design file that several agents are editing at once. Everything from Module 2 still applies, but the canvas adds a constraint code mostly avoids — the artifact is one spatial document, and two agents who each did good work can still produce a page that looks like two different products.

The phrase a shared file with feelings is doing real work. In code, concurrent edits collide as merge conflicts the tooling surfaces loudly. On a canvas, they collide as visual incoherence: spacing rhythms that drift between sections, two near-identical card components, type scales that disagree by one step. Nothing errors. The page just stops feeling like one page, and nobody can point to the line where it happened.

Set expectations on tooling. The module references OpenPencil's concurrent agent teams as the clearest public implementation, and connected canvases — Paper, Pencil, OpenPencil — as the file formats that make this work reviewable. But the conventions and the review rhythm are tool-agnostic; they apply just as well to three Claude Code sessions editing .pen files in one repository.

Walk the failure modes in order of how visible they are, because visibility is the problem. The frame collision is the most code-like: two agents write to the same node and either the later write wins silently or the file format demands a merge. Connected canvases handle this better than binary tools because the file is text, but a three-way merge of a JSON canvas file is still nobody's idea of a good afternoon — OpenPencil ships a git panel with three-way merge for .op files precisely because canvas-scale diffs need help.

The quieter failures are the expensive ones. Visual drift happens when each agent makes locally reasonable choices — a 20px gap here, a 24px gap there — that read as sloppiness when the sections sit next to each other. Duplicate invention is the design-system version of the same thing: each worker, unable to see what the others are building, creates its own card variant. Token bypass is the one that survives longest, because a hardcoded hex that matches the token today drifts silently when the token changes next quarter.

The last bullet is the Module 1 lesson resurfacing: every parallel stream you add multiplies review load. The rest of this module is about pushing that review cost down with structure — ownership, conventions, and rhythm — rather than pretending it away.

This is the fan-out pattern from Module 2 mapped onto canvas geometry. The partition should follow the canvas's own structure rather than an abstract task list: pages in a multi-page file, top-level frames on a single page, or named sections inside one long frame. The reason is practical — agents address canvas content by node and frame names, so a boundary that exists in the file's structure is a boundary the agent can actually respect, while build the top half of the page is not.

The shared-asset rule deserves emphasis because it is where most teams get burned. Tokens, variables, and shared components are read by every zone, which is exactly why no zone may write them. A worker that decides the spacing token is wrong and fixes it has just changed every other worker's output mid-run. The rule is: shared assets belong to the orchestrator, and a worker that wants a change files a request and keeps working with what exists. This mirrors how OpenPencil's concurrent agent teams are described as working — an orchestrator decomposes the page spatially and hands sections to workers, while the system-level style guidance stays common.

The stop-and-ask instruction is the cheap insurance. An agent that hits a genuine cross-zone dependency — the hero needs a component that the features zone is building — should surface it rather than improvise a copy. That pause costs a minute. The duplicate component costs a cleanup pass.

Each line here exists because its absence produces a specific, recurring mess. Zone-prefixed names are what make ownership checkable: when every node the hero worker created starts with landing/hero, the merge owner can diff a zone in seconds and a stray edit outside the prefix is immediately visible. Auto-layout containers with explicit gaps matter because agents reason about structure far better than they reason about absolute coordinates — a frame built from containers round-trips through an agent cleanly; a frame built from absolutely positioned rectangles produces brittle output, a point the connected-canvases material on this site makes at length.

Reuse before create is the anti-duplication rule. The justification requirement sounds bureaucratic but it is one line in the worker's output — needed a stat-card variant, none exists — and it converts silent invention into a reviewable decision. The variables rule is the same discipline as design-token hygiene in code: hardcoded values that happen to match are the drift you discover next quarter.

The delivery mechanism matters as much as the content. Conventions stated in the chat evaporate when the next session starts. Conventions in the project's harness file — CLAUDE.md, AGENTS.md, or the canvas project's own instruction file — and repeated in compressed form in each worker brief are read every run. This is the same lesson as single-agent harnessing, multiplied by the number of workers.

The point of this table is not to rank tools; it is to show that the file format decides which coordination mechanisms are even available. When the canvas is a JSON file in the repository — Pencil's .pen, OpenPencil's .op — concurrent work inherits the whole git toolkit: a branch per zone, a diff per worker, a merge the orchestrator controls, and a pull request where the design change and the code change travel together. OpenPencil ships a git panel with three-way merge and conflict resolution for .op files, which is an honest acknowledgment that diffable design files still need merge help at canvas scale.

Paper sits in the middle: the artifact is markup, which agents handle well, but it lives in the vendor's cloud behind a local MCP bridge, so review leans on before-and-after screenshots rather than line diffs. Figma remains the right call when the constraint is an established team library and true multiplayer with non-engineering stakeholders — but agent edits go through an API layer rather than a file, so the zone-ownership discipline has to be enforced entirely by convention and log, not by branch.

Date-stamp all of this for the audience: pricing and write capabilities in this space have changed repeatedly, these descriptions are accurate as of June 2026, and the school's connected-canvases and open-source-design articles are the maintained references.

Be precise about epistemic status, because the authoring sources are. OpenPencil — MIT-licensed, the self-described first open-source AI-native vector design tool — documents concurrent agent teams as a headline feature: an orchestrator decomposes a complex page into spatial sub-tasks, multiple agents work different sections simultaneously, and the canvas shows per-member indicators while they stream. The school's article on the open-source agentic design stack describes this from the repository and documentation; it did not execute OpenPencil end to end. Present it as a verified description of the design, not a benchmark.

The reason it earns a slide anyway is that the architecture encodes exactly the disciplines this module teaches. Spatial decomposition is zone ownership. The layered workflow — skeleton, then content, then refinement — is a sequencing rule that keeps parallel zones structurally comparable before anyone polishes. Segmented prompt retrieval is context discipline: each worker loads only the design knowledge relevant to its zone instead of the entire system. And the multi-model capability profiles — full prompts for top-tier models, simplified shapes for smaller ones — are a reminder that worker quality is a budget decision, which Module 6 picks up.

The last bullet matters for teams not adopting OpenPencil itself: the same canvas is scriptable from outside through its MCP server and CLI, which means the patterns here can be reproduced with the agent stack a team already runs.

Walk the diagram left to right. The orchestrator — which can be the designer or an agent the designer directs — does the decomposition: zones with single owners, one brief and boundary per zone, and a merge order decided before anyone starts. Below it sit the shared constraints: variables and tokens, the component library, and the naming conventions. Every worker reads them; no worker owns them; a worker that wants them changed routes the request back to the orchestrator.

The middle column is the only place anything runs in parallel. Three workers, three zones, each writing only its own frames, each layering skeleton before content before refinement so the zones stay structurally comparable. The merge and consistency pass is deliberately drawn as a gate in the dark style this school uses for gates: one merge owner, the agreed order, a diff of every zone against the tokens, a check for spacing, type, and naming drift, a snapshot of the assembled page, and one fix list per zone.

The two right-hand boxes carry the human judgment. The designer reviews the page as a page — coherence across zones is precisely what no individual worker could see — and decides to ship, run another round, or fold the work back to a single agent, which is sometimes the honest call. Point at the dashed return line: fixes go to the zone that owns them. Broadcasting one zone's fix list to all three workers is how you get three agents resolving the same problem three different ways.

These four rows cover the overwhelming majority of real conflicts, and they share a structure: the conflict is never inside a zone, it is always at something two zones touch. The shared component case is the most damaging because the breakage is invisible to the worker who caused it — the agent edited the card component to suit its zone, and the other zone's instances reflowed without anyone watching. Making shared components read-only to workers, with changes handled as their own sequenced task after the parallel phase, removes the case entirely at the cost of a slightly longer schedule.

The token case is the same logic one level down. The seam case is subtler and specific to canvases: when each zone controls its own outer padding, adjacent sections double their spacing or collapse it, and the page rhythm breaks at every boundary. Giving the orchestrator ownership of inter-section spacing — ideally as a single token or a wrapper frame the workers do not touch — turns seams from a negotiation into a constant.

The new-shared-asset row is where judgment stays involved. Sometimes the run genuinely needs a component that does not exist, and one worker should build it. The justification line plus the merge owner's read is the lightweight version of a contribution gate; if the same need shows up in a second run, that component graduates into the shared library with proper review, which connects to the design-systems course.

The rhythm has two beats and one role. The first beat is the skeleton checkpoint, borrowed directly from the layered workflow: every zone pauses when its structure is blocked out — sections, hierarchy, rough sizing — and the orchestrator or designer reviews them side by side before anyone writes real content or polish. This is the cheapest moment to catch the zone that misread the brief, the duplicate component, or the layout that will not sit next to its neighbours. It is the multi-agent equivalent of the plan-review gate from the fundamentals course: correction before investment.

The second beat is the merge. One named merge owner — a person for high-stakes pages, an agent with a tight checklist for routine ones — assembles the zones in the agreed order and runs the consistency pass: diff each zone against the tokens, check spacing and type rhythm across seams, flag naming violations, and snapshot the whole page. The snapshot matters because coherence is a whole-page property; no per-zone review can see it.

The role is the merge owner itself, and the discipline is that fix lists go back to the owning zone only. Broadcasting fixes invites three agents to solve the same problem three ways. And the Module 2 habit applies here too: a fix that recurs across runs is not feedback, it is a missing convention — move it into the harness so the next run never produces it.

This slide deliberately reuses the decision logic from Module 1, because the canvas does not get an exemption from it. The small-page case is the most common: writing three zone briefs, setting conventions, and running a merge pass has a fixed cost of an hour or so of designer attention, and a single competent agent will finish a one-screen page in less time than that. The dependency case is subtler — a landing page where the features, pricing, and footer all need to echo a hero direction that has not been chosen yet is sequential work wearing a parallel costume; fan it out and you will rebuild two zones after the hero lands.

The thin-design-system case matters for teams early in their agentic adoption. Concurrent zones stay coherent because they share constraints; if there are no tokens, no component library, and no written conventions, the shared-constraint column in this module's diagram is empty and every worker improvises. Build the system first — the design-systems course covers that — and the concurrency becomes available later.

The taste case and the merge-owner case are about people, not tooling. Direction exploration is a conversation between one designer and one agent, where divergence is the point; concurrency optimises production, not taste. And if no human or clearly-charged agent owns the merge, parallel output simply accumulates as unreviewed work in progress — which is slower than not having started.

Frame this as a traced run of the structure, with illustrative timings — the point is the shape of the log, not a benchmark, and the numbers will vary with the surface and the team. The task suits concurrency on every Module 1 test: the canvas is large (three pages), the zones are genuinely independent (foundations, components, patterns barely reference each other), and the design system is mature enough that shared constraints exist to be read.

The two interventions are where the structure earned its keep. The skeleton checkpoint caught the patterns worker inventing a second card grid before any content existed — a thirty-second redirect at that stage, a zone-level rebuild if it had been caught at the merge. The token-change request from the components worker is the ownership rule working as designed: the worker flagged that a spacing variable seemed wrong, kept building with the existing value, and the orchestrator made the call once, globally, after the run.

The merge findings are typical: a couple of hardcoded colours and a naming violation, all clustered in one zone, all caught by diffing against the tokens rather than by eyeballing. And the designer review still found something no zone could see — the spacing seam between two pages — which is exactly why the whole-page pass is not optional. Total designer-facing time was roughly 105 minutes for a three-page canvas; the honest comparison is not against zero, it is against either a long single-agent run with the designer waiting, or a manual build measured in days.

The exercise is on paper for the same reason the Module 1 exercise was: the hard part is the decomposition and the rules, not the running. Steer participants towards a real file with real shared assets — a marketing site canvas, a design-system documentation file, a multi-screen flow — rather than an idealised example, because the awkward parts are the point. The shared-asset list in particular tends to be longer than people expect once they look: tokens, a handful of components, a couple of illustration styles, the page grid itself.

The convention-writing step is where the value concentrates. Most teams discover they have informal conventions that have never been written anywhere an agent would read them, which means they effectively do not exist for this workflow. Five lines is enough; the discipline is putting them in the harness file rather than in someone's head.

The last bullet matters most for honesty. A respectable fraction of the files people pick will fail the not-worth-it checklist — too small, too coupled, too thin a system — and writing down the single-agent alternative is a better outcome than forcing a team structure onto a solo task. If running this live, compare answers on the merge-owner question: it is the one most groups leave vague, and the one that decides whether the parallel output ever becomes a page.

Recap by connecting the bullets back to the course spine. The quiet-failure slide is Module 1's coordination tax made visible on a spatial surface. Zone ownership and the conflict rules are Module 2's fan-out pattern with the boundaries drawn in canvas geometry. The file-format slide is the same design-as-code argument the fundamentals course makes, applied to the question of whether concurrent work can be reviewed at all. And the rhythm — skeleton checkpoint, merge owner, whole-page review — is the critique discipline scaled to several producers.

Be explicit that the honest takeaway includes the negative case: most canvases, most weeks, are still single-agent work, and the not-worth-it checklist is as much a part of this module as the diagram. Teams that internalise that spend their concurrency budget on the few surfaces where it genuinely pays.

Preview Module 5 concretely. The output of this module is an approved, coherent canvas with named zones, clean tokens, and a merge log. Module 5 is about what happens next: the pipeline from that canvas to merged production code — spec extraction, implementation, parity checks against the approved frames, and a gate with an owner and evidence at every stage. The zones defined in this module's exercise map almost one-to-one onto that pipeline's work packages.