AI assistants and conversation automation.
I build AI assistants that answer from your own knowledge — documents, procedures, case history — rather than from whatever the model invents. And systems that analyse the conversations nobody has the hours to review.
A chatbot that invents answers is worse than no chatbot; in a regulated industry it is a liability. So I ground every assistant in a defined body of knowledge: an answer has to be traceable to a source, and where there is no source, the system has to say it doesn't know.
The other half of this work is conversations that already happened. Interviews, customer calls, support tickets — material nobody analyses because the hours don't exist. That is where AI recovers knowledge you have already paid for.
What I build
Assistants grounded in company knowledge
A system that answers from your documents, procedures and case history — with the source shown alongside every answer.
Support for expert teams
An assistant that shortens a specialist's research: finding the right regulation, interpretation or prior case and drafting an answer for review.
Customer-support automation
Classifying and triaging tickets, drafting replies for an agent, and handing the case to a human at the point where the system stops being confident.
Conversation and interview analysis
Transcription and analysis of recordings: findings, recurring themes, risk signals. Available in a fully private variant where recordings never leave the client's infrastructure.
Integration with the channels you use
Slack, Teams, email, an internal panel, telephony and CCaaS platforms — the assistant shows up where people already work instead of becoming another window.
Who this is for
- Advisory and expert firms whose knowledge is scattered across documents and people's heads.
- Customer-support teams handling a high volume of repetitive tickets.
- Regulated industries where an answer has to be justified by a source.
- Organisations that record conversations and have no capacity to analyse them.
How I run it
- 01Scope and boundaries
We agree what the system answers — and, just as importantly, where it must decline and pass the case to a person.
- 02Preparing the sources
Documents have to be processed, structured and kept current. This is usually a larger job than the model itself.
- 03Evaluation on real questions
Before users see it, I test the system against a set of genuine historical questions, scored for accuracy — not on the impression that it “answers nicely”.
- 04Rollout and oversight
Launch in one channel, watch the answers, correct the scope. Expansion comes only once quality has settled.
Implementations
From an assistant for tax advisors to private interview analysis in due diligence — wherever the answer has to be justified and the data cannot leak.
A self-updating base of 538,000 tax interpretations, hybrid search, a research agent and opinion drafts. From ~12 hours of work to ~2 minutes.
Read the case studyA due-diligence consultancy's interviews turned into structured findings automatically — AI answers every agenda question, validates each answer against the transcript, and catches the unprompted disclosures that matter in a deal. Runs entirely on the firm's own in-country cloud.
Read the case studyA REST backend for a therapists' mobile app — 40+ workflows, 30+ endpoints, RAG per therapy method, a therapeutic agent behind a routing layer, audio/image/PDF input. Production with no critical bugs.
Read the case studyCommon questions
- How do you stop the assistant inventing answers?
- Answers are built from specific passages in your documents and shown with the source. The system is also explicitly set up to say “I don't know” when there is no basis rather than improvise — and that behaviour is measured in evaluation before launch.
- Will our documents go to an external model?
- That depends on your requirements. We can use commercial models under agreements that exclude training on your data, or run entirely locally on models hosted in your own infrastructure. For sensitive data I propose the local option by default.
- Will this replace our support team?
- In practice it takes over the repetitive part and prepares the groundwork for harder cases. The team stays — it just stops answering the same question for the thousandth time.
- What about Polish?
- I build and test these systems in Polish. Polish is harder for semantic search than English, so model choice and document preparation matter more here — and that is part of the work.