AI & Data
Language models,
inside your stack
A language model becomes useful the moment it can read your ticket queue, write to your ERP and be stopped by your access controls. That integration work — identity, tool calling, idempotency, rate limits, rollback — is the whole job, and it is unglamorous.
Overview
Wiring language models into systems that already have owners, SLAs and auditors.
This service is for organisations that have settled on a model and now need it connected to SAP, Salesforce, ServiceNow, Dynamics, a mainframe or an internal API nobody has touched since 2016. We build the integration layer: authentication, tool definitions, request shaping, retries, idempotency keys and the audit trail.
The design question is always how much authority the model gets. Read-only retrieval is straightforward. Letting a model create a purchase order, refund a customer or close a ticket needs a permission model, a value threshold above which a human approves, and a reversal path that works when the model is wrong at three in the morning.
We treat every tool call as an ordinary API call from a caller who occasionally hallucinates its arguments. Schema validation, idempotency, per-tenant rate limits and a dry-run mode are not optional extras. Neither is the ability to disable a single tool without redeploying anything, which is the control your incident commander asks for first.
- 0.7%
- Tool-call error rate after schema validation and retry policy
- 38 tools
- Live in the Corvus Logistics assistant with scoped permissions
- 4 weeks
- Time to swap the primary model vendor with no application code change
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Tool and function calling design
Tools defined with strict schemas, narrow scopes and idempotency keys, so a retried call does not refund a customer twice. Each tool carries its own permission, rate limit and dry-run behaviour.
Identity and permission propagation
The model acts as the requesting user, not a service account holding every permission. OAuth scopes and row-level access propagate through retrieval and tool calls, so it cannot surface records the user could not open.
Enterprise system connectors
Adapters for SAP, Salesforce, ServiceNow, Dynamics 365 and internal SOAP or REST services, including the ones with a 40-field request body and no documentation. Contract tests run nightly against a sandbox tenant.
Orchestration and durable state
Multi-step flows built as explicit graphs with checkpoints, not a loop that hopes for the best. Long-running tasks resume after a restart, and every step stays inspectable when someone asks what happened.
Observability for model calls
Traces spanning prompt, retrieval, tool calls and downstream API responses, with token cost attached to each span. When a request goes wrong you can see which step did it in under a minute.
Model routing and vendor portability
A provider abstraction with per-task routing, so moving a workload between vendors is a config change and a rerun of the evaluation suite rather than a rewrite. Useful when pricing or availability moves.
Deliverables
What you get
- Tool catalogue with schemas, scopes, rate limits and dry-run behaviour
- Integration adapters with contract tests against sandbox tenants
- Orchestration service with checkpointing and resumable long-running flows
- Identity propagation design covering OAuth scopes and row-level access
- Distributed tracing with per-span token, latency and cost attribution
- Runbook covering tool disablement, rollback and incident escalation
Stack
What we build it with
- Model Context Protocol
- LangGraph
- Temporal
- OpenTelemetry
- Kong Gateway
- Keycloak
- Apache Kafka
- FastAPI
- Azure OpenAI Service
- Amazon Bedrock
- PostgreSQL
- Redis
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
System and permission inventory
We list the systems in scope, their auth model, their real rate limits and who owns each one. Half the integration risk is organisational and shows up on this list.
Authority boundary
We agree in writing what the model may do unattended, what needs approval, and the value threshold that separates the two. This document outlives the project.
Tool build and contract tests
Each tool built, schema-validated and tested against a sandbox tenant, with idempotency proven by replaying the same call and confirming nothing duplicated.
Orchestration and tracing
Flows assembled as explicit graphs, instrumented throughout, and load-tested against your systems' actual rate limits rather than the ones in their documentation.
Controlled release
Dry-run against live production traffic, then a limited cohort with approval on every write, then relaxed thresholds as the measured error rate justifies it.
When this is the wrong engagement
If the workflow is fully deterministic and already has an API on both ends, an integration platform or a scheduled job will be cheaper, faster and far easier to certify than a model in the middle.
FAQ
Questions we get asked
- Which model provider do you recommend?
It depends on the task and your data residency rules, and we build so the answer can change. In practice we run evaluations across two or three providers on your own grading set, then route per task. Reasoning-heavy extraction and high-volume classification rarely want the same model.
- How do you stop the model taking a destructive action?
Destructive operations are not exposed as tools in the first release. When they are, they carry a value threshold, an approval step, an idempotency key and a reversal procedure that has been tested. Anything that cannot be reversed stays behind a human, permanently.
- Can this work with a system that has no API?
Often, through the database, a file drop, or a screen-driven adapter as a last resort. Screen automation is brittle and we price it accordingly; where the vendor offers an API in a newer release, upgrading is usually the cheaper path and we will say so.
- What does this cost to run each month?
Token spend plus orchestration infrastructure, and the second is usually smaller than teams expect. A 200-user internal assistant with retrieval and 30 tools typically runs between £1,500 and £6,000 a month, depending on document volume and how much traffic reaches the larger model.
Related