AI implementation
We take an AI solution from decision to daily use in the systems you already have. One bounded workflow first, a fixed price before we start, a human left as the checkpoint.
Short answer
AI implementation is the work of taking an AI solution from idea to production in your existing systems: mapping which workflow to automate, building it against your systems and putting it live with people left as the checkpoint. The difference from a demo is that the solution is actually used in the everyday, every day.
Three things, and they hang together.
Agents that read, assess and act on what comes in: email, forms, documents, enquiries. Process automation that removes the steps where someone moves information between two systems by hand. Integrations that connect what you already have, so that a record is only entered once.
We build in your systems, not alongside them. In practice that means Fortnox or Visma on the finance side, Microsoft 365 or Google Workspace for mail and documents, HubSpot, Salesforce or Pipedrive in CRM, and Slack or Teams where the work is discussed. If you have your own systems with an API, or even an export, we connect those too.
So you are not buying a new platform or a licence for a tool your staff has to learn. The automation ends up where the work already happens.
Four patterns that keep coming back. None of them is about the technology being too weak.
01
Someone decides you should do something with AI and then goes looking for a problem that fits. That gives you a demo that impresses the management team and helps nobody on Monday. We go the other way: which five hours a week go to something nobody really needs to do by hand?
02
An agent can only be as good as the material it reads. If the customer records live in three systems with three different spellings, and nobody is responsible for which one applies, the solution will make the wrong decision in the right way. Data ownership has to be assigned before the build starts.
03
There is a big difference between code that works when the person who wrote it runs it, and code that works on an ordinary Tuesday in November when an API is slow to answer. Logging, error handling and a plan for who gets alerted when something breaks belong to the build, not to the aftermath.
04
Solutions that are allowed to send binding replies without anyone looking get switched off the first time they are wrong. We build the opposite way: the agent prepares, a responsible person approves. The checkpoint moves only once you have seen enough correct outcomes yourselves.
Four steps. You know at all times what is happening and what the next part costs.
01
We go through your workflows together with the people who actually do the work, not only with management. We put numbers on volume and time per step and look at what data exists and what it looks like in reality. The result is a list of candidates ranked by effect over effort, and a proposal for which workflow we should start with.
02
We build one bounded workflow all the way to running condition, in your systems and against your real data. You get to watch it take shape, not a closing presentation. The pilot is quoted at a fixed price before we start, and it is built to go into production, not to be demonstrated and thrown away.
03
The solution goes live with permissions, logging and alerts in place. For the first few weeks we follow the outcomes closely together with you, because real production is where you see the exceptions: the customer who writes in a way nobody anticipated, the attachment that is missing, the day volume triples.
04
We keep the solution running, update it when your systems or the models change and build further at the pace you decide. If you want to take over operations yourselves that is entirely fine, everything is documented and the code is yours.
That is the promise we build our whole way of working around. One bounded workflow, in production at your company, within two to four weeks of starting. The price is fixed and set before we begin, so you know exactly what you are saying yes to.
The bounding is the whole point. A company that automates its entire order handling at once gets a project that runs for nine months and that nobody remembers the reason for. A company that automates the reading of incoming order emails gets something that works before the next monthly meeting, and concrete grounds for deciding what the next step should be.
If the pilot does not give the effect we counted on, we say so plainly. You will have paid a known amount to find out something that was worth knowing, and you decide for yourselves whether we carry on.
Riktpriser
Indicative prices for the three most common scopes. Bigger than that? Then we start with a conversation about whether two people are enough, and we answer honestly.
Indicative prices excl. VAT. Your project is always quoted at a fixed price before we start.
Riktpriser
An automation nobody maintains stops working the day a system is updated. So we price operations openly instead of pretending it is free.
Indicative prices excl. VAT. You are never tied to us for operations: everything is documented so that you can take over yourselves.
Five principles we work by, and we are happy to take questions on them.
01
We build around the systems you already have and do not move information to a platform of our own. What is sent to a language model is what the task requires, nothing more, and we go through exactly what that means for each workflow before it goes live.
02
The automation gets the rights it needs and no more. Every run is logged so that you can see afterwards what was read, what was proposed and who approved it. It is also what you need the day someone asks.
03
Quotes, contracts, customer replies and payments never go out without a responsible person having looked at them. The agent prepares the material, the human makes the decision. You decide where that line sits, and it can be moved once you have seen enough.
04
We use models in a way that does not hand your records over to model training, and we write out which suppliers are involved in the solution. If anything about that is to change, we need your explicit yes first.
05
We document which risk class your solution falls into and what it means for you. Most automations of internal administration land in low risk, but the assessment should be made and written down, not assumed.
Caesar Katende works on agent architecture and orchestration: how a solution is broken up, which tools the agent is allowed to use, how it is evaluated and where the human checkpoint belongs. Ted Wachtmeister works on backend, data and ML as well as operations: integrations, data pipelines, error handling and the parts that have to hold when volume goes up. Both studied at Lund University.
The same people all the way: the person who draws the strategy writes the code and runs the training. Nothing gets lost in a handover.
It also means you talk to an engineer in the first call, not to a salesperson who has to get back to you after checking internally.
Common questions
No. We build in the systems you already use and connect through their APIs. Introducing a new platform at the same time as you introduce automation is two changes at once, and that is usually one too many.
Then we say so. You have paid a known amount to find out something that was worth knowing, and you decide for yourselves whether we adjust, move on to a different workflow or stop. We would rather sell an honest no than a project nobody uses.
You do. The code, the documentation and the configuration are yours and are handed over in your own repositories. You are not locked into a maintenance agreement to get access to what you have paid for.
Either in your own environment or with a cloud provider we agree on, always with logging and alerts. We can run operations on an ongoing basis, or hand them over to your IT function with the documentation as the basis. The indicative prices for operations are open above.
The first call takes 30 minutes and is free. After that the mapping is normally under way within a couple of weeks depending on how the calendar looks, and a pilot is in production 2-4 weeks after the build starts.
We pick the model to suit the task and switch when something better arrives. Simple classification does not need the most expensive model, while reasoning over a complex set of documents does. We write out which suppliers are used in your particular solution, so that you can take a view on it.