Operating a Design Agent Team

This is the closing module of the course, and it deliberately contains no new orchestration patterns. Modules 1 to 5 covered when to split work, how to structure fan-outs, pipelines and critic pairs, how to chain MCP tools, how to run concurrent agents on a canvas, and how to build canvas-to-production pipelines with gates. All of that can work brilliantly for one motivated person and still fail as a team capability, because nobody owns the harness, nobody can say what last month cost, and review quietly became the bottleneck nobody planned for.

Frame the module as the difference between a demo and an operation. A demo needs one good run. An operation needs the run to be repeatable by someone other than its author, affordable at the volume the team actually produces, reviewable without burning out the reviewers, and explainable when something goes wrong. Those four properties — repeatable, affordable, reviewable, explainable — map directly onto the module's sections: harness ownership and onboarding, cost and budgets, review capacity and gates, audit trails and failure review.

Set the expectation that some of this material is unglamorous on purpose. Permissions tables and operating agreements do not demo well. They are also the parts that decide whether the capability survives its first incident, its first invoice surprise, and its first staff change.

The figures here are date-stamped on purpose: every price referenced in this module was captured from official vendor pages on 1 June 2026, and pricing has changed at all three major vendors within the eight weeks before that date. Treat the numbers as a snapshot and the structure as the durable part. The structure is a three-rung ladder — entry tiers around $20 a month, middle tiers around $100 pitched at daily professional use, and top tiers around $200 pitched at all-day use — plus a bring-your-own-key route where you pay for the model rather than the seat.

What actually differs between vendors is metering, and orchestration multiplies whatever you choose. Subscription windows give a rolling allowance; a four-worker fan-out plus a critique agent on a heavy day exhausts it and the team waits. Credit metering never stalls, but the same fan-out costs several normal days of usage, and the surprise lands on the bill instead of on the schedule. BYOK tracks spend to actual tokens, which agencies billing clients love and finance teams without an owner for key management hate.

The operational point for this module: parallel and background agents are precisely what the middle and top tiers exist for. If the team's workflows lean on the patterns from Modules 2 to 5, budget for the tier above the one that looks sufficient on paper, and measure a normal week before committing — the meter is better evidence than any heuristic.

The shift this slide asks for is small but structural: stop reasoning about the subscription and start reasoning about workflows. A subscription is one number that nobody can act on. A per-workflow view — this is what the monthly audit costs, this is what a concept exploration costs, this is what the reporting cycle costs — turns cost into a series of small, reviewable decisions that the people running the workflows can actually own.

The budget question column matters more than precise dollar figures. For most workflows the honest comparison is against the manual alternative: the design ops report that replaces a day of screenshots and spreadsheets, the audit that replaces a week of clicking through screens. Where the comparison comes out badly — a workflow that consumes real spend and real review attention and produces findings nobody actions — the right move is to cut or redesign it, and teams need explicit permission to do that without treating it as an indictment of the whole approach.

The last row carries the discipline: exploratory runs deserve headroom, because that is where new workflows come from, but a capped pool rather than per-run accounting. The boundary rule — anything repeated twice gets promoted to a named workflow with a budget — keeps exploration from becoming the place where untracked spend hides.

The permissions conversation goes wrong when it is framed as a referendum on whether agents can be trusted. The more useful framing is that agentic work forces the team to write down something that was always true but rarely explicit: which surfaces are high blast radius and who may change them. A token file change propagates everywhere. A shared component change lands in every product that consumes it. A push to main or a publish to a live site is visible to users. Those surfaces were already supposed to be controlled; agents just make the volume of change high enough that informal control stops working.

In practice the controls live in three places. Platform permission systems and sandboxes decide what an agent session may touch — directory scope, allowed commands, whether it can push or publish. MCP credentials decide what connected tools allow — and most design-tool MCP servers can be connected with read-only scopes, which is enough for the majority of chained workflows from Module 3. Repository and canvas permissions decide what merges or publishes regardless of who or what proposed the change.

The operating principle is asymmetric: be generous on scratch space and drafts, because that is where iteration speed lives, and strict on the surfaces where mistakes propagate. And keep the map versioned next to the harness — a permission scheme that lives in one person's memory does not survive that person's holiday.

Audit trails sound like compliance overhead until the first time someone asks where a change came from and the honest answer is an agent did it and we are not sure why. The volume agents produce is exactly what makes informal memory stop working: when one person merged three changes a week they could reconstruct the story; when workflows land thirty changes a week nobody can.

The good news is that most of the trail is infrastructure the team already has, used consistently rather than built from scratch. Diffable artifacts and version control — the foundation laid back in the design-as-code material — mean every change is already a diff with an author, a timestamp, and a reviewer. What agentic work adds is two requirements. First, the change should reference what produced it: the brief, the saved workflow command, or the orchestration run, so a reviewer can judge the change against its intent rather than guessing. Second, approval must be attributable to a person. Checks can pass automatically; accountability cannot be automated, and the approver's name on the gate is what makes the review gates from Module 5 mean something.

Reporting closes the loop: the design ops reporting workflow this module draws on requires every figure in a report to link to the script, export, or findings file that computed it. That same standard — numbers with provenance — is what makes an operations review possible at all, and it is why the worked example later in this module can be argued about productively.

Walk the diagram left to right, then land on the cadence band, because the band is the part teams skip. Harness ownership covers the instruction files, skills, agent definitions, and saved workflow commands the whole course has been building — versioned in the repo, changed through the same review gate as anything else, and owned by a named person or pair, typically a design lead or a platform-design pairing. Budgets and cost is the per-workflow view from the previous slides, owned by whoever actually signs the invoice. Review gates carry the permissions, audit trail, and accountability material — the gate is only real if a named reviewer holds it and an escalation path exists for when it fails. Reporting is the design ops reporting workflow: agents assemble adoption, QA debt, and throughput evidence, every figure links to its computation, and the report stays a draft until the lead signs it.

The cadence band is the difference between an operating model and a diagram of one. Weekly spend checks catch the workflow that quietly tripled in cost. Per-change gates and audit entries are continuous. The reporting cycle produces the signed artifact leadership sees. The quarterly review is where the harness, the permission map, and the policies themselves get re-examined — because the platforms, prices, and tools underneath this all churn, and an operating agreement written in January is partly wrong by June.

The ownership point bears repeating: every box on this diagram has an owner line at the bottom. That is deliberate. Shared ownership of operations reliably means no ownership.

This is the constraint the whole course has been pointing at. Module 1 listed multiplied review as part of the coordination tax; Module 2's orchestrator role owned the merge log; Module 5's pipeline put a gate at every stage. Operations is where those add up to a number: how many reviews per week the team's senior people can actually do well, and what happens when the workflows produce more than that.

The tiering is what makes the number manageable. Executable checks — token audits, type checks, accessibility scans, screenshot comparisons — run on everything and cost no human attention. Critic agents reviewing against explicit criteria filter the obvious misses, with the limits the critic-pair pattern already covered: a critic catches criteria violations, not taste. Human judgment then goes only to what survives, which is where it belongs. Teams that skip the tiering end up with senior designers spending entire days reviewing agent output, which is both a morale problem and a quality problem, because attention degrades long before the queue empties.

Two failure patterns to name explicitly. Rubber-stamping: when the queue grows, approvals get faster and shallower, and the gates from Module 5 become theatre — the audit trail will show suspiciously uniform approval times if you look. And the parallelism reflex: the instinct when output slows is to add more agents, which is exactly backwards when the constraint is the reviewer. Reducing parallelism to match review capacity is usually the change that improves both speed and quality.

Onboarding is the test of whether the team built a system or a collection of personal setups. If everything important lives in the harness — the instruction files, the skills, the agent definitions, the saved workflow commands, the conventions for the shared canvas — then a new designer inherits most of it by cloning the repo and reading three documents: the operating agreement, the permission map, and one traced run of a real workflow with its review notes. If the important knowledge lives in the heads of the two people who built the workflows, onboarding takes six weeks and the capability has a bus-factor problem regardless of how good the patterns are.

The sequencing matters. New people start on surfaces where mistakes are cheap: audits, explorations, scratch-branch prototypes. Their early briefs get reviewed before their outputs do, because briefing quality is the leading indicator — a designer who writes sharp briefs and sensible review criteria can be trusted with bigger surfaces quickly; one who skips the gates cannot, regardless of seniority. That is also why autonomy should expand by surface rather than by tenure: access to the design system repo or publish rights follows demonstrated review judgment, which the audit trail conveniently documents.

One caution: do not turn onboarding into tool training. The platform CLI takes an afternoon to learn. The team's standards, conventions, and judgment about what good looks like are the actual content, and the harness plus reviewed practice is how those transfer.

Governance earns its bad reputation when it is written by people who do not run the workflows, applied per run instead of per surface, and never revisited. The strangling column is not a caricature; each row is a real policy pattern that produces the same outcome — designers route around the official path, usage goes unmonitored precisely because it is unofficial, and the organisation ends up with less visibility and more risk than if it had set enabling rules up front.

The enabling column shares one design principle: govern the things that are stable — surfaces, workflows, budgets, reviewer roles — rather than the things that happen hundreds of times a week. A pre-approved workflow with a named owner, a budget, and a gate does not need per-run permission. A new tool, a new MCP connection with write access, or a new surface does need a decision, once, recorded where the next person can find it.

The reporting row deserves an explicit pause because it is where governance most often poisons trust. The design ops reporting workflow this module draws on builds the boundary into the synthesis agent's own instructions: throughput is reported as team-level distributions, never per person, and the report informs prioritisation conversations rather than performance reviews. The moment per-person numbers appear, people optimise for the report instead of the work, and the cooperation the whole system depends on evaporates. Put that boundary in the operating agreement and in the agent definitions, so it survives staff changes on both sides.

The failure review exists for the same reason post-incident reviews exist in engineering: the first serious failure decides whether the team learns or retreats. Without an agreed process, the default response is either to quietly stop using the workflow — losing the capability over one incident — or to quietly absorb the failure and change nothing, which guarantees a repeat.

The sequence on the slide is deliberately ordinary. Containment is cheap precisely because of the operational choices made earlier: diffable artifacts, scratch branches, gates before publishing — reverting a merged diff or restoring a canvas snapshot is minutes, which is the strongest practical argument for those choices. Reconstruction uses the audit trail; if the trail cannot answer which brief produced this and who approved it, that gap is itself the first finding. Diagnosis is where discipline matters: the agent was wrong is where the analysis starts, not where it ends. Almost every real failure traces to a layer humans own — a brief that under-specified, a harness rule that did not exist, a check that was not run, a gate that was rubber-stamped because the reviewer was saturated, or a surface that should never have been writable by an agent in the first place.

The fix should land in the layer, and the harness is usually where it goes — the same loop the fundamentals course established, where recurring corrections get encoded rather than repeated. And close every review with the proportionality question: does this failure mean the workflow needs a better gate, or that this surface should go back to fully manual? Both are legitimate answers. Deciding deliberately is the difference between operating a system and being operated by it.

This example is assembled from the case studies documented in the school's design ops reporting workflow — a five-squad organisation tracking adoption quarter over quarter, and a design ops lead replacing a day of manual assembly — read here through the operations lens of this module. The figures are from those documented runs, not a benchmark; say so when presenting.

Walk the rows as the four layers of the operating model doing their jobs. The reporting layer produced the headline trend — 61 to 78 percent token coverage across six repositories over two quarters — and because every number linked to the counting script and the per-repo JSON, the squad leads argued about what to fund next rather than disputing the measurement; the gain concentrating in the two repos the previous review had funded is what evidence-led prioritisation looks like when it works. The cost layer is undramatic, which is the point: the run took about 40 minutes, the lead's effort dropped from a day to roughly two hours per cycle, and the keep-or-cut review removed a weekly report variant nobody read.

The review-capacity row is the honest one: the audit workflow was producing findings faster than squads could action them, which is the bottleneck-moves-to-attention problem in miniature. The fix was to slow production to match absorption — less parallelism, longer cadence, capped findings — exactly the counterintuitive move the review-capacity slide argued for. And the backlog finding shows the synthesis boundary working: the correlation between stale component requests and low-coverage squads was flagged as a question for humans to investigate, not asserted as a conclusion. The follow-up conversation, not the report, found the cause.

The exercise asks for a draft, not a policy programme. One page is a forcing function: it keeps the agreement at the level of surfaces, workflows, owners, and cadences, and below the level of legalese nobody will maintain. The five sections mirror the module — workflows and budgets, gated surfaces and permissions, review and checks, reporting boundaries, failure response and cadence — so participants can lift answers directly from the slides and from their own current practice.

Steer people towards honesty over aspiration. The agreement should describe what the team will actually do next month, not an idealised operation: if there is no design ops report today, the reporting line might be a single adoption count per quarter; if review capacity is one senior designer, the workflow list should be short enough for that person to gate properly. An agreement that promises more review than the team can deliver is worse than a modest one, because it trains everyone to ignore the document.

Two details disproportionately predict whether the agreement survives. Writing it with the people who will live under it — the designers running the workflows and at least one engineering counterpart for the gated surfaces — rather than presenting it to them. And scheduling the first quarterly review before circulating it, because the platforms, prices, and tools underneath this module all churn, and the agreement is only trustworthy if its own expiry is built in. If participants did the earlier modules' exercises, the workflow list and the canvas conventions they already drafted slot straight into sections one and two.

Close the module by tying the operating layer back to the course's opening argument. Module 1 said more agents is a cost, not a feature, and that the coordination tax has to be repaid by the task. Operations is where that accounting becomes visible at team scale: the per-workflow budgets, the review-capacity planning, and the keep-or-cut reviews are the mechanism that keeps the team honest about which orchestrated workflows actually repay their cost — and gives it permission to cut the ones that do not without abandoning the capability.

For where to go next: the school's curriculum continues in three directions. Designers who want to strengthen the foundations under this course should work through the briefing, harness, and critique material in Agentic Design Fundamentals if they have not already — every operating problem in this module gets easier when briefs and harnesses are strong. Those responsible for the production side should go deeper on the design-to-code and design-system courses, which expand the pipeline and audit material from Modules 5 and 6. And for the facts that this module deliberately date-stamped — pricing, plan structures, platform changes — the school's pricing and platform articles are re-verified on a recurring cadence and are the reference to check before any decision; the figures cited here were captured on 1 June 2026 and will drift.

If participants drafted the operating agreement, the closing ask is simple: put the first quarterly review in the calendar now, and bring the signed first design ops report to it. An operating model that has survived one honest review cycle is no longer a course exercise; it is how the team works.