Workflow Integration & Solution Design
No audio recap for this lesson.
Screen 1: Workflow Integration & Solution Design
Module 4Introduction·4 min
There is a difference between "I use Claude" and "our workflow uses Claude. "
The first is a personal productivity habit. The second is a repeatable process, run by a team, where Claude performs specific steps every time. The value compounds only when you make that shift deliberately, and the shift can go awry when teams automate the wrong steps.
Consider two teams that adopted Claude for the same contract-review process. The first mapped the work and let Claude draft the redline while a lawyer owned every final decision; review time dropped by half and quality held. The second pointed Claude at the whole process and let it approve low-risk clauses unsupervised; within a month an approved clause created an obligation no one caught, and the team pulled the tool entirely.
Same product, same process. The difference was which steps each team chose to delegate.
This module is about making that choice well. The anchoring competency from the AI Fluency Framework is Delegation: deciding, for each step, whether the work is AI-appropriate, human-retained, or collaborative. Delegation done deliberately is what turns individual wins into workflow value.
By the end of this module, you will be able to:
- 1Apply Claude to analyze requirements and use cases.
- 2Leverage Claude for research, planning, and process optimization.
- 3Use Claude to support solution design, development, and iteration.
- 4Integrate Claude into existing workflows to augment or redesign them.
- 5Communicate Claude's value and limitations to stakeholders accurately.
Workflow value comes from deciding which steps to delegate, not from automating everything. Learn to analyze requirements with Claude, build plans on verified analysis, iterate on solutions, map a workflow against Delegation criteria, and describe the result to stakeholders without overstating what the tool can do.
We built this Associate course Module 4: Workflow Integration & Solution Design to help you get real work done with Claude. Treat it as educational content. It doesn't constitute legal, financial, or other professional advice, so adapt what you learn to your own situation. Our products and services evolve quickly, so certain content may contain errors or be outdated; remember to verify on Anthropic's website or docs. Examples and scenarios used in the course are illustrative and often fictitious. If the course material mentions a company or product, it doesn't mean Anthropic endorses them, they endorse Anthropic, or that we're affiliated. Also note your use of Anthropic products and services is covered by our terms, policies and documentation; if anything in this course conflicts with them, they control.
---
Screen 2: Analyzing Requirements and Use Cases with Claude
TeachingRequirements Analysis·9 min
Most real work starts from messy inputs: a long document, a thread of half-formed emails, a verbal ask. Before you can build anything, the requirements have to be extracted, structured, and pressure-tested.
Claude is a strong partner for exactly that translation, turning raw inputs into testable requirements others can act on. Claude can take unstructured material and return structure by pulling the requirements out of a document, organizing them, and flagging what is ambiguous or missing. Upload raw inputs and ask Claude for a structured analysis, rather than a narrative summary.
Translating business needs into task definitions
A business need stated as "we need better reporting" is not actionable. Claude can help convert that business need into specific task definitions: what report, for whom, how often, drawn from what data, and in what format. Each becomes a requirement you can build against and check completion on.
Worked example: an RFP response workflow
A proposal team responds to client RFPs. The inputs are a 40-page RFP document and a scattered email thread of internal answers. The recurring task: turn that into a structured list of answerable requirements.
The prompt
"From the attached RFP and the email thread, extract every distinct requirement the client is asking us to address. For each, give a short label, the exact RFP section it comes from, whether our thread already has an answer, and any requirement that is ambiguous and needs clarification. Return it as a table. "
The output: A requirements table the whole team can work from: each row a requirement, traced to its RFP section, marked answered or open, with ambiguities flagged for a clarifying question to the client.
This is a Project, not a one-off Chat. Past winning proposals live in the knowledge base, the Skills carry the formatting steps, and the standing instructions hold the extraction format. No technical build is required. The standing instructions and knowledge base live in the Project's configuration; the Skills live at the account level and apply everywhere, this Project included. Module 5 covers the configuration in depth.
Pressure-testing the requirements
Extraction is the first pass; pressure-testing is what makes the output trustworthy. Ask Claude to challenge its own list:
"Review the requirements you extracted. Which are ambiguous as written? Which could be interpreted two ways by our proposal team? Which imply a requirement the RFP states only indirectly? "
This surfaces the hidden requirements, the ones buried in a subordinate clause or implied by an evaluation criterion, that cost teams the bid when missed. The structured list plus a pressure-test pass is a far stronger foundation than either alone, and it is the Discernment habit from Module 3 applied at the requirements stage.
---
Screen 3: Research, Planning & Process Optimization
TeachingResearch & Planning·10 min
Planning work usually mixes two things Claude handles differently: synthesis, where it excels, and calculation, where it must be verified.
The strongest planning workflows pair Claude's synthesis with code-executed analysis, so the plan rests on numbers that were computed, not generated.
Research and synthesis
Claude can synthesize across sources to develop a plan: gather the considerations, structure the options, and lay out the trade-offs. For current information that post-dates training, web search in chat covers quick lookups and Research supplies the deeper up-to-date inputs. The synthesis is useful, and it is where unverified claims can enter, so the verification discipline from Module 3 applies throughout.
Code execution for verified analysis
When a plan depends on numbers, have Claude compute them. Upload the dataset and use code execution to run the calculations, produce trend charts, and process the files. A staffing plan built on a guessed utilization rate is a guess; one built on a code-executed analysis of the actual timesheet data is a plan.
Worked example: a capacity plan
An operations lead is planning headcount for next quarter. The workflow: upload the last four quarters of ticket-volume data, use code execution to compute the trend and the per-analyst throughput, then have Claude synthesize a staffing recommendation from the verified figures.
The prompt
"Using code execution on the attached ticket data, calculate quarterly volume growth and average tickets resolved per analyst. Then, from those figures, recommend the headcount needed to hold our current resolution time next quarter, and show the assumptions. "
The recommendation is only as trustworthy as the figures under it. Because the figures came from code execution rather than prose, the plan can be defended line by line. Identifying which steps of a plan are built on a number is how you decide where AI insight impacts the answer.
Where AI insight changes the plan
Not every step of a planning workflow benefits equally from Claude. The synthesis steps, where many considerations have to be weighed and structured, are where it adds the most. The judgment steps, where a person weighs risk appetite or political reality, stay human. A quick scan of a workflow for its synthesis-heavy steps tells you where to apply Claude and where to leave the call to a person.
For the capacity plan, Claude's leverage is in turning four quarters of data into a defensible recommendation; the decision to hire, against budget and hiring-freeze realities Claude cannot see, remains up to the operations lead.
---
Screen 4: Solution Design, Development & Iteration
TeachingSolution Design & Iteration·8 min
Claude is a design collaborator, not a vending machine. The value shows up in an explicit loop: ideate, prototype, gather feedback, refine.
Treating it as a loop, and keeping the design context stable across iterations, is what produces a solution rather than a pile of one-off drafts.
The iteration loop
Ideation produces options; a prototype makes one concrete; feedback exposes what is wrong; refinement fixes it; and the loop repeats until the solution holds. Running this inside a Project keeps the context, constraints, and prior decisions stable, so each iteration builds on the last instead of restarting.
Worked example: an internal process tool
A business analytics team needed a small internal tool to track and visualize a maintained set of metrics. Rather than commission a build, they had Claude produce it as a web artifact and iterated by asking.
"Build a simple dashboard artifact that shows these five metrics from the attached data, with a chart for each. " Claude produces a working artifact.
Knowing when to escalate
The artifact worked because it served a small team's internal need. When a solution becomes a system others depend on, with uptime, security, or integration requirements, it has outgrown Associate scope and belongs with Developer or Architect expertise.
That dependency is the escalation signal: the moment people rely on it as infrastructure, the build is no longer a prompt-and-iterate exercise.
---
Screen 5: Delegation Mapping: Redesigning Workflows with Claude Inside
TeachingDelegation Mapping·12 min
This is the core skill of the module. Before you redesign a workflow around Claude, map it step by step and decide, for each step, who owns it: AI, a human, or both together.
The mapping is judged on three criteria, and getting it right determines whether the workflow compounds value or quietly accumulates risk.
Three steps, three criteria
For each step in a workflow, classify it as AI-appropriate, human-retained, or collaborative, judged against:
Reversibility
Can the step be undone if Claude gets it wrong? Reversible steps tolerate more delegation; irreversible ones demand human involvement.
Stakes
What is the cost of an error at this step? High-cost steps stay human-owned or human-reviewed.
Accountability
Who is answerable for this step's outcome? Accountability does not delegate, even when the drafting does.
Building the redesign
Once mapped, embed the right feature at each AI step: a Skill for repeatable procedure steps, code execution for data steps. Consistency from a configured Skill beats heroic prompting that depends on remembering the right wording every time. The human-retained steps become explicit review gates, not afterthoughts.
Contract review is a common first-win workflow for business teams, so it is worth mapping fully.
Two worked maps, same criteria
Workflow step
Delegation
Why
Extract clauses from the contract
AI-appropriate
Reversible, low stakes, mechanical
Flag departures from the company playbook
AI-appropriate
Reversible; a Skill carries the playbook rules
Draft the redline and rationale
Collaborative
AI drafts, human judges each edit
Approve or reject each change
Human-retained
High stakes, accountability does not delegate
Compute financial exposure of a penalty clause
AI-appropriate (code execution)
Numeric; must be computed, not estimated
Sign and send
Human-retained
Irreversible, external, legally binding
Note that the AI does real work here, including the redline draft, not just a summary. The human owns the decisions and the irreversible steps. That split is the redesign.
The same three criteria produce a very different outcome when stakes and reversibility change. A People team generates offer letters and onboarding packets from templates.
Workflow step
Delegation
Why
Pull new-hire details from the HRIS export
AI-appropriate (code execution)
Mechanical, reversible, must be exact
Draft the offer letter from the approved template
AI-appropriate
Reversible draft; a Skill carries the template
Personalize the welcome note
Collaborative
AI drafts, hiring manager adds the human voice
Confirm compensation figures match the approved req
Human-retained
High stakes, accountability does not delegate
Send the signed offer
Human-retained
Irreversible, legally binding
Notice the pattern is identical to contract review even though the work is unrelated: mechanical and draft steps delegate, the figure-confirmation and the irreversible action are human-retained. The criteria decide the split.
Recognizing over-delegation
It is an incorrect approach to give AI more than the risk profile justifies: letting Claude approve clauses, or send the contract, because it drafted them well. Drafting quality is not a license to delegate the decision. When the map gives an irreversible or high-accountability step to AI, that is over-delegation, and it is exactly where the second team in the introduction went wrong.
Common mapping errors
Halo delegation. A step gets handed to AI because the previous step went well. Each step is judged on its own.
Collapsing collaborative into automate. "AI drafts, human reviews" quietly becomes "AI drafts" when the review gate is never actually staffed. A collaborative step with no real reviewer is an automated step.
Mapping the tool, as opposed to the work. Teams sometimes map around the features they like (a Skill they built) rather than the actual workflow steps. Map the work first, then adjust the features.
---
Screen 6: Communicating Value and Limitations to Stakeholders
TeachingCommunicating Value·8 min
Integrating Claude into a team workflow means describing it to people who did not build it: a manager, a client, a risk function.
Credibility comes from accurate claims, which means communicating the limits as clearly as the value. Overstating capability is how teams lose stakeholder trust on the first visible miss.
Describe capability accurately
State what Claude can reliably do for the use case and what it cannot, without inflation or false modesty. "Claude drafts the first pass redline, which a lawyer reviews" is accurate and credible. "Claude handles contract review" overstates and invites the question your first error will answer badly.
The same workflow, different audiences
Consider the contract-review workflow, interpreted from varied perspectives:
High literacy. "Claude extracts clauses, flags playbook departures, and drafts the redline. It does not approve changes, that gate stays with you. Known failure mode: it can miss obligations implied indirectly, so the playbook-departure flags are a prompt for your read, not a substitute. "
Outcome-focused. "Review time is down about half at the same approval standard. Every change is still approved by a lawyer before it leaves the building. "
Assurance-focused. "AI assists drafting; qualified human reviews and approves every term. No contract is sent without human sign-off. "
This is the same workflow and the same human gate. What changes is the detail each audience needs to trust it at.
Calibrate to the audience
Match the message to the audience's AI literacy. A technical stakeholder wants the feature detail and the failure modes; an executive wants the outcome, the oversight in place, and the risk posture. The expectation you set should match the capability boundary, so no one is surprised later. This is the Description competency from Module 2 applied outward: the same precise specification of what the tool can and cannot do, now directed at stakeholders rather than at Claude.
Document the human oversight
Name the review gates that stay in place. "Every output destined for a client passes human review" is the control that makes the workflow defensible. Stakeholders trust an AI workflow more, not less, when the human checkpoints are explicit.
Good and bad messaging, side by side
Overstated
Accurate
"Our new AI system reviews contracts automatically. " Sets an expectation the workflow does not meet and hides the human gate.
"Claude drafts the redline and flags playbook departures; our legal lead reviews and approves every change before anything is sent. The team's review time is down about half, with the same approval standard. " Value and limits in one breath.
"Fully automated" is almost never true, and the first visible error exposes it. "Claude handles X" collapses the human gate out of the sentence. "It's basically as good as a person at Y" sets a standard that the tool will eventually miss publicly. Each replaces a defensible, bounded claim with an inflated one. The fix is the same every time: state what the tool does, then identify the human checkpoint.
---
Screen 7: Exercise: Redesign a Workflow with Delegation Criteria
ExerciseRedesign a Workflow·7 min
Delegation mapping is the repeatable method for safer workflow integration. This exercise has you map a real workflow end to end, the way you would before redesigning one at work.
Below is an expense-report approval workflow. Classify each step as automate, human, or collaborative, and identify one step best served by a Skill and one by code execution. After you submit your answers, the model solution will be revealed with the reasoning for each step.
The workflow
Come back to this exercise before the quiz. The quiz scenarios use the same delegation-mapping decisions you practice here.
---
Screen 8: Module 4 Quiz: Workflow Integration & Solution Design
QuizModule 4·5 min
Five scenario-style questions. Each presents a situation; select the response that best applies the module's integration framework. Approximately five minutes.
Return to complete the quiz before advancing.
---
Screen 9: Key Takeaways
Module 4Key Takeaways·5 min
Five things that hold across this module:
Delegate deliberately, do not automate indiscriminately.
Workflow value comes from choosing which steps Claude does, not from handing Claude everything.
Claude is a requirements-analysis partner.
Feed it messy inputs, get structured, traceable, testable needs others can act on.
Build plans on verified numbers.
Pair Claude's synthesis with code execution so the figures under a plan are computed, not generated.
Map every step against three criteria.
Reversibility, stakes, and accountability decide whether a step is AI-appropriate, human-retained, or collaborative.
Communicate limits as clearly as value.
Accurate capability claims with the human review gates named are what earn and keep stakeholder trust.
All product behavior descriptions are based on claude. ai features as of June 2026. Feature availability and behavior should be verified against current Anthropic documentation at publish:
- AI Fluency Framework: Delegation competency
- Claude Help Center: Projects, Skills, code execution, and artifacts in workflows, support. claude. com
- Anthropic docs: building with Claude for analysis and planning, platform. claude. com/docs
---
Screen 10: Congrats! You’ve successfully completed this module.
Module CompleteAssociate Path·2 min
You can now map any workflow against delegation criteria and redesign it safely. Integrate with intention: Claude amplifies your team without adding risk.
M1: Product & Model Selection
Choose the right entry point, model, and features for any given task.
M2: Prompting
Build structured prompts and adapt them to the task type.
M3: Output Evaluation
Validate output and know when human review is non-negotiable.
M4: Workflow Integration
Map a workflow against Delegation criteria and redesign it safely.
M5: Configuration
Configure and maintain Projects, instructions, and knowledge.
M6: Governance
Apply use-case, data, policy, and ethics judgment responsibly.
M7: Troubleshooting
Diagnose underperformance and optimize workflows when results fall short.
M8: Course Summary & Next Steps
Recap the journey, prepare for the exam, and recognize escalation boundaries to the Developer and Architect tracks.