Designing the System: Design names who owns every part of the work

In Brief

Design starts by mapping how information moves through one workflow. From that map, it builds a Hybrid Accountability Chart — every accountability named as an outcome, every agent team named, every Human Orchestrator named. It sets the autonomy level for each row. And it locks governance before Build inherits anything. Those decisions are the Design row of your Sprint Planning Canvas. After this chapter, you can produce the four architecture deliverables: a designed workflow, a populated Hybrid Accountability Chart, autonomy levels, and a governance framework ready for Build.

Sofia, our VP of Operations, is on a weekly call and she’s not building up to it. “She’s not keeping up with clients. Reports are late. I think we need to let her go.”

The project coordinator had been with us long enough to know where the client files lived, which contacts needed extra lead time, and what the unwritten rules were for each account. In most companies, that knowledge doesn’t transfer with a two-week notice. You spend the next three months paying a new person to rebuild it while the work piles up. We were partially protected against that loss. We’d lived Source: her workflows were documented, her exception rules captured, the systems she touched mapped. Losing her didn’t mean losing what she knew.

The hiring impulse doesn’t care about any of that. The work still needs doing, and the instinct is to reach for the job description: post the listing, find someone, get them trained, keep the work moving.

I stopped and asked a different question. Not “who should we hire?” but “what does this role actually do?”

We opened a blank document and started pulling the role apart.

We listed the sources of information that fed the job: the CRM, the project tracker, the report templates she’d built, the client check-in cadence she managed from memory.

Then we listed the outcomes the role was responsible for: the reports delivered, the tasks created, the assignments made, the clients kept on track. And then we mapped every accountability — every named outcome the role owned — against a simple filter: which items required human judgment and relationships, and which were data-flow operations.

Data-flow operations meant information moving from one system to another, following rules that didn’t require a person in the middle. The shape of the role changed in front of us.

What had looked like one job was two, and one of those jobs we could design an agent team for.

So we did. And we did let her go — without posting a listing for a replacement.

Instead, the work got absorbed into the company without a crisis. The team didn’t miss a beat.

What the agent team took on was the administration: the routing, the formatting, the status updates. What stayed with people was the judgment. The work got more strategic for the people who stayed, not because we gave anyone a new title, but because we gave them back the hours the low-judgment work had been consuming.

Design exists to ask what the work actually is

Design produces four deliverables, and they land together:

A designed workflow — the inputs, the steps, the handoffs, the outputs, and the points where a human decides versus an agent executes.
Hybrid Accountability Chart entries for every accountability this Sprint touches.
Autonomy levels for each row — AI-Assisted or Automated.
A governance framework — data access, permitted actions, escalation paths, quality monitoring, and kill-switch conditions.

The per-agent mini-spec and tool-category choice are produced in the next chapter, Designing the Work.

The first deliverable has to be specific enough that Build can execute against it without ambiguity. If Build has to ask “what did you mean here?” the specification isn’t finished. A single Sprint often produces multiple entries in the chart; the PM workflow we ran internally generated five in its first pass. Over many Sprints, the chart fills in. After one Sprint, it has its first rows.

Design has to produce all four. A workflow without an accountability entry is a process map nobody owns. An accountability entry without a designed workflow is an org chart row with nothing behind it.

But before you can assign owners, you’ve got to see the work itself. Every accountability bundles three kinds of work: physical action, information processing, and the judgment applied to that information. The information layer is the part Design can redesign. That’s where Design starts.

See the work as information flow first

Before the chart makes sense, you’ve got to answer a question most leadership teams never ask: how does information move through this part of the company?

Not every part of the work is information. AI can’t stack boxes in the warehouse, but it can reconcile the receipts against the ERP. A treasurer compiling the weekly cash report is doing information work even in a business that moves physical product. Whatever your company makes, an information layer runs through every role.

A salesperson assembling a proposal pulls quote history from the CRM, current pricing from a rate sheet, and available capacity from the ops calendar — then applies judgment about what the customer needs.

An account manager preparing a renewal pulls usage data from the product, contract terms from the file, and relationship context from memory.

An analyst turning source systems into a board report pulls from three databases, applies formatting rules, makes presentation decisions.

The information moves through each of them. In every business, the information layer follows the same structure: something comes in, gets processed by rules or judgment, and goes out as a usable result.

That structure is what the Information Flow Specification captures — a one-accountability spec that pins down the data feeds, processing steps, decisions, and output for a single workflow.

The Knowledge Map you built in Source is the parts inventory: what knowledge you’ve got and where it’s stored. The Information Flow Specification is the assembly line — how those parts move through the workflow to become the finished output.

Knowledge Map vs Information Flow: Source maps what knowledge exists and where it lives; Design maps how it moves through one workflow.

An Information Flow Specification names four things:

Data feeds — what data feeds the work, and which systems hold it
Processing steps — what happens to it: lookups, comparisons, calculations, formatting
Decisions — what gets decided, and whether each is rule-based or judgment-based
Output — what it is and where it goes

Most people don’t think about their company this way. They start with roles and tasks. The value of the information flow is that it forces you to start with the outcome instead and work backwards. What does this accountability produce? Who receives it? What has to happen for that output to exist? When you answer those questions first, the roles and tasks fall into their correct positions in the flow.

How to write the Information Flow Specification

Name the accountability — Pins the spec to one specific outcome so you’re describing a workflow, not a job description.
List the data feeds — Forces you to name every source system and document set that supplies raw material to the work, surfacing hidden dependencies.
Document the processing steps — Makes the processing work visible — lookups, comparisons, calculations, formatting — so you can later decide what a rule covers versus what requires judgment.
Classify each decision: rule-based or judgment-based — This split is the design hinge: rule-based decisions are AI-automatable; judgment-based ones require a human in the loop.
Define the output and its destination — Anchors the spec to a measurable deliverable and names who or what receives it, enabling handoff design downstream.
Draw the swim lane diagram — Puts every actor and every handoff on one page, making fragile multi-handoff flows immediately visible before anything is built.

Name the accountability

State the one outcome the workflow produces — as a result, not a role. A result has a finish line you can measure; a job category doesn’t. “Produce a customer-ready draft quote from an incoming RFQ” is an accountability. “Quoting” is a job category.

More examples of outcome framing:

Deliver a weekly client status report from data already in the CRM — not “account management.”
Route and log incoming support tickets to the right team within one hour — not “support ops.”
Produce a signed subcontractor agreement from an approved statement of work — not “contracts.”
Reconcile daily job costs against the ERP and flag variances above $500 — not “cost accounting.”

If you can’t state the outcome in one sentence that names a deliverable, a standard, and a timeframe, the row isn’t ready to go into the chart.

List the data feeds

Walk the workflow and name every system and document that supplies input — the CRM, the ERP, a pricing spreadsheet maintained by one person, a shared drive folder of templates. Pull them straight from the Knowledge Map you built in Source; if a source isn’t on the Knowledge Map, it isn’t an authorized data feed. Write every one down. Missing a data feed here means discovering the gap in Build, where it costs more to fix.

Document the processing steps

Trace, in order, what happens to the data — the lookups, matches, calculations, and formatting that convert raw input into output. Be sequential and specific: each step should name an action, not a category.

Examples from different workflows:

Match the incoming support ticket to the customer’s account record → look up open issues for that account → route to the assigned account manager
Pull yesterday’s job cost entries from the ERP → compare against approved budgets → flag any line over 10% variance → format the exception report
Receive the signed contract → extract the start date, rate, and deliverable list → create the project in the PM system → send the kickoff checklist to the delivery lead

Classify each decision

For every decision point in the processing steps, ask one question: could a documented rule decide this, or does it need a person?

Rule-based decisions are the ones you can write down as “if X, then Y.” They’re consistent, documentable, and AI-automatable. Examples:

If the ticket’s issue type matches a known error code, route it to Tier 1
If the material cost is within 5% of the last purchase price, approve automatically
If the quote total is under $10,000, format it as a standard PDF; above that, flag for Sales review

Judgment-based decisions require context, relationship, or experience you can’t fully specify. Examples:

Whether to approve a non-standard discount for a long-term client (depends on relationship history, competitive pressure, margin targets the agent can’t weigh)
Whether a support escalation needs executive attention (depends on tone, account size, and relationship context)
Whether a candidate resume is worth a first interview (depends on team fit, growth trajectory, things a rubric doesn’t capture)

This split is the design hinge. It determines which parts of the workflow an agent can own and which require a human in the loop.

Rule of thumb: if the decision has ever been made the same way twice with the same inputs, it’s probably rule-based. If you’d want a specific person in the room before making the call, it’s judgment-based.

Define the output and its destination

Name the deliverable — what it is, who or what receives it, and the standard it has to meet. A draft quote delivered to the sales lead’s review queue within two hours of RFQ receipt is a designed handoff. “The quote goes out” is work that stops somewhere and hopes someone picks it up.

Draw the swim lane diagram

Put every actor on one page: one lane per actor (a person, an agent, a system). Place each step in the lane of whoever owns it. Every line that crosses a lane boundary is a handoff.

A six-step process with twelve handoffs is fragile before you build anything. The swim lane lets you see that on paper. For information flows between humans and agents, two lanes are usually enough to start — one for human work, one for agent work. As the design matures, you can split the agent lane into individual agent teams and add lanes for external systems.

Count the handoffs. If the number is higher than the number of steps, simplify the design before moving forward.

Try This

You can have an AI draw the swim lane for you — drop in the Information Flow Specification you just built and paste this prompt into Claude or ChatGPT:

“Here’s a workflow. Actors: [list]. Steps in order: [list]. Where data hands off between actors: [list]. Draw this as a swim-lane diagram — one horizontal lane per actor, each step in its owner’s lane, and mark every point where data crosses from one lane to another as a handoff. Output it as a Mermaid diagram I can paste into a renderer.”

You don’t need diagramming software or a designer. The Information Flow Specification you produced in the steps above is all the input this prompt needs. See the Prompt Appendix for a pre-built version ready to fill in.

Meridian’s Information Flow Specification

Elena’s quoting workflow, pulled apart into the four fields:

Meridian's quoting Information Flow Specification: data feeds, processing steps, decisions (rule vs judgment), and output.

Field	Meridian quoting
Data feeds	HubSpot CRM (customer history and deal data); JobBOSS ERP (job costing history and rate card); “Customer Notes.xlsx” (112 validated pricing exception rules, Elena’s desktop)
Processing steps	Match RFQ to customer record; look up applicable rate card; apply exception rules; assemble draft quote in customer-facing format
Decisions	Rule-based: standard material pricing, lead-time lookup. Judgment-based: non-standard tolerances, strategic account discounts
Output	Draft quote delivered to Elena for review within four hours of RFQ receipt; exception cases flagged to Elena or routed to Dave Kowalski

Swim lane diagram: information flow between human and agent lanes with handoff points marked

Action Step

Pick one accountability from your constraint workflow. Write down the information flow: what data comes in, from where, what happens to it, what goes out, to whom. Don’t describe the role — describe the information. This is the foundation for everything Design produces.

How AI connects to the flow

Once you can see the information flow, you can decide where AI fits. There are five ways AI connects to an information workflow:

Draft alongside — AI works against your documented SOPs, producing drafts a human reviews before anything ships
Retrieve on demand — AI pulls from your documents at the moment the workflow calls for them (RAG — retrieval-augmented generation — a technique where the AI looks up relevant pieces of your knowledge base at the moment it needs them, rather than memorizing everything in advance; covered in the Source chapter)
Move data on a schedule — a data pipeline (an automated connection between two systems that moves or syncs records on a set cadence) handles regular syncs between systems
Fire on a trigger — AI activates when a specific event occurs: a new deal closes, a form is submitted, an exception threshold is crossed
Run as a background service — AI accepts requests and returns structured outputs continuously, without a human initiating each run, within the data access and permitted actions defined in governance

Most first Sprints use one or two of these. Knowing what’s available means the design matches the information problem — not the other way around.

Meridian’s quoting workflow combines two: RAG handles the exception rules in Elena’s spreadsheet, and a data pipeline handles the nightly CRM pull.

Try This

Paste your Constraint Statement and information flow into Claude or ChatGPT and ask: “What information does this workflow need? Where does each piece live? What processing steps happen — lookups, comparisons, calculations, formatting? What decisions get made?” Then follow up: “Which of these decisions are rule-based and which require judgment?” The AI won’t know your business, but the questions will force you to articulate what you might otherwise skip.

The Prompt Appendix at the back of this book includes a full prompt template for information flow analysis, pre-structured so you can drop in your Constraint Statement, data sources, and workflow steps and get a useful decomposition back.

The Hybrid Accountability Chart assigns owners to the flow

The Hybrid Accountability Chart takes the Accountability Chart structure from the Co-Operating Model chapter and adds rows for agent teams — same discipline, new workforce.

Every row names one accountability and one named owner; now some rows also name the agent team doing the execution work underneath that owner.

You build it one Sprint at a time. For each accountability your Sprint is addressing, work through these steps and write the answers into the chart before Build begins:

How to build the Hybrid Accountability Chart

Name the role/function as an outcome, not a task — Outcome framing defines what the row is accountable for; task framing describes activity with no clear success criterion.
Name the agent team (or mark None) — A named team can be pointed to when something goes wrong; a vague label names nothing useful and dissolves accountability.
Name the Human Orchestrator — Every agent team must have one named human who owns the outcome; blank or shared cells are a governance failure waiting to surface in production.
Apply the Right Seat Evaluation to the Human Orchestrator candidate — Sees It / Wants It / Suited for It. An Orchestrator who fails any of the three tests means the chart has a name in the column but ineffective supervision underneath it.
Set the autonomy level: AI-Assisted or Automated — This is a governance decision, not a capability decision; the level determines how much human review sits between the agent output and any consequential action.
Answer the five governance questions for each row — Data access, permitted actions, escalation path, quality monitoring method, and kill-switch conditions must be written down before Build begins.

Name the role/function as an outcome

Apply the same outcome framing from the Information Flow step: state the result the row is accountable for, not the activity inside it. The same test applies — if you can’t state it in one sentence with a deliverable, a standard, and a timeframe, the row isn’t ready for the chart.

Name the agent team (or mark None)

Every agent row gets a short, specific name that states the team’s function — “Quote Research Agent” or “Invoice Reconciliation Agent,” not “AI Helper” or “Assistant Bot.” A name that states the function is something you can point to when output is off; a generic label dissolves accountability when something goes wrong. Name the team by what it does, not by the model it runs on — the model is a Build detail covered in the next chapter. If there’s no agent team for a row, mark it explicitly as None so the chart is complete and readable at a glance.

Name the Human Orchestrator — and apply the Right Seat Evaluation

The Human Orchestrator is the existing employee whose role the Sprint upgrades. The Orchestrator directs the agent team, reviews its output, and handles exceptions once the workflow ships. It’s a workflow-level role, scoped to the one accountability the Sprint targets.

Naming the Human Orchestrator is a deliberate decision. The Right Seat Evaluation is the three-test discipline that makes the call:

Sees It — does this person understand the work the agent does well enough to evaluate whether the output is correct, or will they rubber-stamp because they can’t tell the difference?
Wants It — are they genuinely accountable for the outcome, or do they treat the agent team as someone else’s problem with their name attached?
Suited for It — do they have the judgment, context, and authority to override the agent when it drifts and make the calls the agent can’t?

If the Orchestrator candidate fails any of the three tests, the HAC has a name in the column but no one capable of running what’s underneath it. Choose someone else, or build the human development plan that gets the candidate to all three tests passing before the Sprint runs.

Examples:

The VP of Operations who built the quoting process and knows every pricing exception — passes all three. The coordinator who inputs the data but doesn’t set prices — fails Sees It for this workflow.
The Sales Lead who runs client negotiations and has final authority on deal terms — passes for a contract delivery workflow. The admin who handles scheduling — probably doesn’t have the authority dimension of Suited for It.
The Finance Director who signs off on job costing variances — passes for a cost reconciliation workflow. An analyst two levels below who runs the reports — may fail Wants It if exceptions aren’t their call.

Rule of thumb: the right Human Orchestrator is the person closest to the tasks that produce the outcome they’re accountable for.

Pro Tip

If you run EOS, you already have the muscle for this. Your Accountability Chart says every seat has a name. The Hybrid Accountability Chart extends that same discipline to your agent teams. The naming rigor you already apply to human roles now applies to non-human workers too.

How the Human Orchestrator runs the agent team day-to-day — review cadence, exceptions, drift — is the next chapter, Designing the Work.

Start AI-Assisted. Earn Automation.

The autonomy level is the fourth field on the HAC. It’s a governance decision, not a capability decision. Getting it wrong in the early Sprints is how agent teams lose trust — and once an operator stops reviewing outputs, the errors they miss are expensive.

AI-Assisted means a human reviews every output before anything consequential happens. The agent does the work; the human holds final authority on every result. Use AI-Assisted when:

The agent is new and hasn’t proven its accuracy over multiple Sprints
The exception rules aren’t fully documented yet — there are edge cases the documented rules don’t cover
The output reaches a customer, partner, or financial record directly
The Human Orchestrator needs to learn the workflow’s failure modes before reducing review frequency

Not every accountability moves toward Automated. Some work stays AI-Assisted permanently by design — ephemeral or one-shot work where the setup cost of full automation doesn’t pay, and anything where human judgment is irreducible (consistent with the judgment-based decisions you classified in the Information Flow Specification, and with the “Not AI-tier” sources from the Source chapter). The progression earns automation where it’s earnable. Some work never leaves AI-Assisted, and that’s correct, not a failure.

Examples:

Elena reviews every draft quote before it leaves the building — AI-Assisted
The finance director reviews every cost reconciliation exception before it’s marked resolved — AI-Assisted
The hiring manager reviews every screened candidate profile before scheduling an interview — AI-Assisted

Automated means the agent’s output ships without per-item human review. The human’s role shifts to monitoring aggregate quality, handling exceptions the agent surfaces, and making final decisions on edge cases. Use Automated when:

The agent has proven reliable over multiple Sprints (the Human Orchestrator is rubber-stamping more often than correcting)
The exception rules are fully documented and the agent handles them consistently
A monitoring system can catch errors before they compound
The kill switch is defined and the team is prepared to use it

Examples:

Inbound support tickets are automatically routed and logged, with the support lead reviewing a daily exception report rather than every ticket — Automated
Job cost entries are automatically reconciled nightly, with the finance director reviewing only the flagged variances — Automated
RFQ intake is automatically logged to the CRM and triggers the quoting workflow, with no human in that first routing step — Automated

Rule of thumb for moving along the spectrum: when the Human Orchestrator is spending more time confirming what the agent already got right than catching what it got wrong, it’s time to move toward Automated for that step. Don’t move early. The cost of a bad output that went unreviewed can be higher than the cost of reviewing outputs a few weeks longer than necessary.

AI-Assisted to Automated spectrum: human role shifts from reviewing every output toward exceptions and final decisions

Action Step

For each accountability in your constraint workflow, place it on the AI-Assisted-to-Automated spectrum. Write down your rationale — not just the label, but why. “AI-Assisted because the exception rules aren’t fully documented yet” is a rationale. “AI-Assisted” by itself is a checkbox.

Lock governance before the build begins

Governance answers one question: what is this system allowed to do, and what is it not allowed to do? Define it as a design decision — in the same session where you’re designing the workflow. Build the agent team first and figure out permissions later, and you’ll find those gaps in production, where they cost more.

Pro Tip

Companies fail at governance from both directions: some build first and govern later; others let governance stall the project indefinitely with review cycles that ensure nothing ships. Both produce the same result: no working system. Make it a written set of answers before Build begins — not a policy document that arrives after deployment.

There are five questions to answer for every agent team:

What are the agent’s permission boundaries?

Two sides of the same question: what can the agent read, and what can it do without approval?

Data access: Name the systems, databases, and document sets the agent can read. Name what it can’t touch — customer PII, financial records above a threshold, anything regulated. Lock access at the source, not at processing time. Example: can read CRM deal records and the pricing exception database; can’t read payment history, employee records, or supplier contracts.

Permitted actions: Draw the line at the point where output leaves internal review. “Draft a quote” isn’t “send a quote.” Example: can draft and flag; can’t send any communication to a customer, close or resolve tickets, or modify pricing tables.

What happens on an input the agent wasn’t designed for?

Define the escalation path: who gets the flag, how fast, what the agent does while it waits — pause, default, or continue with a warning. Examples:

If the RFQ references a material not in the database, flag to the VP of Ops and hold
If the job cost entry is missing required fields, flag to Finance and skip that line
If the ticket volume exceeds the routing model’s training range, flag to the support lead and queue for manual review

How will you monitor output quality?

Full review (AI-Assisted), spot checks on a sample (transition), or dashboard with exception flags (Automated). Pick one before Build begins. Examples:

Elena reviews every draft quote during Sprint 1 — target: zero substantive corrections for three consecutive weeks before considering the move to exception monitoring
Finance spot-checks 20% of reconciled entries weekly during the first quarter
Support lead reviews the exception dashboard daily once routing accuracy exceeds 95% for 30 days

What would make you shut the workflow down immediately?

Define the kill switch — the specific, non-hypothetical conditions everybody on the team knows. Examples:

Any customer-facing communication sent without the named reviewer’s approval
Any data accessed outside the permitted system list
Error rate above a defined threshold on three consecutive days
Any pricing modification the agent made without a documented rule authorizing it

Write the answers down. If any answer is “we haven’t decided yet,” that’s the decision you make now — not in Build, and not after deployment. If the agent can reach data, assume it will use that data. Design the boundary before you build the connection.

Pro Tip

The question “does this workflow need an interface?” is a governance question in disguise. If the accountability is fully automated, it probably doesn’t need one — data in, data out, humans monitor by exception. If it’s AI-Assisted with a human in the loop, the human needs a way to interact. That interaction might be working alongside the AI in Claude or ChatGPT, or notification-based (approvals via Slack or Teams). The interface decision follows from the autonomy level, not the other way around.

Meridian’s governance answers

Meridian's five governance answers: data access, actions without approval, escalation, quality monitoring, and kill switch.

Governance question	Meridian quoting
Data access	Agent teams can read HubSpot CRM deal records, JobBOSS ERP job costing history and rate card, and the cleaned pricing exceptions database (112 rules). Off-limits: financial reporting, employee records, customer payment history, supplier contracts, and any system not listed.
Actions without approval	Agents can draft quotes, pull data, and flag exceptions. Agents can’t send any communication to a customer, modify pricing tables, or apply undocumented pricing exceptions.
Escalation path	When the agent encounters an input it wasn’t designed for — unknown material, missing ERP data, RFQ confidence below 60%, or pricing deviation greater than 15% from the closest historical match — it flags Elena and holds until she resolves or routes to Dave (materials) or Mark Ellison (strategic account pricing).
Quality monitoring	AI-Assisted phase: Elena reviews every draft quote. Target: zero substantive corrections for three consecutive weeks on an agent’s output before considering the move to human-on-the-loop.
Kill switch	Any quote reaching a customer without Elena’s review. Agent accesses data outside its permitted systems. Pricing errors exceed 20% on three quotes in any week.

Who’s in the design room

Design decisions affect multiple functions. The quoting workflow at Meridian touches sales, operations, and engineering. A single-function design session misses the dependencies that cross those lines — and produces a workflow the rest of the company can’t operate against.

In a small company, the design session is usually the operations manager and the person accountable for the outcome — a tight pair that can move fast when the constraint is contained to one function and the decisions are clear.

In a 100-person company, include a small cross-functional group: whoever understands the data and systems, whoever has authority to make workflow decisions, and the Human Orchestrator candidate. Cross-functional representation catches the dependencies. Keep it tight — the goal is decisions, not consensus.

The design decisions get captured in a Design Brief, which the next chapter details.

Meridian’s populated Hybrid Accountability Chart

Meridian’s quoting constraint from Signal put Elena Ruiz at the center: sole bottleneck, 3–5 day turnaround. Now it has a chart. Five rows. Three with agent teams running under Elena as Human Orchestrator. Two human-only rows where the accountability requires relationship and judgment.

Blank Hybrid Accountability Chart: one row per accountability — outcome, agent team, Human Orchestrator, autonomy level.

Hybrid Accountability Chart (Meridian): every row names an outcome, the agent team, the Human Orchestrator, and the autonomy level.

Role / Function	Agent Team	Human Orchestrator	Level
Customer data retrieval and history matching	Quote Research Agent	Elena Ruiz (VP Ops)	AI-Assisted
Material and labor pricing assembly	Quote Pricing Agent	Elena Ruiz (VP Ops)	AI-Assisted
Draft quote generation and review	Quote Assembly Agent	Elena Ruiz (VP Ops)	AI-Assisted
Quote delivery and customer negotiation	None	Ty Banfield (Sales Lead)	N/A — human judgment
Non-standard material and tolerance consultation	None	Dave Kowalski (Sr Design Engineer)	N/A — human judgment

Every row has a name. Every agent team has a named Human Orchestrator. All three agent rows start AI-Assisted — Elena reviews every draft quote. That’s the governance decision for Sprint 1. Autonomy is earned as the agent proves itself over subsequent Sprints.

Human Orchestrator: Elena Ruiz, VP of Operations. Her role changes with this chart: not every quote, but operating the workflow that produces them. She reviews every draft in Sprint 1. Her target: standard quotes delivered within four hours of RFQ receipt, with her review time under twenty minutes per quote. She makes the call on when the workflow’s autonomy level advances from AI-Assisted toward Automated.

The governance answers above apply to all three agent rows.

Reflect on your operation

Pick the constraint workflow your Sprint is targeting. For at least one accountability: what is the role’s outcome (not task), what would you name the agent team, and who is the named Human Orchestrator? Apply the Right Seat Evaluation — does this person See It, Want It, and have what it takes to run it? If any field is blank, that blank is your Design session.
When you look at the information flow for your constraint workflow — data in, processing steps, decisions, data out — how many of the decision points are rule-based versus judgment-based? Where does the design hinge?
Place each accountability on the AI-Assisted-to-Automated spectrum. What’s your rationale for each choice? If you wrote the label but can’t write the reason, the design isn’t finished.
Answer all five governance questions for your Sprint’s agent team right now. Any unanswered question is a Design gap that will surface in Build at five times the cost.

The next chapter takes these design decisions — the workflow, the accountability chart, the autonomy levels, the governance answers — and covers how the Human Orchestrator runs the agent team once it ships: review cadence, exceptions, drift, and the Design Brief that locks the gate before Build begins.