Anthropic publishes a Cookbook of working patterns for building with Claude: runnable notebooks covering chat, agentic workflows, retrieval, and tool use. Most of it is deliberately generic. Australian B2B SaaS builders translating those patterns into production face an extra layer of decisions the Cookbook does not cover: data residency, AUD cost modelling, AU-specific tool integrations, and the small but real differences in user behaviour between Australian and US markets.
The stakes are not academic. For an Australian B2B SaaS at $5M to $20M ARR, getting the pattern stack right early prevents a $300,000 to $800,000 rebuild 18 months later, which is roughly what it costs a 15-engineer team to unpick a chat feature that grew into an untested agent platform. The Cookbook is a starting point, not a finishing point. Here are the four patterns that matter most for AU B2B SaaS, and what changes in each when you ship them locally.
Pattern 1: Customer-facing chat
The Cookbook's chat pattern works fine as written. The Australian adjustments are mostly cost and deployment shape rather than prompt design:
Route inference through Bedrock's Sydney region for AU customers when data residency matters. Many AU enterprise buyers now write onshore processing into procurement, and the Privacy Act review has only sharpened that instinct.
Apply an AUD-aware cost model rather than the USD baseline in the Cookbook. A chat assistant serving 5,000 customer conversations a month typically lands between $2,500 and $7,000 AUD in monthly inference, depending on context length discipline.
Calibrate response length for AU users, who in our client testing prefer shorter, more direct replies than the US-tuned defaults produce.
Surface a clear human escalation path. Australian customers expect to see the option even when they never use it.
The system prompt structure from the Cookbook applies unchanged. The deployment shape around it is what changes.
Pattern 2: Agentic workflows
The Cookbook's agent patterns quietly assume the operator already has observability and evaluation tooling. Australian SaaS teams often ship the agent first and bolt observability on later, which is the wrong order, and the order is expensive to reverse once customers depend on the agent's behaviour.
The sequence that works for AU teams:
Stand up evals before shipping any agent that calls a destructive tool. Even 50 hand-written cases catch most regressions.
Use a tool gateway with idempotency keys from day one, so a retried agent step cannot double-charge a customer or send a duplicate email.
Log every tool call to a central store with PII redaction applied at write time, not query time. APP 11 obligations under the Privacy Act are much easier to meet when the raw store is already clean.
Run a daily replay of 100 production interactions to catch behaviour drift before customers report it.
The Cookbook covers the agent loop well. AU SaaS teams need to add the operational discipline around it, and budget for it: allow $40,000 to $90,000 AUD of engineering time for the eval and observability layer on a first production agent.
Pattern 3: RAG over customer data
The Cookbook's retrieval patterns work but assume English-only content. Australian SaaS products serving multicultural services, education, and government customers regularly hold meaningful volumes of non-English content, and the standard pipeline degrades quietly on it. The extensions that matter:
Multilingual chunking that respects sentence boundaries in non-English text rather than splitting on character counts.
Locale-aware embedding selection so similar concepts in different languages land near each other in the index.
Citation rendering that handles non-Latin scripts cleanly in the UI, which is where most teams discover the problem for the first time.
The retrieval pipeline shape from the Cookbook is fine. The text processing layer either side of it needs local work.
Pattern 4: Tool use composition
The Cookbook covers single-tool patterns well. Production AU B2B SaaS almost always needs tool composition: a customer record lookup feeds a billing lookup, which feeds support history, which informs an action. The composition layer is where most teams improvise, and improvisation here is what they later regret.
The durable pattern is a typed tool registry where every tool declares its inputs, outputs, side effects, and idempotency behaviour. The agent sees the registry, not raw functions. Adding a tool becomes a registry entry, swapping an implementation touches nothing downstream, and auditing what the agent can do reduces to reading one file. For a team of eight engineers in Sydney or Melbourne, the registry approach typically costs one sprint to set up and pays for itself the first time a billing tool needs to be swapped without retesting the whole agent.
What to skip
Some Cookbook patterns target use cases that rarely apply to Australian B2B SaaS: high-throughput batch processing built for ad-tech volumes, generic content moderation pipelines, and B2C consumer agents. Skipping them is not a gap in your build. Focus the first two quarters on customer-facing chat, one production agent with real observability, and RAG over your own customer data. That sequence covers the majority of the product surface AU buyers actually evaluate.
Where to start
Read the Cookbook, then translate rather than transplant. The patterns are sound; the assumptions about residency, cost, language, and tooling maturity are American. An Australian B2B SaaS that adapts those four patterns deliberately ships faster and avoids the mid-six-figure rework that follows an unexamined copy-paste.
If you are sizing a Claude build for an Australian B2B SaaS, book a pattern audit and we will map the Cookbook patterns onto your product in a working session.
