We don’t know what we need yet. Is that a problem?

No — it is the normal starting position, and the first step exists precisely for it. Come with the symptom rather than the solution. “Three people spend every Monday reconciling spreadsheets” is a better brief than “we want an AI agent,” because it can be measured and it might turn out to need something other than AI.

Where does our data actually go?

Wherever you decide, and you will know before anything moves. Some work can run entirely on infrastructure you control with models that never leave it; some is better served by a hosted provider. The trade-off between the two is a design decision we put in writing — which system sees which data, in which jurisdiction, under whose terms — rather than a detail discovered afterwards.

Do we have to replace the systems or the team we already have?

Almost never, and we would push back if someone suggested it. The useful work usually sits alongside what exists — reading from the ERP you already run, respecting the permissions you already grant. Your engineers know your estate far better than we will in three weeks, and the goal is to leave them able to maintain whatever we build.

What if the honest answer is that AI won’t help?

Then we say so and you have saved a great deal of money. A fair number of problems presented as AI problems are reporting problems, integration problems, or a process nobody has written down. Telling you that is more valuable than building something impressive that quietly gets abandoned in month four.

You’re new. Why would we trust you with this?

On the evidence, not on our say-so. OpsVector is a young company with a small senior team and we are not going to pretend otherwise or decorate this page with logos we haven’t earned. Start with the smallest stage, judge the written output, and continue only if it is good. Everything we produce is documented so that it stays useful even if you never work with us again.

How does the commercial side work?

Each stage is scoped and agreed before it begins, so there is no open-ended commitment and no surprise at the end of a quarter. What a stage costs depends entirely on what it contains, which is why the conversation starts with the problem rather than with a price list.

AI engineering · DevOps · Europe

AI systems cleared for regulated environments.

Most AI projects stop at a chatbot reading a PDF. The work that matters starts where access is controlled and decisions have to be explained later — document management, payment infrastructure, identity and KYC data, production systems. We build for those environments, with tool surfaces narrow enough to take into a security review.

Start a conversation See how we think →

Small senior team, forming now · Working across the EU · Taking on new work

In one paragraph

OpsVector is a European engineering studio. We build retrieval systems (RAG), Model Context Protocol (MCP) servers and agentic AI for small and mid-sized companies working under real constraints — GDPR, the EU AI Act, internal access policy. Systems that respect the permissions you already grant, keep data in the jurisdiction you choose, and can account months later for why they did what they did.

One real problem

We could list the acronyms we know. It’s more useful to show you a decision.

Secure MCP server development for systems that are already running in production.

A retail operator runs several thousand POS terminals across hundreds of sites. Some are failing quietly — CPU throttling, disks filling, a flood of syslog nobody reads. They want an AI assistant that can diagnose them, without granting it standing access to card-handling infrastructure. Here is where that project is won or lost.

THE DEMO THAT SHIPS IN AN AFTERNOON

Expose one tool over SSH and let the model figure it out. It works immediately. It demos beautifully.

tool run_command(host, command) → stdout

It also grants a language model unrestricted access to payment hardware, on the strength of whatever text happened to land in its context. No version of this passes a security review, and under PCI DSS the access itself is the finding — before anything has gone wrong.

WHAT WE BUILD INSTEAD

We take the runbook an engineer already follows and turn each step into a narrow, typed, read-only tool. The model gets judgement. It never gets a shell.

tool get_thermal_state(host)          → read-only
tool get_cgroup_limits(container)    → read-only
tool search_logs(host, pattern, win)  → read-only
tool propose_remediation(finding)    → needs human sign-off

Every call is bounded, logged and attributable to a named person. Nothing changes a terminal without explicit human sign-off. The scope of what the system can reach is a documented design decision — the answer an auditor asks for.

Same symptom, four different root causes — thermal, cgroup quota, frequency governor, VM steal time. Diagnosis is ruling things out. That’s engineering, not prompting.

And the unglamorous half nobody demos

A working prototype is perhaps a fifth of this job. The rest is what decides whether anyone is still running it in a year: a log of every call the model made and what came back, so any question about a past decision has an answer. Rate limits, so a retrying agent cannot overwhelm the systems it depends on. An evaluation set built from your own historical cases, so you can tell whether a prompt change made things better or merely different. A defined behaviour for when the model is unavailable, because it will be. And a single documented way to switch it off, owned by a named person.

None of that is exciting. All of it is the difference between a demo and a system.

House style

Never expose a generic capability.

Four rules do most of the work. They are the difference between a system that impresses a boardroom and a system you are willing to leave running on a Friday night.

They are not opinions we hold lightly. Each one exists because the alternative has a well-documented failure mode, and because the cost of that failure lands on the client rather than on us.

Narrow tools, not shells

A tool that can do anything can do anything wrong. We enumerate the actions a system genuinely needs, type them, bound them, and expose nothing else. If a capability isn’t on the list, it doesn’t exist.

It costs more up front. It is also the only version you can put in front of a security review without flinching, and the only one where the worst case is knowable in advance rather than discovered.

Determinism owns what must be exact

Language models paraphrase, and paraphrasing a number is a liability. Code computes every figure into fixed slots; the model writes only the prose around them. Generated narrative, computed facts.

The same split applies to dates, identifiers, totals and anything a regulator might ask you to reproduce. Use the model for judgement and language. Never for arithmetic.

Your own files are untrusted input

A README can carry an instruction. A scoped directory still holds an .env, a stray customer export, a symlink pointing somewhere it shouldn’t. Retrieval is an attack surface, and we treat it like one.

Which means scoping is the floor, not the ceiling: paths resolved before they are checked, secrets caught at the tool boundary, and retrieved content that can never be mistaken for an instruction.

If you can’t reconstruct it, you can’t defend it

Months later someone will ask why the system did what it did on a particular Tuesday. That question has to have an answer: which inputs, which retrieved sources, which model, which version of the prompt, which human approved it.

We build that record from the first day rather than retrofitting it after the first awkward meeting, because retrofitting it is not actually possible.

What we take on

Work that has to hold up under review.

RAG development, MCP servers, document management and extraction pipelines, agentic workflows, and the DevOps engineering underneath all of it.

MCP servers for access-controlled systems

Turning an existing runbook into a tool surface an agent may use: scoped, typed, read-biased, fully audited. Diagnostics first, changes only behind an approval gate.

Retrieval that respects who is asking

RAG over real company data, where the CFO and the new intern ask the same question and must get different answers — and no summary is allowed to leak across that line.

Document management and extraction

Classification, extraction, validation and risk checks against your existing DMS or records system — identity documents, invoices, contracts — built so a human can account for every decision months after it was made.

Agentic workflows with a human in the loop

Agents that may propose anything and execute nothing without a signed approval. Designed around the exception case, because that is the part a review will ask about.

A straight answer on where AI is worth it

An honest read on where AI actually pays for itself in your operation, which ideas to kill early, and what has to be true before any of it touches production. Frequently the useful output is a shorter list than the one you arrived with.

The DevOps underneath it

None of the above survives without infrastructure as code, pipelines, observability and a way to roll back. We build that part too, because we have to live in it.

How it runs

Four steps, and you can stop after any of them.

How an AI engagement works, from the first assessment through to full handover to your own team.

Nobody should have to commit to a six-month build before finding out whether the idea holds. So the work is arranged so that each stage produces something you keep and could hand to somebody else.

STEP 01
Work out whether there is a problem worth solving
A short engagement, usually days rather than weeks. We sit with the people doing the work, not only the people describing it, and establish what actually breaks, how often, and what it costs when it does. You end up with a written problem statement and an honest verdict — including, sometimes, that AI is the wrong instrument and something simpler would do.
STEP 02
Design it before building it
The architecture, the tool surface, where the data travels and who may see it, what the system is forbidden to do, and how it fails. Written down, with the rejected options and the reason each was rejected still visible. This document belongs to you. If you take it to another firm, they can build from it.
STEP 03
Build the smallest thing that proves it
Narrow scope, real data, real constraints, running where it will eventually live rather than on someone’s laptop. Evaluated against cases drawn from your own history, so “is it good enough?” has a numeric answer instead of a vibe. If the numbers say no, that is a cheap and useful result.
STEP 04
Hand it over properly
Infrastructure as code, pipelines, monitoring, runbooks, and your engineers walked through all of it until they can change it without us. We are happy to stay on for support, and we would rather you didn’t need it. A supplier you cannot leave is a risk on your register, not a service.

In the open

We’re new, so we’ll show the working.

OpsVector is a young shop. We’d rather prove competence than assert it, so we’re publishing the thing nobody publishes: the whole design path for real systems, including the turns that were wrong and why we took them.

Not a tidy architecture diagram at the end. The decisions, in order, with the trade-offs still visible.

Engineering notes
Written by us, on the parts of AI engineering that don’t fit in a launch post. Starting with why the filesystem MCP server is the one that most often fails a security review.
SOON
An interactive system design guide
Full builds, step by step, from a blank page to something defensible — the diagnostics platform, a payment flow, a document risk pipeline. Follow the reasoning, not the result.

Before you write

The questions that come up every time.

What European companies ask about AI adoption, data residency and GDPR before they start.

We don’t know what we need yet. Is that a problem?: No — it is the normal starting position, and the first step exists precisely for it. Come with the symptom rather than the solution. “Three people spend every Monday reconciling spreadsheets” is a better brief than “we want an AI agent,” because it can be measured and it might turn out to need something other than AI.
Where does our data actually go?: Wherever you decide, and you will know before anything moves. Some work can run entirely on infrastructure you control with models that never leave it; some is better served by a hosted provider. The trade-off between the two is a design decision we put in writing — which system sees which data, in which jurisdiction, under whose terms — rather than a detail discovered afterwards.
Do we have to replace the systems or the team we already have?: Almost never, and we would push back if someone suggested it. The useful work usually sits alongside what exists — reading from the ERP you already run, respecting the permissions you already grant. Your engineers know your estate far better than we will in three weeks, and the goal is to leave them able to maintain whatever we build.
What if the honest answer is that AI won’t help?: Then we say so and you have saved a great deal of money. A fair number of problems presented as AI problems are reporting problems, integration problems, or a process nobody has written down. Telling you that is more valuable than building something impressive that quietly gets abandoned in month four.
You’re new. Why would we trust you with this?: On the evidence, not on our say-so. OpsVector is a young company with a small senior team and we are not going to pretend otherwise or decorate this page with logos we haven’t earned. Start with the smallest stage, judge the written output, and continue only if it is good. Everything we produce is documented so that it stays useful even if you never work with us again.
How does the commercial side work?: Each stage is scoped and agreed before it begins, so there is no open-ended commitment and no surprise at the end of a quarter. What a stage costs depends entirely on what it contains, which is why the conversation starts with the problem rather than with a price list.

Something in production, something regulated?

Tell us the problem in plain words — what breaks, who it hurts, what you’ve already tried. If it isn’t a fit, we’ll say so and point you somewhere better.

No form, no discovery-call funnel, no sequence of automated follow-ups. An email reaches a person who has built this kind of system, and the first reply will be either a real question or an honest “not us.” We work in English, remotely, across European time zones.

contact@opsvector.ai

We reply to every message that isn’t automated.