// ai engineering · malmö, sweden
AI systems that survive contact with production
Everyone has a demo. We build the part that comes after: retrieval you can trust, evaluation you can measure, guardrails you can defend and infrastructure you can afford.
// what we do
The engineering work behind a useful AI feature
We come at AI from the infrastructure side: the model is one component in a system that also needs data, evaluation, observability, cost control and an owner.
From prototype to production
Most AI projects die between a convincing demo and a reliable system. We take the demo, put evaluation, guardrails, observability and cost control around it, and ship it.
Retrieval (RAG) done properly
Chunking strategy, hybrid search, reranking, freshness and citation. Retrieval quality, not model choice, is what usually decides whether an assistant is trusted.
Agents and tool use
Bounded agents with typed tools, deterministic fallbacks, budget limits and human approval where it matters. Autonomy where it pays, guardrails everywhere else.
Evaluation and quality gates
Golden datasets, LLM-as-judge with human spot checks, regression suites in CI. If you cannot measure a change, you cannot ship a model upgrade safely.
LLM platform & gateway
A single gateway for routing, caching, rate limits, key management, per-team budgets and audit logs, so every product team is not integrating providers on their own.
Inference infrastructure
GPU node pools on Kubernetes, vLLM or Ollama for self-hosted models, autoscaling to zero, and an honest comparison against just paying an API provider.
AI in the developer workflow
Coding assistants, review bots and generated tests, introduced with policy, secret hygiene and measurement, so the productivity claim can actually be checked.
Governance and the EU AI Act
Use-case classification, data flow documentation, logging and human oversight, the practical engineering work behind the compliance paperwork.
// architecture
A reference stack for LLM applications
Not every project needs every layer, but knowing which layer a problem belongs to is half the work.
// method
How we take an AI use case to production
- 01→FramePick a use case with measurable value and tolerable failure modes.
- 02→BaselineBuild the boring version first, often search or rules beat an LLM.
- 03→EvaluateGolden set and metrics before optimisation, not after.
- 04→HardenGuardrails, PII handling, fallbacks, budgets and rate limits.
- 05OperateTraces, drift watch, cost per request and a model upgrade routine.
// maturity
The AI adoption ladder
Most organisations we meet are somewhere between stage 1 and stage 2. The gap to stage 3 is mostly platform work, and it is very learnable.
Experiments
Individuals use chat tools privately. No policy, no measurement, and no idea what data leaves the building.
First feature
One AI feature reaches users. Prompts live in code, quality is judged by vibes, and cost is a surprise on the invoice.
Repeatable
A shared gateway, evaluation suites and traces exist. A second team can ship an AI feature without reinventing the plumbing.
Governed
Use cases are classified, data flows documented, human oversight defined, and model upgrades are a routine rather than a risk.
Compounding
AI is part of the golden path: evaluation in CI, budgets per team, and retrieval quality improving from real usage data.
// landscape
What a consultant should know in the AI era
The tooling churns fast, but the categories are stable. These are the ones we keep our hands in.
// our view
Opinions we hold, until evidence says otherwise
Most AI problems are data problems. The difference between a useless assistant and a good one is almost always retrieval quality and content structure, not which frontier model you picked this quarter.
Model choice should be a config value. Providers leapfrog each other every few months. Build behind a gateway so switching is a deployment, not a project.
Evaluation is the real moat. A team with a solid golden dataset can adopt a new model in a day. A team without one is guessing forever.
Agents need least privilege. Give an agent tools the way you would give an intern production credentials: narrowly, with logging, and with an approval step for anything irreversible.
// faq
Questions we get about AI
Should we self-host models or use an API?
For most teams, start with a managed API and a gateway that makes switching cheap. Self-hosting pays off when you have steady high volume, strict data residency requirements, or a fine-tuned model, and someone to run the GPUs.
How do we stop an AI feature from making things up?
Ground answers in retrieved sources, require citations, constrain output with schemas, and add a refusal path. Then measure it: a golden dataset with expected answers turns hallucination from a feeling into a number you can drive down.
What does the EU AI Act mean for us in practice?
Mostly: know which of your use cases are high risk, document data flows and model decisions, keep logs, and ensure a human can intervene. Nearly all of that is engineering work we can help you implement rather than paperwork.
Our AI costs are unpredictable. Can that be fixed?
Yes. Caching, smaller models for easy paths, prompt trimming, streaming limits and per-team budgets at the gateway typically cut spend substantially while keeping quality where it matters.
Is prompt injection a real risk?
Very. Any agent with tools and access to untrusted text needs least-privilege tools, output validation and approval steps for anything destructive. We treat it as a security design problem, not a prompt-wording problem.
// how we work
// contact
Have an AI idea stuck between demo and production?
Tell us what you are trying to build and we will tell you honestly whether AI is the right tool for it.
office: Malmö, Sweden · uppdrag across Europe