AI integration
AI features built on Anthropic's Claude, with the safeguards production needs
We build assistants, document workflows and search into your product using Claude through Anthropic's API. Every feature ships with an evaluation set, guardrails, cost limits and a clear account of where your data goes.
Who it's for
Clients usually come to us for ai integration in one of these situations.
Your support team answers the same questions daily
Most tickets are covered somewhere in your help center, but customers can't find the answer, and agents spend their day pasting links.
Staff retype data from documents
Invoices, applications or contracts arrive as PDFs and someone keys the fields into your system by hand, with the errors that come with it.
Leadership wants an AI feature, but nobody has defined it
There's pressure to add AI to the product. You need a specific job for it, a way to measure it, and an honest view of where it shouldn't be used.
What we build
We focus on AI features that do a specific job inside an existing product, where success can be measured. We don't sell general-purpose chatbots or promise that a model will replace a team.
- In-product assistants
- An assistant inside your web or mobile app that answers from your help center, product data and policies, cites its sources and hands off to a person when it isn't confident.
- Document extraction
- Pull structured fields from invoices, contracts, forms and reports into your database, with confidence flags and a review queue for anything uncertain.
- Semantic search
- Search that understands what people mean, across tickets, documents and records, using embeddings and retrieval tuned on your own content.
- Support automation
- Draft replies, ticket classification, routing and summaries for your support team, integrated with the help desk you already use. People stay in the loop for sending.
- Workflow agents with tools
- Claude calling your own APIs through defined tools to look up orders, update records or schedule work, with permissions scoped to what each action needs.
- Summaries and reporting
- Turning long threads, call notes and activity logs into short summaries and weekly reports that link back to the source.
How we approach it
Every request moves through the same steps, inside your weekly release cycle.
- 01
Define the job and the metric
We agree on what the feature must do, what a correct answer looks like and how we'll measure it, before choosing prompts or models.
- 02
Build an evaluation set
We collect real examples from your domain, with expected outputs, and run every prompt and model change against them.
- 03
Prototype behind a flag
The first version runs for internal users only, with logging, so you can see real behavior before customers do.
- 04
Roll out with guardrails
We release gradually with input checks, output validation, rate limits and spend alerts in place, then keep tuning from evaluation results.
Typical timeline
Engagement timeline
A typical schedule for one AI feature going from idea to production.
About 10 weeks to a staged rollout
Weeks 1 to 2
Define the job and the metric
What the feature does, what a correct output looks like, and the threshold it must meet to ship.
Weeks 1 to 3
Build the evaluation set
Real examples from your domain with expected outputs, including hard and off-topic cases.
Weeks 3 to 6
Prototype behind a flag
Prompts, retrieval and tools built and scored against the evaluation set on every change.
Weeks 5 to 8
Internal pilot
Staff use the feature with full logging. Disagreements are reviewed and added to the evaluation set.
Weeks 7 to 10
Guardrails and gradual rollout
Input and output checks, cost limits and spend alerts in place, then release to customers in stages.
Typical for one well-defined feature, such as an assistant or an extraction pipeline, on a Scale plan. Access to real example data is the biggest variable.
What you get every week
Releases happen on a fixed day each week. Monday starts with a queue check; Friday ends with these in your inbox and your shared channel.
Evaluation report
How the current version scores on the evaluation set, what changed since last week and which cases still fail.
Usage and cost snapshot
Requests, token usage and spend against the monthly budget you set, by feature and by workspace.
Flagged examples
A short list of real interactions that were low-confidence, rated poorly or handed off, with what we'll do about them.
Release notes
Prompt, model and guardrail changes listed like any other code change, with the evaluation results that justified them.
Quality standards
The targets we hold this work to, and how we check them. These are our commitments for how the work is done, not certifications.
- Evaluation sets
- Our targetEvery feature has a test set of real cases with expected outputs, and a release threshold agreed with you.
- How we checkThe set runs on every prompt or model change; results are attached to the pull request.
- Guardrails
- Our targetInput checks, structured output validation, grounding against retrieved sources and narrowly scoped tool permissions.
- How we checkAdversarial, off-topic and prompt-injection cases are part of the evaluation set.
- Cost limits
- Our targetA monthly budget with per-user and per-workspace limits, and alerts before thresholds are reached.
- How we checkLimits and alerts are tested before launch and visible on a usage dashboard.
- Data handling
- Our targetOnly the fields a feature needs are sent to the model, personal data is redacted where possible, and retention is documented.
- How we checkA data flow document reviewed with your security or privacy team before rollout.
- Human oversight
- Our targetPeople confirm actions with consequences, and low-confidence results route to a person.
- How we checkEnforced in application code and covered by automated tests, not left to the prompt.
- Observability
- Our targetRequests, latency, token usage and user feedback logged with personal data masked.
- How we checkFlagged interactions reviewed weekly and turned into fixes or new evaluation cases.
What we put around the model
A model call is a small part of a production AI feature. Most of our work goes into the parts that make it dependable, private and affordable.
Evaluation
Each feature has a test set drawn from your real cases. We track accuracy, refusal and citation rates over time and run the set before every prompt or model change ships, so regressions are caught in review instead of by customers.
Guardrails
Input filtering, structured output validation, grounding checks against retrieved sources, and tools limited to the narrowest permissions they need. When the model isn't confident, the feature says so or routes to a person.
Data privacy
Under Anthropic's commercial terms, API inputs aren't used to train models. We send only the data a feature needs, redact personal information where possible, and can run Claude through Amazon Bedrock inside your AWS account if your policies require it. Retention and logging settings are documented for your review.
Cost controls
We pick the smallest Claude model that passes the evaluation set, use prompt caching and batch processing where they apply, and set per-user and per-workspace limits. Usage dashboards and spend alerts let you see costs before the invoice arrives.
Observability
Requests, latency, token usage and user feedback are logged with personal data masked, so we can investigate a bad answer and fix the cause.
Human review
For anything with consequences, such as sending an email, changing a record or approving a payment, the default is a person confirms the action.
Typical deliverables
What you can expect to have in hand, in accounts and repositories you own.
- Working feature integrated into your app and APIs
- Evaluation dataset and a repeatable test harness
- Prompt and model configuration under version control
- Guardrails for inputs, outputs and tool permissions
- Usage, latency and cost dashboard with budget alerts
- Data flow document for your security and privacy review
Illustrative example, not a client case study
Example engagement
A distributor extracts line items from supplier invoices
Imagine a wholesale distributor whose accounts payable team types line items from hundreds of supplier invoice PDFs into its accounting system every month. Formats differ by supplier, and errors surface at month-end.
Weeks 1 to 2
Define correct
With the AP lead, we list the fields that matter, agree what counts as a correct extraction, and collect sample invoices from the main suppliers into an evaluation set.
Weeks 2 to 5
Prototype with Claude
Extraction with a structured output schema and per-field confidence, scored against the evaluation set on every change.
Weeks 5 to 8
Pilot with a review queue
The AP team checks every extraction in a review screen. Corrections they make are added to the evaluation set.
Weeks 8 to 10
Roll out with limits
Only low-confidence fields go to review, a monthly spend cap and alerts are set, and records post to the accounting system through its API.
Where it ends up
Invoices arrive in the accounting system as structured records, uncertain fields wait for a person, and every future prompt or model change is tested against the same evaluation set before it ships.
Technologies we use
A short, well-known list. We'd rather know a few tools deeply than list every framework we've touched.
| Area | Tools |
|---|---|
| Models | Claude via the Anthropic API, Claude on Amazon Bedrock |
| Retrieval | PostgreSQL with pgvector, OpenSearch, Embeddings and reranking |
| Application | TypeScript, Python, Anthropic SDKs, Tool use |
| Operations | Prompt caching, Batch processing, Evaluation harness, Papel Monitor |
Which development plan fits
AI integration is delivered under a development subscription. These are the plans that suit this work best.
Scale
$1,490 per month, best fit
AI integration with Claude is included, alongside four parallel requests and a quarterly architecture and cost review.
Start with ScaleEnterprise
Custom quote
For AI work that needs a security review, a DPA, deployment in your own cloud account or custom support hours.
Talk to sales
Need a standard in-app assistant without a custom build? Papel Copilot, our early-access product built on Claude, may cover it. About Papel Copilot
Compare all development plansCommon questions
If yours isn't here, ask us on a call or by email.
Will our data be used to train AI models?
Under Anthropic's commercial terms, API inputs aren't used to train models. We also limit what we send to the data each feature needs and document the full data flow for your review. If your policies require it, we can run Claude through Amazon Bedrock in your own AWS account.
Why Claude?
Claude performs well on the work we build most often: following detailed instructions, reading long documents, extracting structured data and using tools. Building on one model family lets us reuse evaluation tooling and guardrails across projects. If a task is better served by a non-AI approach, we'll tell you.
How do you keep AI costs predictable?
We choose the smallest model that passes your evaluation set, cache repeated context, batch work that doesn't need an instant answer, and enforce usage limits per user or workspace. You get a dashboard and alerts tied to a monthly budget you set.
Who pays for model usage?
Model usage is billed by the provider to an account you own, either Anthropic or AWS. That keeps billing transparent and means the integration keeps working if you change development partners.
Can you build on a model other than Claude?
We build on Claude because our evaluation tooling, guardrails and experience are built around it. If you're committed to another provider, tell us early and we'll say honestly whether we're the right team for the work.
What if the feature isn't accurate enough?
The release threshold is agreed before we build. If the prototype doesn't reach it, we tell you, and recommend narrowing the scope, adding human review or using a non-AI approach rather than shipping something unreliable.
Talk to an engineer about ai integration.
A 30-minute call with an engineer, not a sales script. You'll leave with a scope, a plan recommendation and a start date.