Troubleshooting and Optimisation · Lesson 4 of 4

7.4 — Optimising a Workflow for Efficiency

Make a working Claude-based workflow faster and lower-friction to run repeatedly through reusable Projects, prompt templates, right-sized model choice, and front-loaded instructions.

Getting a Claude-based workflow to produce correct output once is a different achievement from making it cheap and easy to run correctly every week, or every day. Once a workflow works, the remaining question is efficiency: how much friction, time, and cost does it take to run it again the next time, and the time after that? Optimisation here isn't about squeezing out marginal quality gains — it's about removing unnecessary repeated effort from a process that's already correct.

Reusable Projects Instead of Rebuilding Context Every Time

A recurring task — drafting weekly reports, triaging a category of support tickets, reviewing a type of document against the same standard — shouldn't require re-explaining the role, the rules, and the background context in a fresh conversation each time. A claude.ai Project lets you set that context once: a system prompt describing the role and rules, and knowledge base files holding reference material the task depends on (a style guide, a policy document, a schema). Every new conversation inside that Project starts with all of it already in place, so each run only needs the one thing that actually varies — this week's notes, this ticket's content. Rebuilding the same context by hand in a fresh, generic conversation every single time is wasted repeated effort that a Project setup removes once and for all.

Prompt Templates for Recurring Tasks

For a task run often enough to have a stable shape, save the message itself as a reusable template with clear placeholders for the parts that change ("Summarize the attached notes into three sections: Decisions, Action Items, Open Questions. Notes: [paste here]"). This does two things at once: it removes the friction of re-deciding how to phrase the request every time, and it front-loads the clear, specific instructions that produce good output on the first try, rather than the requester improvising a slightly different, vaguer version of the request each run and needing a follow-up message to correct it.

Right-Sizing Model Choice for Routine vs. High-Stakes Runs

Model selection (covered earlier in this course) is also a workflow-efficiency lever, not just a one-time capability decision. A routine, high-volume, low-stakes run of a recurring workflow — classifying incoming requests, drafting a first-pass summary that a person will review anyway — is a good candidate for a faster, lighter model: the speed and cost savings compound every time the workflow runs, and a human review step catches the occasional miss. A high-stakes run of the same general workflow — the one attached to a client-facing deliverable, or a legal or financial document — still warrants the most capable model available, because an error there costs far more than the model-tier savings are worth. Optimising for efficiency doesn't mean using the cheapest option everywhere; it means matching the setting to the stakes of each specific run rather than defaulting to the most expensive option out of habit.

Front-Loading Instructions to Reduce Back-and-Forth

A workflow that technically works but requires two or three follow-up correction messages every single time it runs isn't actually efficient, even if the final output is fine — each of those extra turns costs time and, in a Console/API context, additional tokens. If the same correction ("also include the date," "shorter, please," "don't forget the disclaimer") keeps getting sent after the first response on every run, that correction belongs in the reusable Project instructions or the prompt template itself, not repeated by hand each time. The pattern to watch for in your own recurring workflows is a correction you find yourself typing more than once — that's a signal the first-draft instructions should be edited so the correction is never needed again.

Key Concept

Once a workflow works, optimise it for repeated use: put stable role, rules, and reference material in a reusable Project instead of rebuilding context each run; save recurring requests as templates; match model choice to each run's actual stakes rather than defaulting to the most expensive option; and fold any correction you're repeating by hand into the instructions themselves so it's front-loaded instead of re-sent every time.

Common Exam Distractor

An answer suggesting the most capable, most thorough model should be used for every run of a recurring workflow "to be safe" sounds cautious but isn't efficient — it ignores the actual stakes of routine, human-reviewed runs and pays a real cost every single time the workflow executes. Likewise, watch for an answer proposing to keep re-writing the same context from scratch each run "to keep things fresh" — that's exactly the repeated effort a reusable Project setup exists to remove.

Exam traps

Rebuilding the same role, rules, and reference material by hand in a new conversation every time a recurring task runs

A claude.ai Project holds that stable context once so every new conversation starts with it already in place — re-typing it each run is unnecessary repeated effort a Project setup eliminates.
Defaulting to the most capable, most expensive model for every run of a routine, high-volume, human-reviewed workflow

Model choice should match each run's actual stakes; using the top-tier model for low-stakes, reviewed-anyway output pays a real recurring cost without a corresponding benefit.
Repeatedly sending the same follow-up correction after every run instead of updating the underlying prompt or Project instructions

A correction sent more than once on the same workflow is a signal that the fix belongs in the reusable instructions themselves — front-loading it removes the recurring back-and-forth for every future run, not just the current one.

Practice question

A team runs the same Claude-based weekly ticket-triage workflow every Monday. Each week, someone pastes a fresh explanation of the triage rules into a brand-new conversation, uses the most capable available model regardless of ticket complexity, and then sends a follow-up message reminding Claude to include a priority tag, since it's often missing from the first response. What combination of changes would most improve this workflow's efficiency?

A Keep using a new conversation each week for variety, but switch to an even more capable model to reduce the need for the priority-tag follow-up
A more capable model doesn't address the repeated context-rebuilding, and 'variety' from a fresh conversation each week is pure wasted effort, not a benefit — this doesn't target either real inefficiency.
B Set up a reusable Project with the triage rules saved once, add the priority-tag requirement directly into those instructions so it's included automatically, and match model choice to each ticket's actual complexity and stakes rather than always using the most capable model Correct
This removes all three real inefficiencies: repeated manual context-rebuilding (fixed by a persistent Project), a recurring correction sent by hand every week (fixed by folding it into the instructions once), and unnecessary cost from using the most capable model on routine, low-stakes tickets (fixed by right-sizing model choice to each run).
C Ask Claude to summarize the triage rules more concisely each week before pasting them in
Shortening the rules doesn't remove the need to re-paste them every week — the actual inefficiency is re-supplying stable context at all, which a persistent Project setup solves.
D Continue sending the priority-tag reminder each week, since it only takes one extra message
A correction repeated on every single run is exactly the kind of recurring friction this lesson identifies as a signal to fold the fix into the underlying instructions instead of re-sending it indefinitely.

Build exercise: Turn a Recurring Task into a Reusable, Right-Sized Workflow

Intermediate · 30 minutes

You'll practice:

Move stable context for a recurring task into a reusable claude.ai Project
Fold a repeated correction into the underlying instructions instead of resending it
Practice matching model choice to the actual stakes of a routine run

Pick a task you (or a hypothetical team) would run more than once with Claude — a weekly summary, a recurring review, a repeated classification task. In a brand-new, generic conversation (not a Project), run it once with all context typed fresh, and time roughly how long the setup (before the actual task content) took to write.

This establishes the real, felt cost of rebuilding context from scratch, which is easy to underestimate when you only think about the final output quality.

You should see: A completed run, plus a rough sense (even 'about two minutes' or 'about six sentences of setup') of how much of your message was reusable context versus the actual task-specific content.
Hints
1. ```
Separate your message mentally into 'stuff that would be identical next time' and 'stuff that's different every time.'
```
2. ```
If most of your message is reusable context, that's the signal a Project setup would help most.
```
3. ```
Note any correction you'd expect to have to send afterward, even if you don't send it yet.
```
Create a claude.ai Project. Move the reusable context (role, rules, reference material) into the Project's custom instructions and/or knowledge base files, then run the same task in a fresh conversation inside that Project, sending only the task-specific content.

This is the actual efficiency fix: reusable context lives once in the Project, and each run only supplies what genuinely varies.

You should see: A correct, on-standard output produced from a much shorter message, with no re-typed setup.
Hints
1. ```
Put anything that would be identical next time into the Project instructions, not the message.
```
2. ```
If you have real reference material (a style guide, a rubric), add it as a knowledge base file rather than pasting it into every message.
```
3. ```
Confirm the output quality matches or beats your first, fully-manual run.
```
Identify one correction you predicted (or actually needed) to send after the first response, fold it directly into the Project's instructions, and re-run the task from a fresh conversation to confirm the correction is no longer needed. Separately, write one sentence on whether this specific task is routine/high-volume (favoring a faster, lighter model) or high-stakes (favoring the most capable model), and why.

This closes the loop on the two remaining efficiency levers: front-loading a recurring correction, and consciously matching model choice to actual stakes rather than defaulting out of habit.

You should see: A run that no longer needs the follow-up correction, plus a one-sentence, stakes-based justification for a specific model choice for this task.
Hints
1. ```
Word the folded-in correction as a standing instruction, not a one-off note (e.g. 'always include a priority tag' rather than 'remember the priority tag this time').
```
2. ```
If you're unsure about stakes, ask: would a human review this before it goes out, and how costly is a missed error?
```
3. ```
This three-part setup — Project, folded-in corrections, right-sized model — is the reusable pattern for any recurring workflow going forward.
```

Sources

Written fresh — synthesises Project setup, prompt templates, and model selection into a workflow-efficiency lesson
Anthropic docs — Claude Projects
Anthropic docs — Models Overview