Anthropic Claude Development & AI Integration

What we build on Claude

Most Claude work falls into three shapes. Each one needs different engineering around the model, and the model is usually the smallest part of the build.

• →Document analysis: extracting terms, obligations and exceptions from contracts, policies and filings, with the source passage attached to every field
• →Retrieval over your own content: answers drawn from your documents, with a link back to where each answer came from
• →Tool-using agents: an assistant that reads a request, calls your systems through defined tools, and asks a reviewer before it does anything that cannot be undone

Designing with Claude's features, not around them

Claude's API has a few levers that change cost and reliability more than any prompt wording does, and which ones a build uses depends on its scope. Strict tool use constrains a tool call to the schema we define, which guarantees the call is well formed; it does not make the values in it correct, so the values still need checking in code before anything runs.

• →Prompt caching for large context that repeats across requests, such as a policy manual or a product catalog, so it is not paid for in full on every call
• →Long context or retrieval: we test whether a document set fits in one request or needs to be retrieved in pieces, and choose on accuracy and cost, not habit
• →Tool definitions with strict input schemas, plus a validation step in our code for the values themselves
• →Citations, so reviewers can check an answer against its source instead of trusting the summary

When we choose Claude, and when we do not

We pick a model per task, not per company. Claude is a strong candidate for long-document reasoning and careful instruction following; a high-volume, templated task may be cheaper on a smaller model from any provider, which is why our workflow automation practice builds AI steps on either the OpenAI or the Claude API. Some decisions do not need a large language model at all: our CTO's Jevfish write-up shows a bounded choice handed to a fast decision model while ordinary code enforces the rules. Where the scope allows, keeping the model behind one interface in your code makes changing it later a configuration change and a rerun of the evaluation, not a rewrite.

Evaluation before launch, and the model's retirement date

A model that is fluent and wrong is the main risk in any Claude build. Before launch we assemble a test set from your real documents and requests, write down what a correct answer looks like for each, and score the system against it. The same set runs again whenever a prompt, a tool or the model changes. That last case matters because Anthropic retires older models on a published schedule, and requests to a retired model fail. When an engagement needs a pinned model version for stability, that stability lasts only until the version's retirement date, so the upgrade is planned and re-scored like any other change.

• →A fixed test set drawn from your own material, with expected answers agreed with your team
• →Where the engagement calls for it, a pinned model version, with its retirement date tracked and the upgrade re-scored before release
• →Answers that fail schema validation, cite no supporting passage, or contradict your system of record go to a reviewer instead of shipping

Agents that act in real systems

An agent that can send a message or update a record needs the same controls as a new employee with system access. The agent should reach only the tools its job needs, a person should approve anything that moves money or cannot be undone, and every action should leave a record someone can audit. These are the controls we design in.

• →Allowlists for who can reach the agent and which tools it may call
• →Human approval on actions that move money, send external messages or delete data
• →A log of every tool call, with its inputs and result