Designing AI Solutions with Claude, Part 1: How Claude Behaves and Why It Matters

• 1. Introduction
• 2. Decisions nobody made
• 3. How Claude behaves
  • The four properties
  • When the context window runs out
  • What they mean for your design
• 4. A shared vocabulary
  • Three layers of the platform
  • Seven building blocks
• 5. Summary
  • Key takeaways
  • What's next

1. Introduction

In this series, I'll walk you through how I think about designing solutions with Claude - not writing the code, but making the decisions that come before the code. I'll keep it in plain language and focus on the things that have proven most useful to me in practice.

Let's face it: picking a model is the easy part. The hard part is everything around it. Before you build anything with Claude, you have to answer four questions:

1. Which part of the work should Claude own? What goes to Claude, what stays with your existing systems, and what stays with people?
2. What shape does the work have? Is it a single enhanced call, an automated workflow, or an agent working on its own?
3. Which reference architecture are you following? Naming a proven blueprint up front can save you from expensive U-turns later.
4. Where does the work meet Claude? The right entry point, model and context strategy keep the solution working and affordable.

This series goes through these decisions one by one, a few at a time.

The approach I'm going to describe isn't a recipe you can copy and paste. Every project is different, and every choice here is a trade-off between cost, complexity and risk. My goal is to give you a set of questions and patterns, so that you can make a decision and defend it when someone puts a reasonable alternative on the table.

Note: Anthropic's products change quickly. Model names, features and availability mentioned here reflect the state of the platform at the time of writing. Always double-check the current Anthropic documentation before you commit to anything.

2. Decisions nobody made

One of the most frustrating things I've seen is a design that looked perfect in the demo and fell apart three months later. The demo ran flawlessly five times in a row, so everybody assumed the system was reliable. Then the bill arrived, or the audit, or an angry customer.

The pattern is almost always the same. Someone said "let's just use Claude for that", "let's use an agent, so we don't limit it too early", or "let's use the best model available, just to be safe". Each of these sounds reasonable in a meeting. Each of them is a decision that was never really made - and a decision you don't make is still a decision. Usually it's the most expensive one.

If you design without understanding how the model behaves, you pay for it after launch, when rework is most expensive and trust is hardest to rebuild.

What makes it worse is that these problems don't announce themselves. A system that ignores the model's properties won't throw an error. It quietly drifts, and the gap shows up as inconsistent results caught by an auditor or an unhappy user - not by the system itself.

Most of these failures are predictable, though. If you know where to look, you can spot them on the whiteboard instead of in production.

3. How Claude behaves

Before deciding what Claude should do in your solution, you need a clear picture of how it behaves. None of the properties below is a bug to fix. Each one is a strength you design around - the same way a structural engineer designs around the properties of steel or concrete.

The four properties

When the context window runs out

The working memory edge can fail in two different ways, and they are easy to confuse:

• The request is too big to send. It gets rejected before generation even starts. If the prompt exceeds the model's token limit, the API returns 400 invalid_request_error. If the raw request body exceeds the byte limit, you get 413 request_too_large.
• The window fills up during generation. The prompt fits, but the output hits the ceiling and stops early. On current models the response comes back with the stop reason model_context_window_exceeded and truncated output.

To stay away from the edge, check the usage field in every response and use the token counting API before you hit send.

What they mean for your design

Each property maps directly to a design consequence:

• Non-determinism - the same input can produce different outputs across runs. That's why evals exist: you can't certify behavior you've only seen once.
• Context is a finite resource - what you put in the window, in what order, and what you leave out are design decisions that affect both quality and cost.
• Confidence is not correctness - Claude can give a wrong answer in the same fluent, confident tone as a right one. That's why human-in-the-loop and verification are architectural choices, not something you bolt on at the end.
• Knowledge has boundaries - for unreliable topics, use search, retrieval, tools and MCP, so that an external system is the source of truth.

A story I keep coming back to: an architect watched a demo run perfectly five times in a row and concluded the behavior was deterministic. The team shipped a financial reconciliation pipeline that treated every model output as a fixed, repeatable result, with no checks around it. In week two, outputs started drifting - the same statement, processed again, got a different categorization. Nobody noticed until an analyst happened to re-run a batch.

The lesson isn't "the model is unreliable". The lesson is that a demo is not proof of determinism, and these four properties are there whether your architecture acknowledges them or not.

4. A shared vocabulary

Before choosing anything, you need words that everyone in the room understands the same way. I've been in a review where someone said "we'll use an agent" and five people heard five different things: a single model with tools, a multi-step workflow, a team of subagents, Claude Code, and a chatbot. The discussion stalled for twenty minutes before anyone noticed.

Three layers of the platform

These three terms are often used as if they meant the same thing, but they belong to different layers of the architecture. Every deployment includes all three.

• Entry points - what a person or system interacts with directly. An entry point is a wrapper that decides who can talk to Claude and how. Examples: Claude.ai (web, mobile, desktop), Claude Code, your own app built on the API.
• Build-time interfaces - how an engineer programs against Claude. Examples: the direct API, the SDKs, MCP, the Agent SDK.
• Delivery routes - where API traffic actually ends up, meaning whose infrastructure runs the request. Examples: Anthropic directly, AWS Bedrock, GCP Vertex AI, Microsoft Foundry.

You pick the entry point for the user and the job. You pick the build-time interface for the engineering team. You pick the delivery route for the partner's cloud commitments and compliance posture. Three different conversations with three different stakeholders.

Seven building blocks

Every pattern and architecture in this article is a combination of a small set of primitives. Each one has one job:

The key skill is composing these blocks - and using as few of them as the requirement allows. Every primitive you add is something to build, observe and govern. Reaching for a team of agents when a single tool call would do means paying in latency, tokens and operational surface on every single request.

5. Summary

Key takeaways

• Claude has four properties - next-token prediction, knowledge, working memory and steerability - and each one is a strength you design around, not a bug to fix
• A demo is not proof of determinism - the same input can produce different outputs
• Entry points, build-time interfaces and delivery routes are three different layers, chosen by three different stakeholders
• Seven primitives cover almost everything you'll build - use as few of them as the requirement allows

What's next

Knowing how Claude behaves is only the foundation. In the next part, I'll use it to make the first two real design decisions: which work Claude should own, and whether it should run as a single call, a workflow or an agent.

Continue reading: Part 2: Decomposition and pattern selection