CCAO-F 7.3 — Optimizing workflows

Where the time actually goes

Every task from scratch

Re-explaining the same background each time
Requirements dribbled out over many messages
One enormous conversation running for weeks
Every output checked to the same depth

Set up once, then run

Standing context lives in the project
One complete brief, related questions batched
A fresh chat per task, with a clean brief
Checking depth matched to what is at stake

Four habits, four fixes. None requires a new tool — they are all rearrangements of work you are already doing.

Front-load the standing context

If you do the same kind of work repeatedly, the background belongs somewhere it does not have to be retyped. Anthropic’s own guidance is to upload your core working documents to the project knowledge section when starting a project, because documents uploaded to a project are cached for future use, and cached portions count less against your limits than new content. That is the efficiency argument. The quality argument is stronger: context you set up deliberately once is better than context you improvise under time pressure fifteen times.

Two maintenance details come with it. Caches expire after a period of inactivity, so an occasional project will not always be working from a warm cache. And project instructions should be kept concise, with unused files removed — a project that has accumulated eleven documents, four of them superseded, costs more and answers worse. Setting a project up is 5.1; keeping it current is 5.4. What belongs here is the recognition that this is an efficiency decision as well as a configuration one.

Worked example · A bid team that re-uploaded the same five documents

A four-person bid team at an engineering consultancy answers eight to ten tenders a month. Each tender starts with someone uploading the capability statement, the quality-policy extract, two case studies and the current rate card, then re-explaining the house style.

Count the repetition. Five documents and a paragraph of context, ten times a month, across four people. Nothing about it varies.
Move it once. The five documents go into a bid project’s knowledge, with instructions covering house style, the three things every answer must contain and the two claims nobody may make without sign-off.
Keep the chats small. Each tender gets its own conversation inside the project, carrying only the tender documents and that tender’s questions.
Prune quarterly. The rate card and case studies are replaced rather than added to, so the project never accumulates two versions of the same fact.
What changed. The repeated upload disappeared, answers became consistent between the four writers, and the standing documents are now cached rather than re-sent as new content each time.

Takeaway: The saving was real but secondary. The bigger win was that four people stopped each improvising the house style from memory.

Fewer, fuller messages

The second habit is drip-feeding. A request goes out half-formed, the answer is nearly right, a correction follows, then another, then a change of format. Each of those round trips re-sends the whole conversation so far. The documented advice is the opposite pattern: give clear, detailed instructions or questions in each message, batch similar requests together, combine related questions into one message, and take a moment to review your message for clarity and completeness so that fewer follow-ups are needed. For editing work, send the entire text in one message rather than in pieces.

There is a related discipline inside a conversation: refer back to previous information instead of repeating it. Pasting the same brief again three messages later does not remind Claude of anything it already has, and on paid plans you can search previous conversations and reference them from a new chat rather than reconstructing them.

Drip-fed versus briefed

Six round tripstext

1. "Write a project
update."
2. "Make it shorter."
3. "Add the budget
position."
4. "It's for the
steering group, not
the team."
5. "Can you use our
RAG statuses?"
6. "Actually put risks
at the end."

One brieftext

Write a project update
for the steering group.

250 words. Order:
progress, budget
position, decisions
needed, risks last.

Use our RAG statuses
(red/amber/green) for
each workstream.

Attached: this month's
tracker and last
month's update.

The right-hand version is one message instead of six, and it is also a better brief — the constraints were always in the writer’s head, just never written down.

Knowing when to start again

The third habit is the conversation that never ends. The context window is described in the documentation as Claude’s working memory — how much content it can process and remember at once — and it varies by model: newer models support up to a million tokens, while others offer five hundred thousand or two hundred thousand. Long conversations run into it, and there are two consequences. Quality drifts, because an enormous thread contains every wrong turn as well as every good one. And conversations that trigger automatic context management, where earlier messages are summarised, consume more of your usage limit, because that summarising is additional work.

The remedy is the one the documentation gives: start a new conversation, or use features such as projects to work with larger amounts of information more efficiently. A useful rule of thumb is one conversation per deliverable. When the thing you are making changes — a different document, a different decision — open a new chat and bring across a short clean summary rather than a week of history. Managing context and knowing when to restart or summarise is 3.4; the point here is that it is an efficiency lever, not only a quality one.

Lever	What it does	Cost of getting it wrong
Project knowledge	Standing documents cached and reused	A bloated project with stale files
One complete brief	Removes the correction round trips	A long brief for a one-line question
Fresh chat per deliverable	Avoids drift and context management overhead	Losing context you actually needed
Turn off unused features	Less work per message	Turning off thinking on a task that needed it
Draft, review, refine	Better output through a deliberate extra pass	Spending three passes on a routine email

Efficiency is not the same as effectiveness

The objective names both, and they can pull in opposite directions. The cheapest possible workflow is one message, no attachments, no checking — and for a routine internal note that may be exactly right. For anything consequential, the better workflow deliberately costs more. The documented chaining pattern is to generate a draft, have it reviewed against explicit criteria, then have it refined on the basis of that review: three passes where one would have done, because inspecting the intermediate output is the point.

So optimisation means matching the depth of the workflow to what is at stake, not minimising everything. An internal summary nobody will act on needs one pass. A tender response worth two million, a letter to a regulator, a figure that will appear in a board pack — those earn the extra passes and the verification, and which outputs cross that line is covered in 2.4. A workflow that treats both the same is unoptimised in one direction or the other.

A workflow audit

Passes: Standing documents live in a project, not re-uploaded each timeFive bid documents moved once
Check: The brief is complete before the first message is sentFormat still settled by correction
Fails: Related questions are batched rather than sent one by oneNine messages where two would do
Fails: One conversation per deliverableA single thread running since March
Missing: Unused tools, search and thinking switched off for routine workNever reviewed since setup
Passes: Checking depth matches what is at stakeTender answers verified; internal notes not

Run this over a task you do weekly. The failures below are the usual ones, and each has a fix that takes under an hour.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Re-uploading the same background documents for every task	Put standing documents in a project, where they are cached and reused.
Drip-feeding requirements across many short messages	Write one complete brief and batch related questions together.
Running one conversation for weeks across many deliverables	Start a fresh chat per deliverable, carrying a short clean summary.
Re-pasting context the conversation already contains	Refer back to it, or search previous conversations from a new chat.
Optimising every workflow for the lowest possible cost	Match the number of passes and the checking depth to what is at stake.
Letting a project accumulate superseded files	Replace rather than add, and remove files that are no longer used.

You should now be able to

Identify the constant part of a repeating task and move it into shared setup.
Write one complete brief instead of a sequence of corrections.
Explain why very long conversations cost more and drift, and when to start fresh.
Name the product levers that reduce work per message, and their trade-offs.
Decide which outputs justify a draft-review-refine pass and which do not.

Optimizing workflows