The models, agents and tooling we build on
We are model-agnostic by design. This page is the honest version of what we deploy, how we choose between options, and what we deliberately do not do. It is maintained rather than written once.
Four constraints decide the model, not a leaderboard
Benchmarks move faster than any page can track, and they are measured on someone else's tasks. These are the questions we actually work through with you, and they stay true no matter which model is ahead this quarter.
Where is the data allowed to go?
This decides more model choices than capability does. If data cannot leave your network, the shortlist is open-weight models on your own infrastructure, and everything else follows from that.
What does a wrong answer cost?
A misrouted support ticket and a misread loan document are not the same risk. High-consequence steps get a stronger model, tighter evaluation, and a human gate. Low-consequence steps get a cheap model.
Is a human waiting?
Interactive workflows are latency-bound and often want a smaller model close to the user. Batch workflows are throughput-bound and can absorb a slower, more capable one.
How much context does one decision need?
Long contracts, case files, and log dumps push toward large-context families. Short structured records rarely justify the cost.
What happens when the model changes?
We put an abstraction at the model boundary and keep evaluation suites per task, so swapping a model is a config change and a test run, not a rewrite. You are never locked to one vendor.
What we deploy, and what we reach for it on
Listed by family rather than version number, because versions change and the reason you would pick a family does not. Open-weight families can run entirely inside your own network.
| Family | Weights | Strengths | We reach for it on |
|---|---|---|---|
| ClaudeAnthropic | Hosted | Long-context reasoning, careful instruction following, and tool use that stays coherent across many steps. | Agentic workflows with a lot of tools, and anything where a wrong answer is more expensive than a slow one. |
| GPTOpenAI | Hosted | Broad general capability, mature function calling, and the widest ecosystem of client libraries and integrations. | General assistants, structured extraction, and teams that already standardised on the OpenAI SDK. |
| GeminiGoogle | Hosted | Very large context windows and native multimodal input across text, image, audio, and video. | Document-heavy and multimodal pipelines, and workloads already sitting inside Google Cloud and Vertex AI. |
| LlamaMeta | Open | Open weights with a large tooling ecosystem, so it runs anywhere you can run a GPU. | Self-hosted and air-gapped deployments where data cannot leave your network. |
| Mistral and MixtralMistral | Open | Strong capability per parameter, so inference cost and latency stay low at volume. | High-throughput classification and routing steps where a frontier model would be overkill. |
| QwenAlibaba | Open | Wide range of open sizes and strong multilingual coverage, including non-Latin scripts. | Multilingual workloads and self-hosted deployments that need a specific parameter budget. |
| DeepSeekDeepSeek | Open | Open reasoning-focused models with competitive cost per token. | Reasoning-heavy batch work where per-token cost dominates the business case. |
| KimiMoonshot AI | Open | Long-context handling and strong agentic tool-use behaviour. | Long-document workloads, and as an open alternative when a hosted frontier model is not an option. |
Open-weight families run on your own GPUs through vLLM. Hosted families can run inside your existing cloud account through AWS Bedrock or Google Vertex AI, so inference never leaves your account.
The layer between a model and a system you can run
A model on its own is not a system. These are the parts that make it one, and the parts most of the engineering actually goes into.
Coding agents
How our engineers write and review code. Every change still goes through the same review gates as any other commit.
- Claude Code
- Terminal-native coding agent. Multi-file changes with the repository as context.
- Codex
- OpenAI's coding agent for delegated, sandboxed engineering tasks.
- Cursor
- AI-first editor. Repository-aware edits and review inside the IDE.
- GitHub Copilot
- In-editor completion and review, wired into GitHub pull requests.
- Replit
- Browser-based agent environment for prototypes and internal tools.
- Windsurf
- Agentic IDE aimed at multi-step changes across a codebase.
Agent frameworks
How an agent is given tools, state, and somewhere for a human to step in.
- MCP
- Model Context Protocol. An open standard for exposing tools and data to a model without bespoke glue per integration.
- LangGraph
- Stateful agent graphs with explicit control flow, checkpoints, and human-in-the-loop gates.
- LangChain
- Tool and model integration layer underneath the graph.
- CrewAI
- Role-based multi-agent orchestration for workflows that split across specialists.
Retrieval and data
How a model gets grounded in your data, so an answer can be traced back to a source.
- RAG
- Retrieval augmented generation. Grounding answers in your own documents so outputs are citable.
- pgvector
- Vector search inside Postgres. Our default when a client already runs Postgres.
- Pinecone
- Managed vector database for retrieval at scale without running the infrastructure.
- Weaviate
- Open-source vector database, self-hostable alongside the rest of your stack.
Serving and ops
Where inference runs and how regressions get caught before a release rather than after.
- vLLM
- High-throughput inference server for open-weight models on your own GPUs.
- Bedrock and Vertex AI
- Managed model hosting inside AWS and Google Cloud, so inference stays in your existing cloud account.
- LangSmith
- Trace logging and evaluation runs, so regressions are caught before a release rather than after.
- MLflow
- Experiment tracking and model registry for the parts of the stack that are trained rather than prompted.
What we do not do
“AI company” covers a lot of very different businesses. Here is where our boundary sits, so nobody has to discover it during procurement.
We do not train foundation models. We build systems on top of them, and fine-tune open-weight models where a task genuinely needs it.
We do not publish our own benchmark leaderboard. Public benchmarks move faster than any marketing page, and the number that matters is your task, measured on your data.
We are not tied to one vendor. Model choice is an engineering decision per workload, and it is written down so it can be revisited.
This page is reviewed every 90 days, and whenever we touch this site. Where we do build, see agentic AI systems, AI agent development, and managed AI operations.
Model and tooling questions
Not sure which of these your problem needs?
That is the conversation. Bring a workflow you want to automate and we will tell you which parts of this stack it actually needs, and which parts it does not.