Anthropic's Claude models are hosted over an API like OpenAI's. We choose them when documents are long enough that context size decides the design, or when the assistant is better off declining to answer than guessing.
What is Anthropic?
Claude is a family of language models with an unusually large context window — meaning it can take a great deal of text in one request. In practice that changes the architecture: instead of chunking a hundred-page contract into fragments and retrieving pieces, you can often put the whole document in and ask about it directly.
Fewer moving parts means fewer places for the pipeline to lose the thread, and answers that reason across the whole document rather than across whichever three paragraphs the retriever happened to surface.
When we choose Anthropic
When the unit of work is a long document — a contract, a tender, a policy manual — and the question spans it rather than sitting in one paragraph. Large context is a genuine architectural simplification there.
When being wrong is expensive. Claude is comparatively willing to say it does not know, and for a system a compliance team has to sign off on, that behaviour is worth more than a slightly better score on a benchmark.
And when the assistant has to explain its reasoning to a person who will be held responsible for acting on it. An answer that shows which clause it relied on is one a manager can sign off; an answer that is simply confident is not.
When we do not use Anthropic
When the task is transcription or image generation — different providers lead there, and we pick per task rather than standardising on one vendor for tidiness.
When data residency rules out a hosted API entirely, which is the same constraint as with any provider.
What we build with Anthropic
Contract and tender review
Reading a long document and answering questions across all of it — obligations, deadlines, unusual clauses — with the relevant passage quoted. Long context means the answer considers the whole agreement rather than fragments of it.
Policy assistants for staff
Internal HR, finance and operations questions answered from the actual handbook, with a citation and a clear "not covered in the documents" when that is the truth.
Tender and RFP response support
Reading a long tender document and producing a structured summary of requirements, deadlines and compliance obligations, with each point linked back to where it appears. Days of reading turned into an afternoon of checking.
Bilingual document comparison
Checking an Arabic contract against its English counterpart for differences that matter. Large context means both versions fit in one request, so the comparison is across the whole document rather than paragraph by paragraph.
How we ship Anthropic projects
The same discipline as any model integration: a spend cap, an evaluation set the client grades, caching, and a fallback path.
Provider choice is kept a configuration decision rather than baked in, so moving between Claude and another model is a change of setting and a re-run of the evals rather than a rebuild.
With every answer required to cite the passage it came from. An assistant that cannot show its source is one no manager will let their team rely on, and citation is what turns a demo into something a business can actually deploy.
What Anthropic costs you
Long context is not free — sending a hundred pages costs more per request than sending three paragraphs, and at volume that arithmetic can favour retrieval even when large context is simpler to build.
Third-party dependency applies equally here: availability, pricing and behaviour are outside your control, which is what the evaluation set exists to detect.
Cost scales with how much you send, and long context sends a lot. A hundred-page document in every request adds up quickly at volume, so we compare it against retrieval on your real usage pattern rather than assuming the simpler architecture is also the cheaper one.
Latency follows the same curve — a large request takes longer to process, which shapes how the interface has to behave while waiting.
Anthropic questions we get asked
We test both against your actual documents and your evaluation set, then pick. The honest position is that they trade places regularly and the answer depends on your content — which is exactly why we build the eval harness before choosing rather than after.
Yes, and mixed Arabic and English within one document, which is the common case in contracts here. We test against your actual documents during discovery rather than a sample, because scan quality affects the result more than language does.
That is a policy question before it is a technical one. API data is excluded from training by default, but the documents still leave your infrastructure. We put the current terms in writing during discovery so your compliance team decides with the facts.
By scoping it to the approved document set and building an explicit handoff for anything outside it. The assistant says it does not know and routes the question to a person. That boundary is the part compliance teams actually review, so we design it first rather than last.
Hundreds of pages in a single request, which is what makes the architecture simpler than chunk-and-retrieve for contract and policy work. The practical ceiling is cost rather than capability — at volume, sending the whole document every time gets expensive, and that is when retrieval becomes the better design.
Yes, though quality depends heavily on the scan. A clean PDF is straightforward; a photograph of a stamped page taken at an angle needs a preprocessing step first. We test against a sample of your worst documents rather than your best ones during discovery, because the worst are what determine the real timeline.