Step 3: Design Your AI Workflow¶

Part of: Business-First AI Framework

What This Is¶

The Design phase is where you decide how your workflow should be built — before you build it. You take the Workflow Definition from the Deconstruct step and make design decisions. The Design skill supports both step-decomposed and outcome-driven Workflow Definitions:

For step-decomposed definitions, you make five design decisions:

1. Architecture decisions — What platform are you using, and what integrations and constraints does the Workflow Definition reveal?
2. Autonomy assessment — Where does the whole workflow sit on the autonomy spectrum (Deterministic → Guided → Autonomous)?
3. Orchestration mechanism — Who drives the workflow (Prompt, Skill-Powered Prompt, or Agent)?
4. Autonomy classification — How much AI assistance does each step need?
5. Building block mapping — What specific AI components does each step require?

For outcome-driven definitions, the flow is streamlined — autonomy (Autonomous) and orchestration (Agent) are pre-determined by definition. The Design phase focuses on:

1. Architecture decisions — Platform and tool integrations extracted from capability domains
2. Involvement mode — Augmented or Automated, determined from the definition's human gates and trigger type
3. Capability domain mapping — What integrations, intelligence, and reusable skills does each capability domain need?
4. Agent configuration — The primary design artifact: agent blueprints drawn from the definition's goal, constraints, and expected outputs
5. Evaluation criteria — Carried forward from the definition's quality criteria, with supplementary questions as needed

Why This Matters¶

Not every workflow needs the same level of AI infrastructure. A weekly status report might need a single well-crafted prompt. A multi-department content pipeline might need specialized agents coordinating across stages. Choosing the wrong orchestration mechanism means either over-engineering (building agents when a prompt would do) or under-building (forcing a prompt to do agent-level work).

Design also maps each step to specific AI building blocks — Prompt, Context, Skill, Agent, MCP, Project, API, or SDK — so you know exactly what to build. The recommended implementation order (quick wins first, complex agent steps last) gives you a practical sequence for rolling out AI incrementally.

Architecture Approach¶

Before any other decisions, choose how you'll build your workflow. This is the first fork in the road — it shapes which platforms, tools, and building blocks are available to you.

Which approach fits?¶

The model analyzes your workflow and recommends an approach based on these signals:

Most workflows start no-code. Code-first becomes the right choice when you need programmatic control, integration into existing systems, or production-grade deployment. The same three orchestration mechanisms (Prompt, Skill-Powered Prompt, Agent) apply to both approaches — the architecture approach determines how you implement them, not what you implement.

Architecture Decisions¶

Before assessing autonomy and choosing an orchestration mechanism, the model gathers the information that shapes platform-aware recommendations. Rather than walking through a checklist, it uses an extract-then-confirm approach: ask one question, extract everything else from your Workflow Definition, and present the analysis for confirmation.

One question: Platform. The only thing not already in your Workflow Definition is which AI platform you'll use. If you've already mentioned it in conversation, the model confirms. If not, it asks — and accepts whatever level of specificity you provide ("Claude Code", "ChatGPT", "Google Gemini", "Claude" are all fine). The model doesn't try to disambiguate to a specific offering upfront — the ecosystem is enough for Design decisions, and the specific tool is resolved during Build when generating artifacts.

Everything else is extracted from the Workflow Definition:

• Tool integrations — pulled from data flows, context needs, and step details across all steps. The model lists the tools identified but defers platform availability research to the Build step.
• Trigger/schedule — pulled from your Scenario Metadata. Time-based triggers are noted as scheduled execution requirements with implications for involvement mode and infrastructure.
• Browser access — if any step involves logging into a website, it's flagged during step classification rather than asked about separately. The connection details are handled during Build.
• Shareability — deferred to Build, where it determines artifact format (file-based vs. code-based). Not asked during Design.

Code comfort and deployment surface are inferred from the platform choice when specific (Claude Code = CLI + code-comfortable, ChatGPT = web + no-code) or resolved during Build when vague.

After extracting, the model presents a single confirmation block showing the platform, extracted tool integrations with availability mapping, trigger implications, and any flags — then asks if anything was missed or needs adjustment. The confirmed decisions gate all subsequent recommendations.

Autonomy Assessment¶

Before choosing an orchestration mechanism, the model assesses where the whole workflow sits on the autonomy spectrum. This is the same spectrum used for per-step classification later — applied at the workflow level.

Deterministic ———————— Guided ———————— Autonomous
(fixed path)       (bounded decisions)     (context-driven path)

The model presents this as a confident assessment — for example: "This workflow is Guided because most steps follow a fixed sequence, but the research step involves bounded judgment about which sources to pursue." If you disagree, you discuss and adjust.

Orchestration Mechanism¶

Based on the autonomy assessment and architecture decisions, the model recommends who drives the workflow. The orchestration mechanism answers: who follows the steps?

Single-agent vs. multi-agent is an architecture detail decided during agent configuration (later in Design) if "Agent" is selected — not a top-level choice here.

The model presents a confident recommendation — for example: "Based on your workflow's Guided autonomy and the two reusable sub-routines I identified, I recommend Skill-Powered Prompt with Augmented involvement."

If you disagree, the model explains the alternatives and you discuss. Most workflows start as Prompt or Skill-Powered Prompt and evolve toward agents as you add automation.

When the orchestration mechanism is Agent and the platform has multiple agent offerings (e.g., Claude Code sub-agents vs. Claude Agent SDK), the model asks which offering you want to use — this determines the artifact format in the Build step.

Human Involvement¶

The orchestration mechanism recommendation includes an involvement mode — whether a human participates during the workflow run:

The involvement mode is determined by your architecture decisions — platform, scheduled execution needs, and which steps require human review. See the AI Workflow Design Matrix for how autonomy and involvement combine into six workflow archetypes.

Autonomy Classification¶

For each step in your Workflow Definition, classify it on the autonomy spectrum:

Building Block Mapping¶

Map each AI-assisted step to one or more of the AI building blocks:

Also identify for each step:

• Tools and connectors — What external tools, APIs, or integrations does this step need?
• Human-in-the-loop gates — Where should a human review before the workflow continues?

Skill Candidate Identification¶

Steps that should become skills share these characteristics:

• Reusable — The logic appears in multiple workflows or will be run repeatedly
• Complex — More than a simple instruction; involves multi-step reasoning, evaluation criteria, or domain expertise
• Consistent — Needs to produce reliable, repeatable outputs every time

For each skill candidate, document enough detail for generation:

This detail enables generation of skills on any platform during the Build step.

Agent Blueprints¶

When the orchestration mechanism is Agent, document each agent your workflow needs. These are platform-agnostic specifications — the model builds them into working agents during Build. Whether the workflow needs one agent or multiple agents is decided here based on the number of distinct roles, expertise domains, and orchestration needs.

Plus:

• Context — What data, files, or knowledge base does the agent need access to?
• Goal — What triggers this agent and what does it produce?

For multi-agent workflows, also document:

• Orchestration pattern — Supervisor (one agent delegates), pipeline (agents in sequence), or parallel (agents work simultaneously)
• Agent handoffs — What does each agent pass to the next? What format?
• Human review gates — Where does a human review output before the pipeline continues?

This agent configuration is platform-agnostic — it serves as a blueprint. During the Build step, the model researches your chosen platform's current tools and generates platform-appropriate agent implementations.

Outcome-Driven Design Flow¶

When your Workflow Definition has Definition Type: Outcome-Driven, the Design phase takes a streamlined path:

• Autonomy is Autonomous by definition — the agent system determines its own execution path
• Involvement mode (Augmented vs. Automated) is still determined from the definition's Human Gates section and trigger type
• Orchestration is Agent — the primary design artifact is the agent configuration
• Capability domain mapping replaces per-step classification — for each domain (research, analysis, writing, etc.), the model maps integration needs, intelligence requirements, and whether the domain should become a reusable skill
• Evaluation criteria are carried forward from the definition's Quality Criteria section rather than gathered from scratch
• Agent Configuration becomes the primary section of the spec, with instructions drawn from the definition's Goal, Constraints, and Expected Outputs

The output is the same AI Building Block Spec format, with Capability Domain Mapping replacing the Step-by-Step Decomposition table, and an Autonomy Statement replacing the Autonomy Spectrum Summary.

How to Use This¶

This step is facilitated by the design Business-First AI Framework Skill. How you get it depends on your platform — see Get the Skills for installation instructions.

Start with this prompt:

Design the AI workflow from my Workflow Definition.
Assess the autonomy level, recommend an orchestration mechanism, and map building blocks.

Upload or paste your Workflow Definition file ([workflow-name]-definition.md) from the Deconstruct step when prompted. The skill runs the Design analysis and produces an AI Building Block Spec.

Two phases, two modes¶

Design has two distinct phases that use different modes of interaction with the model:

Phase 1: Collaborative decisions (normal conversation)

The first part of Design is a back-and-forth conversation. The model scans your Workflow Definition for known answers, confirms what it can infer, asks about anything genuinely unknown, assesses the workflow's autonomy level, recommends an orchestration mechanism and involvement mode, and you discuss and confirm. This is normal conversational mode — you're making decisions together.

Phase 2: Plan the spec (plan mode)

Once the architecture decisions, autonomy level, and orchestration mechanism are locked in, the model has everything it needs to plan the full AI Building Block Spec. This is when you activate plan mode — the model shifts from asking you questions to planning: classifying each step on the autonomy spectrum, mapping building blocks, identifying skill candidates, and documenting agent blueprints.

How to activate plan mode on your platform:

After the model produces the plan, review and approve the AI Building Block Spec before moving on. If anything needs adjustment — a step classification, a skill candidate, an agent blueprint — now is the time. Once you approve, the model transitions to Build (Step 4) and begins building.

What This Produces¶

The AI Building Block Spec contains:

• Architecture approach — No-code or Code-first, with rationale and recommendation signals
• Autonomy level assessment — Deterministic, Guided, or Autonomous, with rationale for where the whole workflow sits on the spectrum
• Orchestration mechanism — Prompt, Skill-Powered Prompt, or Agent, with involvement mode and reasoning
• Architecture decisions — platform, tool integrations (with connector mapping), trigger/schedule implications, and any flags (browser access, infrastructure needs) — each with rationale and a constraints summary showing how they shaped the recommendations. Deployment surface, code comfort, and shareability are resolved during Build.
• Code-first selections (when applicable) — specific API and SDK choices per step with justification (e.g., "Claude Agent SDK for the research agent because it needs tool use and multi-step orchestration")
• Scenario summary — workflow metadata from the Workflow Definition
• Decomposition table — every step with autonomy classification, decision points, failure modes, data flows, context needs, AI building block mapping, and skill candidate flags
• Autonomy spectrum summary — steps grouped by classification level
• Skill candidates — steps tagged for skill creation, with generation-ready detail (purpose, inputs, outputs, decision logic, failure modes)
• Agent blueprints (when applicable) — platform-agnostic specification for each agent with all five core components plus context and goal
• Step sequence and dependencies — sequential vs. parallel execution paths
• Prerequisites — what must be in place before the workflow can run
• Context inventory — every piece of context the workflow needs, with status and key contents
• Tools and connectors — external integrations required
• Implementation order — quick wins → semi-autonomous → complex agent steps

This AI Building Block Spec is the input for Step 4: Build, where the model generates platform-appropriate artifacts (prompts, skills, agents, connectors) based on your orchestration mechanism and architecture decisions.