Designing the System.
Design is the stage where your constraint and knowledge map become a workflow with named owners — human and AI. It produces two things: Hybrid Accountability Chart entries that assign every accountability to a named supervisor, and a governance framework (autonomy levels, guardrails, escalation paths) that makes the system safe to operate. This chapter covers the frameworks for designing the system. The next chapter covers designing the work itself.
My integrator 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.”
I know the feeling on both ends of that sentence. The project coordinator had been with us long enough to know things — where the client files actually lived, which contacts needed extra lead time, what the unwritten rules were for each account. That knowledge doesn’t transfer with a two-week notice. It walks out the door and you spend the next three months paying a new person to relearn it while the work piles up. We’d been around this loop before and I could feel myself reaching for the job description template.
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 against a simple filter: which items required human judgment and relationships, and which were data-flow operations — 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 actually two — and one of those jobs, we could design an agent team for. We never posted the listing. The work shipped. The role got more strategic, not because we gave her a new title, but because we gave her back the hours that the low-judgment work had been consuming.
That question — “what is this work, actually?” — is the question Design exists to ask. And the framework for answering it is what this chapter introduces.
Design is the first stage of Execute & Compound. Everything before this was diagnosis. Everything after this is shipping. Design is the gate between the two — and the reason every sprint either compounds or stalls.
What Design produces.
Design has two deliverables, and they ship together.
The first is a designed workflow — specific enough that Build can execute against it without ambiguity. A workflow specification that names the inputs, the steps, the handoffs, the outputs, and the points where a human decides versus an agent executes. A sketch or a Miro board with sticky notes is not this. If Build has to ask “what did you mean here?” the workflow was described, not designed.
The second is a set of entries in the Hybrid Accountability Chart for the accountabilities this sprint is addressing. Each entry names the function, the agent team (if applicable), the human supervisor, and whether the work is AI-assisted or automated. A single sprint often produces multiple entries — 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 — the first piece of structural evidence that your company is operating as a Co-Intelligent Company rather than a human company that happens to use AI tools.
Design produces both or it has produced nothing. 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. The two deliverables are the same artifact viewed from two angles — one is the operational shape of the work, the other is the structural shape of the responsibility.
The Hybrid Accountability Chart.
The Hybrid Accountability Chart is the instrument that makes Design concrete. If you run on EOS, you already have an Accountability Chart — one name against each accountability in the company. The Hybrid Accountability Chart extends that idea to a workforce that includes agent teams alongside humans.
You build it one sprint at a time. For each accountability your sprint is addressing, you answer four questions — and you write the answers into the chart before Build begins:
- What role or function does this team perform? Not the task — the outcome this person or team is responsible for. “Produce accurate initial quotes within 2 hours of request” is an accountability. “Look up pricing” is a task.
- What is the name of the agent team, if applicable? Name it. Scope it. A team called “AI Helper” is not designed. A team called “Quote Generation Team” with a defined input (bid request + customer segment data) and output (draft quote with confidence score) is designed.
- Who is the human supervisor? Every row must have one. No exceptions. No “TBD.” No “the team.” A name. If you can’t name the supervisor, the design is not done.
- Is this accountability AI-assisted or Automated? AI-assisted means human-in-the-loop — reviews every output. Automated means human-on-the-loop — monitors by exception, reviews on schedule.
Here’s what your chart looks like after a handful of sprints — built up over time, with multiple rows per sprint when the constraint workflow touches multiple functions:
Every agent team in the chart has a human supervisor — every row, no exceptions. There are no unowned teams. This is a structural rule of the chart, not a soft principle. The reason is straightforward: humans are still responsible for making sure the organization accomplishes its goals. There needs to be a person you can talk to, work with, and hold accountable in the real world — someone who ensures the agents are performing on track and who owns the outcome when they are not.
If you run EOS, you already have the muscle for this. Your Accountability Chart says every seat has a name. The Hybrid Accountability Chart says every agent team does too. Same principle, extended to a workforce that includes non-human workers.
The four questions are not a template to fill in once and forget. They are a design discipline. Every sprint forces the four answers for every row — including the harder ones. “Who supervises this team?” is uncomfortable when the agent team is producing work nobody on the leadership team has owned before. That discomfort is the point. The chart surfaces it before any code is written.
The information flow question.
Before the chart makes sense, you have to answer a question most leadership teams never ask: how does information actually move through this part of the company?
Every accountability in a knowledge business is an information problem. The project coordinator isn’t “managing projects.” She’s taking information from one system, combining it with information from another system, applying rules she carries in her head, and producing an output that moves to the next person in the chain. The quoting process isn’t “creating quotes.” It’s pulling customer data from the CRM, matching it against pricing tables in the ERP, applying exception rules that live in a spreadsheet on someone’s desktop, and assembling the result into a format the customer can read. When you see the work as information flow, the design question changes. You stop asking “what tool should we use?” and start asking “what information does this work need, where does it live, and how should it move?”
That question produces what I call an information flow specification — a spec for how information moves through one accountability. It names:
- What data feeds the work (and which systems hold it)
- What transformations happen to that data (lookups, comparisons, calculations, formatting)
- What decisions get made along the way (and whether each decision is rule-based or judgment-based)
- What the output is and where it goes next
The best tool for making an information flow visible is a swim lane diagram. A swim lane diagram draws parallel horizontal lanes — one for each actor in the workflow (a person, a team, an agent, a system). Each step in the flow sits in the lane of whoever owns it. When data moves from one actor to another, a line crosses the lane boundary, and that crossing is a handoff. The diagram makes three things immediately visible: who does what, where information changes hands, and how many handoffs the workflow requires. A six-step process with twelve handoffs is a process designed to be fragile. You can see that on the swim lane before you build anything.
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.
How is this different from the Knowledge Map you built in Source? The Knowledge Map tells you what knowledge exists and where it lives — the inventory. The information flow spec tells you how that knowledge moves through a specific workflow — the transformations, the decisions, and the handoffs. The Knowledge Map is the atlas. The information flow spec is the route.
Most people don’t think about their company this way. They think in terms of roles and tasks. But roles are containers for information work, and tasks are steps in an information flow. When you write the flow down, you see where the bottlenecks actually live — and more importantly, you see which parts of the flow an agent can handle and which parts genuinely require a person.
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 information.
Once you can see the information flow, you need to know your options for connecting AI to it. There are five patterns, and the right one depends on what kind of information problem you’re solving.
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 transformations happen? 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.
This conversation works best when you give the AI enough context to reason about your specific workflow. 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. Use that instead of starting from scratch.
1. Skills reinforcing SOPs. The knowledge lives in people’s heads. It’s been captured (or will be captured in Source) as documented process — standard operating procedures, decision frameworks, institutional knowledge. The AI uses that documentation as context for brainstorming, iteration, and drafting. This is the co-operation pattern: you work alongside the AI in a conversational interface (Claude, ChatGPT), and the quality of the output depends on the quality of the documented knowledge. Most companies start here. It’s the lowest infrastructure lift and the fastest to show value.
2. RAG — retrieval-augmented generation. The knowledge lives in documents, records, or databases. The AI retrieves relevant chunks at runtime and uses them to generate answers, drafts, or analyses. This is how you make an agent that “knows” your company — it doesn’t memorize everything, it looks up what it needs when it needs it. RAG requires decisions about chunking (how you break documents into retrievable pieces), metadata (how you tag those pieces so the right ones surface), and freshness (how often the retrieval index updates). It’s more infrastructure than skills-on-SOPs, but it unlocks agent teams that can operate against your actual data without you manually feeding context every time.
3. Data pipelines. The knowledge lives in systems that need to talk to each other. The AI isn’t generating content here; it’s processing, routing, or transforming data between systems. The project coordinator’s report generation — pulling data from the CRM, formatting it, dropping it into a template — is a pipeline problem. No conversation needed. Just data in, transformation, data out. Tools like n8n, Make, or Zapier handle this kind of plumbing without requiring custom code.
4. Low-code integration tools. Platforms like Zapier, Make, or Power Automate that connect systems without writing code. These handle the routing and handoff problems that don’t need intelligence, just connectivity. They’re not AI, but they’re part of the design because they handle the pieces the agent team doesn’t need to touch.
5. Service layers and APIs. The AI operates as a service — accepting requests, processing them against defined logic, returning structured outputs. This is the most engineered pattern and the one that scales agent teams into production workflows. Your Build team (internal or external) implements this when the design calls for an agent team that operates reliably, at volume, with defined inputs and outputs.
You don’t need all five. Most first sprints use patterns one and two, with some pattern four for the routing work. The point is knowing what’s available so the design matches the information problem — not the other way around.
| Pattern | Best For | Infrastructure Level | Example |
|---|---|---|---|
| Skills reinforcing SOPs | Brainstorming, drafting, iterating on documented knowledge | Low — conversational AI + documented process | Working with Claude to draft client proposals using your SOPs |
| RAG | Answering questions or generating output from a large knowledge base | Medium — retrieval index + metadata + update pipeline | Agent that pulls relevant contract clauses when drafting agreements |
| Data pipelines | Moving and transforming data between systems on schedule | Medium — connectors + transformation logic | Pulling CRM data nightly, formatting scorecards, posting to Slack |
| Low-code integration | Routing, handoffs, and triggers that don’t need intelligence | Low — visual workflow builder | New deal in CRM triggers onboarding checklist in project management tool |
| Service layers and APIs | Production agent teams operating at volume with defined I/O | High — custom code, hosting, monitoring | Agent server that generates and assigns tasks daily via CRM API |
Don’t pick the technology pattern first. Map the information flow first, then ask which pattern fits. A skills-on-SOPs approach for a data pipeline problem wastes everyone’s time. A full service layer for a brainstorming use case is overengineered. Let the information tell you what it needs.
AI-assisted or automated.
The fourth question on the HAC is the one operators get wrong most often. They treat it as a technology decision when it’s a design decision.
Always start AI-assisted. Every accountability, every agent team, every sprint — begin with a human in the loop reviewing every output. No exceptions. The progression toward automation is not about reducing review frequency. It is about moving the human’s role toward exceptions and final decisions.
Here is what that progression actually looks like. The Quote Generation Team starts with a human reviewing every draft quote and sending the email to the customer. After the agent has proved reliable over several sprints, the next iteration shifts: the agent drafts and sends, but the human approves before the email goes out. Eventually, the design might move toward an agent on the website that fully automates quotes — subject to human approval before any contract is signed. The human never leaves the workflow. The human’s position in the workflow changes — from reviewing every output to approving final decisions and handling exceptions.
This is a spectrum, not a binary. And it shifts over time. Nothing about the agent changed across those sprints. What changed was the design — the leadership team learned which decisions the agent gets right reliably, which it does not, and where the human’s judgment is irreducible.
Start AI-assisted — always. Humans in the loop, reviewing every output, conservative by default. This is not a judgment call. It is the starting position.
Move toward automated when: the human is rubber-stamping more often than not. When the review consistently confirms what the agent already produced, the design is ready to shift the human’s role back — toward exception handling and final approval rather than line-by-line review.
The autonomy level is a governance decision, not a capability decision. The agent may be perfectly capable of running unsupervised. The question is whether your organization has the monitoring, the escalation paths, and the discipline to let it. Start with more guardrails than you think you need. Loosening guardrails is easy. Recovering from a bad output that went unreviewed is expensive.
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.
Design is where that call gets made deliberately, with the Human Orchestrator’s name attached to it — not three months after deployment when the team has quietly stopped reviewing outputs and nobody remembers deciding that.
Governance and guardrails.
The autonomy spectrum only works if there’s governance underneath it. Governance answers one question: what is this system allowed to do, and what is it not allowed to do?
Companies fail at governance from both directions. Some build the agent team first and figure out permissions later — after the wrong person has pulled data they shouldn’t have, or the agent has drafted a client-facing email nobody reviewed. Others let IT governance stall the project indefinitely, running review cycles that ensure nothing gets built at all. Both failure modes produce the same result: no working system. The framework is the middle path — define governance as a design decision before Build begins, but define it in the same session where you’re designing the workflow, not in a separate compliance review that lives on its own timeline.
There are five questions to answer for every agent team. 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.
1. What data can agents access? What’s off-limits? Name the systems, databases, and document sets the agent can read. Name what it can’t touch — customer PII, financial records above a threshold, strategic plans, anything regulated. Lock access down at the source, not at processing time. If the agent can reach the data, assume it will use the data. Design the boundary before you build the connection.
2. What actions can agents take without approval? What requires human sign-off? “Draft a quote” is different from “send a quote to a customer.” “Generate a report” is different from “distribute a report to the leadership team.” Draw the line at the point where the output leaves internal review.
3. What happens when an agent encounters something it wasn’t designed for? Define the escalation path. Who gets the flag? How fast? What does the agent do while it waits — pause, use a default, or continue with a warning?
4. How will you monitor output quality? Full review of every output (AI-assisted), spot checks on a sample (transition zone), or dashboard with exception flags (automated). Pick one and write it down.
5. What would cause you to shut down an agent workflow immediately? Define the kill switch. Agent sends customer-facing communication without review. Agent accesses data outside its permitted systems. Error rate exceeds a defined threshold. These aren’t hypothetical — they’re the conditions under which the system stops, and everybody on the team knows it.
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 co-operative (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.
The Human Orchestrator.
Design produces a workflow specification and an entry in the Hybrid Accountability Chart. It also produces a role: the Human Orchestrator for this accountability.
Every operator eventually asks: what does the human do when the AI does the work? The Human Orchestrator is the answer — a different job, and a more strategic one.
The Human Orchestrator sets the goals for the agent team. They design the workflow the agent team executes against. They own the outcome — the sprint’s measurable result against the constraint from Signal. They review the agent team at the goal level, not the task level — not checking every output line by line, but asking whether the team is moving the constraint in the right direction. And they make the design improvements between sprints. After every Compound phase, the Human Orchestrator looks at what the team produced and asks: what one design change would make the next sprint better? Eight sprints of one good design change each produces an agent team substantially more capable than the one that shipped in sprint one. That’s the compounding mechanism.
You met a version of this role in Chapter 2 — our marketing lead running four agent teams in parallel, each working a different piece of the same content project. Each one had a named tool, a scoped task, and her as the supervisor reviewing outputs. What I didn’t show you there is the Design work that made that shift possible. Someone had to sit down and ask what she was actually accountable for. Which parts of her job required her judgment, and which parts required execution that any well-designed agent could handle? Which teams needed to surface decisions to her, and at what frequency? Those questions got answered in a Design session before a single agent was built. The four-tab setup wasn’t improvised. It was designed — and because it was designed, her role didn’t shrink when the agents came in. It changed shape into something the original offer letter didn’t have a name for.
Finding the right person.
The Human Orchestrator role isn’t a title you assign to whoever’s available. It requires specific capabilities, and identifying the right person is part of the design work.
Everyone in a knowledge business will eventually need to become an orchestrator at some level. The skills involved are not exotic: context management — knowing what information each agent needs and when. Knowing what good looks like — being able to evaluate output quality without redoing the work yourself. The ability to communicate clearly across different agents and platforms. And a working understanding of the tools and information different agents need to be successful. If this sounds familiar, it should. It’s not that different from good management — creating the conditions for the people you’re responsible for to succeed. Orchestration is management extended to a workforce that includes agents. The same discipline, applied to a larger team.
The right person has authority over the workflow and the constraint outcome — not a project manager who coordinates, but an owner who decides. They need comfort with ambiguity, because the first few sprints will surface problems nobody anticipated and the Orchestrator has to adjust the design without freezing. And they need willingness to shift from executing to designing. The best candidate is usually the person closest to the work who’s also frustrated by the parts of it that don’t require their skill.
That third trait is the development gap. The operations lead who got the job because she was excellent at executing operations work is now being asked to design the operations function instead of running it. It’s a different role, and developing the capability is deliberate work, not a personality change.
This shift requires investment. Upskilling employees to work in an orchestration environment — learning the available tools, understanding what agents can and cannot do, and building the habit of thinking through problems systematically rather than executing them directly — is not optional. Budget for it. The operations lead who became an orchestrator did not wake up with those capabilities. She developed them over several sprints with deliberate support.
What does ramp-up look like? The first sprint is guided — the Orchestrator runs Design with support, either from a Compound coach or by working through the framework’s question sequence step by step. Someone experienced sits alongside them, not to do the work, but to coach the process. By the second sprint, they’re running the process independently. By the fourth, they’re improving it. The skill isn’t learned in a training session. It’s learned by doing the work, one sprint at a time, with the framework holding the structure while the person builds the muscle.
Identify your Human Orchestrator candidate. Ask: does this person have authority over the constraint outcome? Are they willing to shift from executing to designing? Write down the name. If there’s a development gap, name it — and plan the first sprint as the ramp-up, not as a test they need to pass.
The Human Orchestrator also owns the day-to-day operation of the agent team. Inputs clean. Outputs reviewed at the appropriate frequency. Flagging when the design is drifting — inputs degrading, outputs trending off, a class of decisions no longer being handled cleanly. Companies that deploy agent teams without a named person responsible for this operational layer discover within weeks that the team has drifted — inputs no longer reviewed, outputs no longer trusted, the workflow back to “we just do it the old way.” The fix is naming the role and giving it the hours. In a 25-person company, that is part of the Orchestrator’s existing role. In a 100-person company, the Orchestrator may delegate day-to-day monitoring to someone on their team — but the accountability stays with the Orchestrator. It does not float.
The Design Team.
In a company of 25, the Design session might be the CEO and one direct report at a whiteboard. In a company of 100, Design needs more structure — and that structure is a cross-functional Design Team with a charter.
The Design Team is a functional team, not a committee. It’s owned by leadership — typically the integrator or COO — and it has a defined scope: research the constraint, analyze it from multiple angles, benchmark against what’s possible, build a roadmap, and maintain a prioritized backlog of design work. The team includes the Human Orchestrator candidate, whoever understands the data and systems involved, and whoever has authority to make decisions about the workflow.
The charter is short. It says: this team owns the design of Human+AI workflows for the company. It meets on a cadence (weekly during active sprints, biweekly between sprints). It produces Hybrid Accountability Chart entries and workflow specifications. It does not build — Build is a separate stage with separate roles. And it does not operate in isolation — the constraint comes from Signal, the knowledge map comes from Source, and the design hands off to Build with everything Build needs to execute.
This matters because Design decisions affect multiple functions. The quoting workflow touches sales, operations, and engineering. The content production workflow touches marketing and client delivery. A Design Team with cross-functional representation catches the dependencies that a single-function design session misses — and produces workflows that the whole company can operate against, not just the function that requested the sprint.
The artifact that comes out of the Design Team’s work is a Design Brief — a comprehensive document that captures the design decisions, stakeholders, systems, and specifications needed to move into Build. The next chapter introduces the Design Brief in detail and shows how it connects to the Build Spec that developers execute against.
If you run EOS, you may find overlap between your L10 cadence and Design Team meetings — the constraint often comes out of your Quarterly Rocks, and the review rhythm is similar. But they’re not the same thing. The L10 drives the operating model. The Design Team designs the Human+AI workflows. Keep them distinct even if they share participants and timing.
The populated example.
Here’s what the Hybrid Accountability Chart looks like for a real constraint — Meridian Manufacturing’s quoting workflow from the previous chapters.
Constraint (from Signal): Elena Ruiz, VP of Operations, is the sole bottleneck for quoting — pricing exceptions, material lead times, labor estimates, and customer-specific terms all require her direct involvement, resulting in 3–5 day quote turnaround versus the 24–48 hour industry standard. Estimated annual cost: $558K in lost revenue, misallocated time, and floor underutilization.
Knowledge Map (from Source): HubSpot CRM with win/loss history (manual pipeline), JobBOSS ERP with job costing history and rate card (not connected to quoting), “Customer Notes.xlsx” — 147 rows of pricing exceptions on Elena’s desktop (cleaned to 112 validated rules during Build), two organic sources (Elena for pricing judgment, Dave Kowalski for fabrication hour estimation), two missing sources (historical quote-to-actual accuracy, customer segment profitability).
Hybrid Accountability Chart
| Role / Function | Agent Team | Human Supervisor | 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 |
Human Roles
Human Orchestrator: Elena Ruiz, VP of Operations. Owns the constraint outcome: reduce quote turnaround from 3–5 days to same-day for standard work. Sets the target: standard quotes delivered within four hours of RFQ receipt, with Elena’s review time under twenty minutes per quote. Reviews sprint results against that target. Makes the call on when to move any agent from AI-Assisted toward Automated. Elena reviews every draft quote in sprint one — all three agents start human-in-the-loop. Dave Kowalski provides labor hour estimates for non-standard work and is consulted when the agent encounters materials or tolerances outside its historical range.
Guardrails
- 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 cannot 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.
That’s one constraint, one sprint, five chart rows, a named Human Orchestrator, and five guardrail answers. The next chapter covers the work itself — Work Deconstruction, populated examples, prototyping, the Design Brief, and the gate checklist that separates Design from Build.
Reflection Questions
- For the constraint your sprint is targeting, fill in the four Hybrid Accountability Chart questions for at least one accountability: what is the role’s outcome (not task), what would you name the agent team, who is the named human supervisor, and is it AI-assisted or automated? If any field is blank, that blank is your Design session.
- When you look at the information flow for your constraint workflow — data in, transformations, decisions, data out — how many of the decision points are rule-based versus judgment-based? Which of the five connection patterns (skills on SOPs, RAG, data pipelines, low-code integration, service layer) fits the rule-based portion?
- Who in your company is the right Human Orchestrator for this sprint — the person with authority over the constraint outcome who is willing to shift from executing to designing? Name them out loud. If you have a development gap to fill before they can run the role, what does that ramp look like?
- Answer all five governance questions for your sprint’s agent team right now: what data can it access, what actions can it take without approval, what happens on unrecognized input, how will you monitor quality, and what triggers the kill switch? Any unanswered question is a Design gap that will surface in Build at five times the cost.