Designing AI Solutions with Claude, Part 2: What Claude Should Own and How It Should Run

1. Introduction

In the first part we looked at how Claude behaves and built a shared vocabulary: three platform layers and seven building blocks. In this part, I'll cover the first two real design decisions: which work Claude should own at all, and in what shape it should take part.

2. Decomposition

This is the step that comes before architecture, and it's the one most often skipped.

Claude, systems or people?

Every part of a solution falls into one of three buckets:

• What Claude does - work that benefits from understanding natural language, summarizing, planning, drafting, or acting through tools.
• What existing systems do - everything the partner already paid for to be reliable: the order status service, the policy engine, the rules table, the database that is the system of record.
• What people do - judgment calls, exception paths, approvals, and moments where being right matters more than being fast.

The most common and most expensive early mistake is putting too much into the first bucket. Over-assigning work to the model almost always makes the process more expensive, slower and harder to debug.

For each piece of work, don't just ask whether Claude can do it. Ask whether Claude should own it, and justify the answer with three questions:

• Reversibility - can a wrong decision be undone?
• Stakes - how much does a wrong decision cost?
• Accountability - who has to answer for it?

Example: a claims triage assistant

A partner asks for "an assistant that reads a claim, sets its priority, checks the policy coverage and emails the adjuster". The first instinct is to give all four steps to Claude. Looking through the four properties tells a different story:

• "Read the claim" - this is Claude's sweet spot. Reading and interpreting text is pattern-rich language work, and with a constrained output schema, both next-token prediction and steerability work in your favor. Claude does this.
• "Set the priority" - looks like a language task, but it isn't. Priority is a deterministic rule the partner already defines and maintains in a rules engine. Claude calls the rules engine, and the existing system does the work.
• "Check the policy coverage" - same problem, higher stakes. Policies change and coverage tables get updated, and the model has no reliable way to know when what it learned became outdated. The answer must come from the system holding current coverage data, via tool use or an MCP server.
• "Email the adjuster" - this one needs splitting. Writing the message is language work, so Claude drafts it. Sending it belongs to the email system. And a person should review and approve anything above a certain value threshold.

So the question to ask is "where do the four properties favor Claude over a system that already does this correctly?", rather than "where can Claude help?".

Watch out: the rule that quietly drifted

A typical scoping conversation goes like this:

Partner: "We have a rule that every claim above £5,000 needs a senior adjuster. Today we check it with a SQL query against the claims table. Could Claude handle that instead?"

Architect: "Sure, we can prompt Claude to extract the amount and route the claim if it's over 5k. That keeps everything in one step, which is much simpler."

Partner: "Perfect, works for me."

Three months later, out of 14,000 processed claims, 41 were routed incorrectly. All 41 had the same problem: the amount wasn't written as a clean number. It was hidden in a sentence like "damages valued at about five thousand pounds". The model treated "about five thousand" as a loose estimate, not as a value that should trigger senior review. The rule was precise. The data it worked on wasn't, and the model followed the letter of the rule instead of its intent.

What went wrong:

• A rule that must be right every time was handed to a system that is right most of the time. The gap between those two is where the 41 claims lived.
• Nobody built test cases for the routing, because routing was treated as "something the model will just handle" rather than a business rule that needs testing, monitoring and a human owner.
• The audit found the problem, not the system's own monitoring. Logging that would catch a broken SQL check doesn't record the choices a model makes inside a single request.

The trap is easy to fall into because the model handles the clean cases correctly - and the clean cases are exactly what you see in demos and early tests.

3. Pattern selection

Once you know which parts Claude owns, the next question is structural: in what form does Claude take part?

Augmented LLM, workflow or agent

There are three patterns. Each sits at a different point on two axes: how predictable the path through the work is, and how much autonomy you're willing to give the model.

• Augmented LLM - a single model call. You send a request, the model does one bounded task in one pass, and your code handles the integration around it. You can add tool use, retrieval or extended thinking, but control flow never branches based on what the model decides. Use it when the task is well defined, the result is verifiable, and there's no reason to split the work into steps.
• Workflow - you break the task into named steps and orchestrate them in your own code. Each step may or may not call Claude. Because control flow lives in your code, you can log it, test it and reason about it like any other software. Use it when errors are costly, observability matters, and the steps can be defined up front.
• Agent - you give Claude a goal and a set of tools, and the model decides the sequence of steps itself. Control flow lives inside the model. Use it only when the path through the work can't be enumerated in advance, and only when an unexpected or inconsistent result is acceptable and fixable.

Claude Code is a good production example of an agent: it explores unfamiliar code, decides which files to read based on what it has already found, and does multi-step engineering work no one could have planned in advance. The downside is that this is also where non-deterministic failures concentrate, because the model's trajectory is the control flow and there's no code boundary to put a safeguard on.

Note: In production, agents are usually constrained by narrow tool access, per-turn budgets, explicit permissions and stop criteria. These constraints aren't optional - they're what keeps an agent from becoming a source of risk.

Four workflow sub-patterns

Choosing "workflow" doesn't finish the design. A workflow can take one of four shapes:

These aren't mutually exclusive. Most production workflows combine more than one. Pick the simplest one that meets the task's needs for error tolerance and observability, and escalate only when measurements show the simpler pattern isn't enough.

Five factors that decide

Go through these five factors in order. For each one, ask whether it rules out any of the three patterns. The first factor that rules a pattern out is the deciding one.

One caveat: agents don't automatically cost more than workflows. Cost is driven by how much context accumulates and how many model calls you make. A badly designed workflow can cost more than a well designed agent, so the design matters more than the label.

Try prompting before fine-tuning

When prompting feels unreliable, many engineers reach for fine-tuning. With Claude, that's usually the wrong first move. Go through this sequence instead:

1. 1.
   Optimize the prompt. Most reliability problems are prompt problems.
2. 2.
   Add tool use or retrieval if the prompt alone isn't enough.
3. 3.
   Move to a stronger pattern, like evaluator-optimizer, if quality still isn't there.
4. 4.
   Only then consider fine-tuning.

Fine-tuning makes sense when the task runs at very high volume and inference cost is a real constraint, when latency is critical and a smaller specialized model would win, or when output must follow a consistent format that prompting couldn't reliably fix. Outside those cases, it ties you to a fixed model version without much benefit.

Note: Fine-tuning for Claude isn't generally available. Access is limited, varies by model and delivery route, and changes as Anthropic expands the program. Confirm the current options with Anthropic before recommending this path.

Watch out: wanting flexibility, getting non-determinism

Teams often pick an agent because the task feels open-ended, not because it actually is. The course illustrates this with three quotes from one team's 90-day retrospective:

"We picked an agent because we didn't want to constrain it too early. By month two we'd added so many guardrail tools that we'd basically rewritten a workflow inside the agent loop - just without the logging."

"Compliance came and asked which step approved the payout. We pointed at a model turn. They asked which model version. We checked the trace. The version had moved to a newer one two weeks earlier and nobody had re-validated."

"When we analyzed the traces, the real paths through the system fit into just four shapes. Four. We could have written it as a router and four chains and saved ourselves six months."

Each quote names a different failure:

• They optimized for unknown future flexibility instead of the known current shape. All four paths were knowable from week one.
• Non-determinism became a compliance problem. When an auditor needs a deterministic answer, an agent can only offer a trajectory.
• An unpinned model version made it worse. This one is a model governance gap, and it would hurt any pattern - a workflow shipped the same way would inherit the same problem.

Agents aren't something to avoid. They should just fit the purpose. If the steps really can't be known up front, an agent is the right choice for exactly that reason. If they can, you're paying for flexibility you'll never use.

4. Summary

Key takeaways

• Split every request into what Claude does, what existing systems do and what people do - before you pick any pattern
• A rule that must be right every time doesn't belong in a system that is right most of the time
• Augmented LLM, workflow and agent differ in how much autonomy you hand over; the first factor that rules a pattern out decides
• Pick an agent only when the steps really can't be known up front - otherwise you pay for flexibility you'll never use
• Optimize the prompt, add tools or retrieval, try a stronger pattern - and only then consider fine-tuning

What's next

With the work split and the pattern chosen, the next question is how that structure connects to everything around it. In the next part, I'll cover multi-agent systems, five proven reference architectures and RAG pipeline design.