AI integration services
We do not train models. We embed existing ones where the work already happens — and make them dependable: decisions stay with people, and every answer has a source.
This already runs
Our own sales system has run for 20 months: a messenger assistant has handled 3,332 messages, the system has carried 260 orders and generated 196 documents without a human. Customer document data is extracted from photographs. Figures reconciled against the live database on 14.09.2026.
Separately, an internal platform where agents search for opportunities daily, parse them and draft replies. Nothing leaves without approval: that is not a setting but a property of the system.
What we actually do
- An agent that does work, not one that answers questions
- The difference between a chatbot and an agent is whether it can reach your data and act. An agent reads the database, checks it against your rules, prepares a document or a reply and stops before anything a human must approve. A chatbot just talks.
- Answers with a source, not from the model’s memory
- A model without access to your data will confidently quote a price, a lead time and availability — and the customer sees the mistake before you do. So in a working system the model may not assert anything the data does not contain: it phrases, it does not decide, and every answer carries what it was drawn from.
- A human in the loop by design
- Not «you can review before sending» but «it cannot be sent unreviewed». Those are different things: the first relies on discipline, the second on code. Anything leaving the building — an email, a document, a post — goes through approval, and the system cannot route around it.
- Embedding into what already exists
- AI is rarely a separate product. More often it is a layer inside your CRM, admin panel or messenger — where people already work. So most of the job is not prompts but integrations: data access, permissions, queues, and what happens when a third-party service is down.
Three things that break these systems
We hit all three in our own systems rather than reading about them.
- A model that invents
- The most expensive failure is not technical. An invented price sounds exactly as confident as a real one, and the customer remembers it. The cure is not a better prompt but architecture: the model has no field in which to write something the data does not contain.
- Cost that surfaces later
- A model call costs money, and a system that calls one on every action drains the budget quietly. Cheap deterministic filtering in front of the model removes most of the work: rules handle the obvious, and the model only looks at what genuinely needs judgement.
- «Success» does not mean it worked
- A success response confirms the request was accepted, not that a human saw anything. The difference shows only in the delivery log, and it has to be checked systematically. We were caught by this in our own system — now it checks itself.
Frequently asked
Do you train models?
What does it cost to run?
Will our data go into a model?
How is this different from an off-the-shelf chatbot?
Answers on this topic
Plain explanations without marketing — useful even if you never hire us.
Custom system or an off-the-shelf box: an honest comparison
When a boxed product wins, when custom wins, and the third option: a working system adapted to your process. Lock-in, code ownership, support, migration risk.
Selling on WhatsApp: the 24-hour window and lost messages
How the WhatsApp Business API actually behaves: the 24-hour window, templates, and why an "ok" from the API does not mean the customer saw your message.
Automating invoices, contracts and delivery notes
Why salespeople lose hours to paperwork and what to automate first. A worked example: 196 documents generated by the system with no manual typing.