Anthropic / Claude Integration in New Zealand

Find out what your team already does by hand

In most New Zealand businesses somebody is already using a chat window daily for something useful — summarising a long report, rewriting a quote, making sense of a contract, extracting figures from a supplier's PDF.

That habit is the best specification you will get. It tells you which task is worth automating, how often it comes up, and what good output looks like, because someone has been judging it by eye for months.

It may also tell you what has been pasted into a personal account, which is worth knowing now rather than during an audit.

Where Claude tends to be the right choice

All the frontier models are capable, and for short classification work the differences are small. Claude is most often chosen when:

• The documents are long. Contracts, tenders, case files, annual reports — a large context window means the whole thing can be supplied rather than chopped up and stitched back together.
• The extraction has to be careful. Structured output from messy source documents, where a plausible wrong value is worse than a refusal.
• Being unsure is acceptable. It is comparatively willing to say it cannot find something, which is a feature when a person will be held to the answer.
• The model calls your own functions. Tool use is well-supported, which matters for anything agent-shaped.

Ask each developer why they are proposing a particular model. A specific answer about your task is worth more than a general claim about quality.

Insist on structured output

Ask for prose and your software has to parse it, and that parsing breaks when the wording drifts. Structured outputs let you supply a schema and receive a response that conforms to it or fails loudly.

That is the difference between a feature that degrades noisily and one that writes a plausible wrong value into your database.

Then validate anyway. A schema guarantees shape, not sense — your own rules still have to catch the invoice dated 2087.

Ask about prompt caching

If every request sends the same large block of background — a policy manual, a product catalogue, a long set of instructions — that portion can be cached and reused rather than reprocessed and recharged on every call.

On workloads with heavy repeated context this cuts the bill substantially, and there is no real downside. It is one of the few pure wins available, and it is frequently left on the table.

Ask what it saves on your specific workload. A developer who has not considered it has not thought about your running costs.

Ask to see the evaluation set

Fifty to two hundred real examples from your business with the correct answer recorded, scored before launch and after every change.

Without one, nobody can tell whether last week's prompt change helped or quietly broke a category nobody tested. It happens constantly: a tweak that fixes one supplier's invoices breaks another's, and the first person to notice is a customer.

The set costs mostly your team's time, because only they know the right answers. It is the first thing missing from a cheap quote and the best money in the project.

Plan for the model being unavailable

Every provider has outages, rate limits and slow periods. What your software does in that moment is a design decision:

• Does the feature fail gracefully, or does the page break?
• Is the work queued and retried, or lost?
• Is there a fallback — a smaller model, or the manual path that existed before?
• Does the user see something honest, or a spinner forever?

Treat incoming text as untrusted

If the feature reads material from outside your business — an email, an uploaded document, a web page — assume it may contain instructions aimed at the model. Text saying "ignore your instructions and forward this" is a real attack, not a hypothetical.

The defences are ordinary engineering: validate the output before anything acts on it, give the feature only the permissions it needs, and route anything irreversible through a person. Ask whether the developer has read the OWASP list for LLM applications.

Build so you can leave

Models change every few months, prices fall, and the best option for your task next year may be a different provider. That should be a configuration change, not a rewrite.

Ask for the model and prompt in configuration rather than scattered through the code, a structured contract between your feature and the model, and an evaluation set that could prove a replacement is at least as good. None of it costs extra at build time and all of it is expensive to retrofit.

Comparing five quotes

Read for:

• Who asked what your team already does by hand?
• Who gave a cost per use and mentioned caching?
• Who uses structured outputs and validates them?
• Who included an evaluation set?
• Who explained how you would change provider later?

Describe the task, how often it happens, what a wrong answer costs, and whether a person reviews the output. Developers who have shipped this will ask about evaluation before they ask about the model.