Services
AI engineering in Gothenburg, for systems that go into production.
Vynatix, a software consultancy in Gothenburg, builds AI systems on foundation models for production use, with senior engineers embedded in your team. That means retrieval that returns the right context, evaluation that tells you when the model is wrong, deployment into your environment (including on-prem and sovereign cloud) and observability after launch. We say plainly what a model can and cannot do, and recommend a simpler tool when it serves you better.
Scope
What we build
Everything below is part of one thing: production systems on foundation models, meaning software built around a large language model that is in real use, and the engineering around the model that lets you check the answers and see what the system does.
Chatbots and assistants
Software people talk to in plain language to get an answer or get a task done.
Retrieval and grounded answers (RAG)
The system first looks up the relevant passages in your documents, and the model answers from those, citing the source.
Agent and harness engineering
An agent is a model that chooses its own next step and calls tools. The harness is the code around the model that sets what it may do and checks the result.
Workflow automation
Manual steps in a process, such as sorting, extracting details or drafting, handled by a model inside a defined flow.
MCP servers and integrations
Model Context Protocol servers that give an assistant defined, limited access to your systems and data, and connections to what you already run.
SDKs and developer tooling
Libraries and tools that let your own developers build on the system, test it and extend it.
Evaluation pipelines
Automated tests that run the system against questions with known answers, so you can see whether a change made it better or worse.
Deployment into your environment
The system runs where your data is allowed to be: in your own environment, including on-prem on your own servers or in a sovereign cloud.
Production observability
Logging and monitoring of what the system does with real questions, so errors, refusals, response times and cost are visible after launch.
Limits
When is a language model the wrong tool?
A language model is the wrong tool when the answer has to be exact and the same every time, when ordinary code, a query or a search already solves the problem, or when nobody can check whether the output is right.
A model is good at reading and writing language: answering questions over documents, summarising, classifying, extracting details and drafting. It cannot guarantee zero error, it does not know what is missing from what it was given, and the same question can come back worded differently each time.
So we say plainly what a model can and cannot do for your problem, before you spend on one. If a simpler tool would serve you better, we recommend it. If the work is not something we do well, we say so and tell you who can.
Often the better tool
- Ordinary code or a database query, when the answer has to be exact
- A rules engine, when the logic is already written down
- Search, when people need the document rather than a summary of it
- A form, when the input is structured anyway
Regulated client ·
An assistant that answers only from approved documents.
For a regulated client, we built a closed-domain assistant that answers only from approved documents. Every answer cites its source. A question it cannot ground in source is declined and handed to a person, rather than answered with a guess.
The boundary. We set that line deliberately, and we can show you where it sits and why.
Read the caseNo language model has literally zero error. The honest design is a system that refuses outside its domain, and you can see where the line is.
Evaluation and observability
How do you know the system is right?
You know because it is measured, before and after it ships: an evaluation pipeline tests every change against questions with known answers, and production observability shows what the system does with real questions.
Before it ships. An evaluation set is a collection of representative questions, each with the answer the system should give or the note that it should decline. The set is written with the people who know the domain. The pipeline runs it automatically whenever the model, the prompts, the retrieval or the documents change, and compares the result with the previous version, so a regression shows up before release rather than in front of a user.
After it ships. Observability means logging what was retrieved for each question, what the system answered and which source it cited, within your rules for how data may be handled. It also means following refusals, wrong answers, response times and cost over time. Failures found in production go back into the evaluation set, so the same mistake is tested for from then on.
Neither makes a model perfect. Together they make its errors visible and measurable, which is what lets you decide where the line should sit.
What the evaluation checks
- Answers are supported by the source they cite
- Questions outside the documents are declined
- Questions the documents do answer are not declined
- A change to the model, prompts or documents does not make results worse
How we work
Who does the work?
Senior engineers from Vynatix do the work: AI consultants in Gothenburg who work embedded in your team for as long as the assignment needs them. Vynatix AB is a software consultancy in Gothenburg, Sweden, founded in 2023 and part of Ultra Group. Our senior engineers work as part of client organisations on Android Automotive, AI engineering and cloud platforms, with Volvo Trucks and Volvo Cars among our clients.
The people you meet do the work
There is no account layer between the engineer and you. The first conversation is usually in person, in Gothenburg.
Hours reported every week
You pay for the hours worked and see them every week. No black box, no surprise invoice.
You own the code
We own the outcome. You own the code. Every project leaves a record an engineer can read.
Frequently asked questions
What is RAG?
RAG (retrieval-augmented generation) is a technique in which the system first retrieves relevant passages from a document collection, such as your own documents, and then has a language model write the answer from those passages. Because the answer is built on retrieved passages, it can cite its source. The aim is for the facts in an answer to come from the documents rather than from the model's general training. That makes answers checkable, and you control what the assistant answers from by controlling which documents go in.
Can the system run on-prem or in a sovereign cloud?
Yes. Vynatix deploys AI systems into the client's own environment, including on-prem and sovereign cloud, as part of the AI engineering service, so the system can run where your data is allowed to be. Which model you can use then depends on what can run in that environment, and we say plainly what that choice means for quality.
Can the assistant refuse to answer outside the approved documents?
Yes. That is how the assistant Vynatix built in 2025 for a regulated client works: it answers only from approved documents, every answer cites its source, and a question it cannot ground in source is declined and handed to a person. The line was set deliberately, and we can show where it sits and why.
Do you build MCP servers?
Yes. Vynatix builds MCP servers and integrations as part of its AI engineering work. MCP (Model Context Protocol) is an open protocol that lets an AI assistant or agent call your tools and read your data through a defined interface. The server decides what is made available, so access is explicit and can be limited.
How is the work billed?
Vynatix bills for the hours worked and reports them honestly every week, so you can see what you are paying for and why. There is no black box and no surprise invoice.
How do we get started?
Email front.disk@vynatix.com with a subject line starting "Project", and describe what the system should do and what it must not get wrong. Vynatix replies within one working day. The first conversation is usually in person, in Gothenburg, and after that most of the work happens in writing.
Read more
The services page covers all three things we do, and the work page has the three projects we can talk about. In Swedish, we have written a guide to building an AI assistant over internal documents and one on comparing AI consultancies in Sweden.
Considered work
An AI system that has to be right? Start with the constraint.
Tell us what the system must do and what it must not get wrong. We reply to inbound within one working day.
Get in touch