Prompt engineering with Claude

Prompt engineering with Claude is more than the wording of a single prompt. It is how you structure the work it does and what happens around it. Each decision below is the same move, match it to what the work needs, taken roughly from the request inward. Some are written up; others are still to come. The broader craft of working with Claude is Working with Claude; the system it all runs inside is Designing the system.

Match the run to the need

The first decision is how a request runs. The synchronous lane is the normal call: you send a request, wait, and get the answer back in seconds at full price. Batch processing is the opposite: you hand over many requests at once, walk away, and collect the results later, for about half the cost, but with no promise of when inside an up-to-a-day window. The deciding question is simply: is anything waiting on this? If yes, take the synchronous call and pay for speed. If no, batch it and take the saving.

If you batch, these are the details worth keeping at hand, the footnotes that shape the design:

• Meeting your own deadline. A batch can take up to its full window, and queued requests also wait for the next submission, so the worst case is the wait for the next batch plus the processing window. If you promise users a turnaround, submit often enough that wait-plus-window still beats your promise.
• Matching answers to questions. Batch results come back in any order, so you attach an id you choose to each request and it is returned on each result. You match by that id, never by position, or you will pair the wrong answer with the wrong question.
• Handling failures. Not every request in a batch succeeds. You resubmit only the failed ones, found by their id, and after fixing the cause rather than blindly resending, for example splitting a request that was too big. You do not redo the whole batch.
• One shot, no back-and-forth. A batch request is a single turn and cannot hand control back to you mid-request and resume, so it cannot run a tool, take your result, and continue. Anything needing that loop has to happen outside the batch. Each request must be self-contained.
• You check on it; it does not call you. You poll the batch to see when it is done and then fetch the results; it does not notify you when it finishes.
• Prove it small first. Test the prompt on a small but representative sample before running the whole batch. A flaw you only find at full scale means paying for and redoing the entire run.

The shape of this decision is durable; the exact figures, the discount, the maximum window and the size limits, are provider specifics that move, so check the current Anthropic Message Batches documentation for today’s numbers rather than trusting one baked into a page.

Match the shape to the need

One call, a workflow where you set out the steps yourself, or an agent left to find its own way. The usual advice is to pick the one that fits, but the shape is not really the choice. Every job is a run of forks. Each one is settled either by you in advance or by the system at runtime. Keep them all and you have written a single call; keep only the tools and the boundary around them and you have written an agent. Nobody picks agent, they just hand over enough forks that agent is what it becomes. Which forks to keep is How much to let AI decide.

Match the orchestration to the need

One Claude agent, or a coordinator handing parts to subagents that work in parallel, and how context passes between them without losing the thread. To come.

Match the connections to the need

The tools Claude can reach, and MCP as the standard way to plug it into your files and other systems, so it is acting on real information rather than working blind. To come.

Match the inputs to the need

Every tool you connect answers in its own dialect: a date as a number here, the same date as text there, success as a code from one and as the word ok from its neighbour. Handed that raw, Claude spends its reasoning converting rather than thinking, on every result, forever. Converting a date format is not a judgement call, so it belongs in code. That is the clearest worked example of a bigger decision, and it lives on When to use AI and when not to.

Match the guarantees to the need

Telling Claude to do something is a request, not a guarantee. It will usually follow a clear instruction, but usually is not always, and for the steps that move money or go out to a customer that gap is the whole problem. The way to close it is not a firmer sentence, it is a check in the code around Claude. Which steps earn one, and how to gate on what actually happened rather than what the model says happened, is Guaranteeing the steps that matter.

Match the safeguards to the need

Failures are not rare events in a system built from separate parts; they are a normal part of how it runs. Hiding one lets a wrong answer through, and crashing on one throws away everything the other parts got right. The path between them, and why an empty result is not the same fact as a failed lookup, is When a step goes wrong.

Match the response to the failure

Saying a step failed tells you nothing about what to do next. A passing blip, a malformed request, a firm no and something off-limits want four opposite responses, and a system that treats them alike will hammer a wall it can never get through. Naming the kind is what picks the move, and that is What kind of failure is it.

Match the human checks to the need

Some work can run on its own and some needs a person before it counts. Checking everything wastes the little review time you have; checking nothing is how the expensive mistakes get out. Where to spend the attention, and why one overall accuracy score hides the slice that is quietly failing, is Where a person should look.

Match the sources to the need

When an answer is gathered from many places, the source behind each claim tends to fall away as findings are tidied into one confident summary. After that a checked figure and an offhand guess read exactly alike. Keeping the source attached, and what to do when two credible ones disagree, is Keeping the source on every claim.

Part of Working with Claude. The system side is Designing the system.