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
Which AI model is best for enterprise use?
There is no single best model, and any vendor who names one is selling that vendor. The right choice falls out of four constraints: where your data is allowed to go, what a wrong answer costs, whether a human is waiting on the response, and how much context one decision needs. MetaSys picks per workload against those constraints and writes the reasoning down so it can be revisited when models change.
Does MetaSys train its own AI models?
No. MetaSys builds systems on top of existing foundation models, and fine-tunes open-weight models where a task genuinely needs it. Training a foundation model from scratch is not what most enterprise problems need, and claiming otherwise would be misleading. The engineering value is in retrieval, evaluation, orchestration, and operations around the model.
Can MetaSys deploy AI models inside our own infrastructure?
Yes. Open-weight families including Llama, Mistral, Qwen, DeepSeek, and Kimi can run on your own GPUs behind your own network boundary, served through vLLM. Hosted frontier models can run inside your existing cloud account through AWS Bedrock or Google Vertex AI. If data cannot leave your network at all, that constraint sets the shortlist before capability does.
What happens when a newer model is released?
MetaSys puts an abstraction at the model boundary and keeps an evaluation suite per task, so swapping a model is a configuration change and a test run rather than a rewrite. New releases get measured against your evaluation suite on your data. A model only moves into production if it wins on the tasks you actually run.
Do you use AI coding agents to build client systems?
Yes. Our engineers run modern coding agents as part of delivery, under the same review gates as any other code. Every change is reviewed by a named engineer, tested, and traceable in version control. Agents change how fast a change is drafted, not who is accountable for it.
What is MCP and why does it matter?
MCP, the Model Context Protocol, is an open standard for exposing tools and data sources to a model. Before it, every integration between a model and an internal system was bespoke glue that had to be rewritten per model. MCP makes those integrations reusable across models, which is what makes swapping a model cheap rather than expensive.
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.