Aim automation at your constraint: the step that sets the pace of everything behind it. Often that is exactly the busywork eating your day; checking first just confirms it, because an hour saved anywhere else quietly evaporates. The people who build these systems for a living (Anthropic’s own engineers, whose public talks and interviews this guide distills) work in that order: locate the constraint, solve it once by hand, then encode the solution so it never needs solving again. Everything else in this guide hangs off that ordering.
The logic comes from operations theory, and the classic picture is a scout troop on a trail. The line stretches because the fast hikers speed ahead, but the troop arrives when the slowest hiker arrives, so the leader moves the slowest walker to the front and redistributes the weight in his pack. The troop speeds up precisely because the fastest hikers slowed down. Your workflows obey the same arithmetic: 60 minutes saved anywhere except the constraint is 60 minutes that queues up behind it, indistinguishable from time not saved at all.
“Find the bottleneck, solve the bottleneck.”
Boris Cherny, creator of Claude Code, “How Anthropic Engineers ACTUALLY Automate Their Work” · 0:2601Interrogate before you build
Most people cannot name their actual bottleneck, which is why the first tool is an interrogation, not a build. Ask why the work is slow; then ask why of the answer, 5 times over. Fifty new sales leads are worthless if onboarding is manual. The leads were never the constraint. Only when the constraint has a name do you choose an instrument for it, and the instrument should be the smallest one that works: a skill for a repeatable procedure, a scheduled routine for a recurring check, an artifact for something you need to see, an external tool when the work lives outside the model. One problem, one deliberate pairing, not one hammer for everything. When the instrument is a skill, Expertise you can install covers where reliable ones come from.
02The machine that reports to you
If the interrogation reveals that you are the bottleneck (you dispatch every task, you chase every status), the fix is structural. A back-and-forth, top-down loop (you ask, it answers) caps the system at the speed of your attention. The working alternative is bottom-up: Claude initiates, and you review what arrives. Every proactive system, human or machine, has the same four parts, and naming them for your own workflow is most of the design work:
- Trigger: how often it runs. Time-based (“Monday, 8 a.m.”) or event-based, which in practice means a frequent, cheap check that decides whether the expensive work should run at all.
- Worker: whatever does the job. Build the minimum viable version; solve today’s problem, not a theoretical future one.
- Access: the accounts and tools the worker may touch. The test is the same as for a new hire: does it have the logins the task actually requires?
- Receipt: the proof of completion, and the part most people get wrong. A receipt must spell out the outcome: “141 emails reviewed, 12 minutes of runtime” carries verifiable numbers; “emails reviewed” hides every possible failure behind three words.
Anthropic runs this shape on real work: one internal system hands Claude the entire growth- experiment loop on a schedule, with the analyzed results returning to the team as the receipt. The pattern scales down just as well: one trigger, one worker, one explicit receipt, delivered wherever you already look every day.
03The trace holds the story
A receipt is the total at the bottom of a dinner bill. The trace is the line items: the full transcript of what the system actually did, step by step. Unwatched automations drift. Asked for the secret at an engineering workshop, Anthropic’s applied-AI answer was surprisingly manual:
“By far and away the best approach … is just reading the traces by hand.”
Ash, Applied AI at Anthropic, “How Anthropic Engineers ACTUALLY Automate Their Work” · 8:43Reading traces (the step-by-step record of what the agent actually did) is a three-step discipline, and 10 minutes of it a week catches drift long before a broken receipt would. First, make sure the logs exist: scheduled runs usually keep their conversation history, and anything you run elsewhere should write a run log to a known location, ideally through one shared logging skill so the format can be changed in one place. Second, actually look at them, in whatever viewer makes that effortless. Third, the step that compounds, act on what you find: bring the trace back to Claude, point at the exact wrong turn, and have it fix the skill itself. That converts a one-time failure into a permanent repair, because the fix lands in the system rather than in the conversation. Every new repo starts with your lessons covers that habit.
04Hand over the objective
Tasks are instructions: send this report, reply to these emails. Objectives are outcomes: make this true, figure this out. The difference is easiest to see side by side:
| Task | Objective | |
|---|---|---|
| You hand over | An instruction (“send the report”) | An outcome (“make this true”) |
| Claude decides | Almost nothing | The route, the tools, the order |
| You must supply | The steps | Done-criteria plus an evaluator |
| Failure looks like | A wrong step | A receipt without proof |
The strongest colleagues you have ever worked with took objectives, and Claude can too, but only inside the right support structure. The cautionary tale is a retro game built two ways by Anthropic engineers: the same objective, prompted conversationally, shipped something that looked finished until the first arrow-key press did nothing. Restructured (the objective plus support structure, then a closed laptop), it came back 6 hours later fully playable. Same model, same goal; only the structure changed. Keeping a run that long honest is its own discipline, the subject of Guardrails for hours-long agent runs.
That structure has three parts. Agree on what done looks like before any work starts, at uncomfortable granularity: the engineers behind that experiment settled on twenty-seven contract criteria, because vague criteria produce a shrug while granular ones point at the exact line to fix. Add an evaluator that is not the worker, with real access to run the product, because a model grades its own work the way an employee writes their own performance review. And require the final receipt to carry proof: screenshots of the running thing, not a paragraph asserting success.
Further reading
- Austin Marchese · How Anthropic Engineers ACTUALLY Automate Their Work, the source this guide distills
- Wikipedia · theory of constraints, the operations theory behind the hiking-line picture
- Wikipedia · The Goal (Goldratt), where the scout-troop story comes from
- Anthropic · engineering blog, first-party accounts of agent workflows
- Anthropic · Claude Code documentation, the tool the workers in this guide run on