Claude for Work

Most organisations adopting Claude go through the same arc. A few people try it, get impressive results on a handful of tasks, and become enthusiastic. Everyone else tries it, gets mediocre results, and concludes it is overhyped. The difference between the two groups is almost never prompt wording — it is structure.

This curriculum is about the structure. It assumes participants can already type a question into a chat box, and addresses what turns that into work a team can rely on: persistent project context, repeatable document pipelines, honest judgement about what to delegate, and written conventions so the whole team works the same way.

From chats to projects

Module one addresses the most common pattern holding teams back: treating every task as a fresh conversation that begins by re-explaining the organisation, the audience, the tone, and the constraints.

Projects hold that context persistently. Participants build one for a real recurring task, loading the background material, style guidance, and reference documents the work genuinely needs. The test is whether a colleague can open the same project and produce comparable output without inheriting any of the original author's unstated assumptions. That test fails often on the first attempt, and fixing it is the module.

Long documents, done properly

The second module covers the capability that most changes what is possible day to day: sustained work across long documents. Contracts, research papers, board packs, interview transcripts, regulatory filings.

Participants learn to structure this work rather than pasting a long document and asking for a summary. That means specifying what is being extracted and in what format, working section by section where fidelity matters, asking for source passages alongside conclusions so claims can be checked, and recognising the failure mode where a summary is fluent, plausible, and quietly wrong about a detail that matters.

Teams build a pipeline for whichever document task they actually repeat most.

Knowing what not to delegate

Module three is the judgement session, and it is deliberately deflationary. Participants inventory their real tasks and sort them by suitability against two axes: how well the model performs, and how expensive verification is.

The useful cases are where performance is good and verification is cheap — drafting, restructuring, first-pass extraction, exploratory analysis. The trap is tasks where output looks authoritative and verification is expensive, because the time saved in drafting is repaid with interest in checking. Teams leave with an explicit list of both, and with a verification requirement attached to each category rather than left to individual discretion.

Making it stick across a team

The optional second day produces the written conventions that determine whether any of this survives the month after the workshop: which uses are approved, which data categories may be used and under what deployment, what must be reviewed before it reaches a client or the public, where shared projects live, and who maintains them.

This is unglamorous and it is the difference between a team that adopted a tool and one that attended a workshop.

Related curricula

Engineering teams should look at loop engineering and agent harness engineering instead. Organisations on other stacks have equivalents: ChatGPT for work, Microsoft Copilot for work, and Google Gemini for work.

Related reading

• Claude for work: a practical guide
• What are agent skills? A complete guide
• Claude Code commands: complete reference
• How to actually work with AI agents: a communication guide

Sessions are delivered by explainx.ai and adapted to the organisation's document types, data policy, and functions.