What Savia is and why I'm building it

Savia isn't a chat that knows about your company.

It's where your company's knowledge stops walking out of the door.

Everything else I'm about to describe hangs off that sentence.

The problem, as a scene

It's half past nine in the morning. Someone new is three weeks into the team. An issue lands on their desk that they've never seen before.

They have two options. Work it out alone for forty minutes, or ask the person who has been there eight years and knows the answer in twenty seconds.

They ask. It's the rational thing to do.

Multiply that by five new people and by every day of the year. The person who knows the answer stops having time for their own work. And the knowledge stays exactly where it was: in their head.

That's the problem. It isn't about tools. It's about where the information lives, and what happens the day that person leaves.

Why ChatGPT doesn't solve it, and not for the reason you think

Two years ago the argument was easy: a generic model doesn't know your internal processes.

That argument doesn't hold any more. You upload the documents and it knows them.

The real argument is a different one, and it's three things.

It doesn't know who's allowed to see what. Marta in Purchasing shouldn't be able to read what's in the HR folder. A generic chat with all your documents inside it doesn't distinguish: if it's uploaded, it's available to whoever asks.

It leaves no trace. If in six months you need to know who looked up a client's margin, there's nobody to ask. In a company with sensitive information that isn't a detail: it's the reason legal says no.

And above all, it doesn't close the loop on what nobody has written down yet. You can upload absolutely everything you have documented. What isn't written still isn't written, and that's precisely the part living in two people's heads. There's no competing there, because it isn't a model problem. It's a process problem.

How the knowledge gets in

The documents you already have

Manuals, procedures, minutes, templates. The easy part, and the least valuable one, because it's the part that's already written.

The day-to-day conversations

Most of a company's useful knowledge never became a document: it was said in a chat, on a call, or standing next to someone's desk. Savia captures those conversations automatically and turns them into knowledge you can query.

The expert's video

This is the piece I'm happiest with, and the one that best answers the premise of this article.

The twenty-year veteran can't write down what they know. They've never drafted a procedure and they aren't going to start now. But they know how to teach it: put someone in front of them and they'll explain it in three minutes.

So I don't ask them to write. Straight from the form they record their screen and talk it through the way they'd tell a colleague. Savia transcribes the video and indexes it.

What happens next is what makes this a demo rather than a feature: when someone asks about it, the chat answers citing minute 4:32 and plays that exact moment of the video underneath the answer.

The knowledge leaves that person's head in three minutes of video, not in three hours of documentation they were never going to write.

How it answers

Savia uses RAG, short for retrieval-augmented generation. In plain terms: before answering it searches your company's knowledge, takes the fragments that apply, and builds the answer from them.

Every answer carries its source: which document, who contributed it, when — or the exact minute of the video.

And when it doesn't know

This is where most products go vague and say "the model admits when it doesn't know", as if it were a character trait.

In Savia it's a mechanism, and it's measurable: if the best match found doesn't reach the confidence threshold, two things happen at once.

1. The answer comes back flagged as unofficial. Whoever asked can see that it isn't backed by company documentation.
2. That question is logged as a gap.

Honesty doesn't depend on the model having a good day. It's a consequence of where you set the threshold.

The loop: from gap to knowledge

Gaps don't sit in a list nobody looks at.

The system groups similar gaps together. When several people ask equivalent things within the same window of time, that stops being a stray question and becomes a real documentation hole.

Only then is a form generated. And it doesn't go to just anyone: it goes to the area's referent with the fewest items pending at that moment.

That detail matters more than it looks. This article opens with the problem of the veteran drowning in the same questions; it would be absurd to fix that by firing a form at them every time someone has a doubt. It doesn't trigger on the first question, and it isn't always the same person's turn.

That person answers once, or records the video. It gets approved. It gets reindexed. Whoever asked gets notified.

From then on the answer is available to the whole team, permanently.

That's the full round trip back to the problem we started with: instead of the senior answering the same thing forty times, they answer it once and it stays written.

Sensitive data doesn't go through the RAG

This is the design decision I'm proudest of, and it's the opposite of what people expect.

The article could give the impression that everything goes into the same bucket. It doesn't. Employee records — salary, ID numbers, sick leave, disciplinary files — are deliberately kept outside the RAG.

The reason is simple: vector search works by similarity, and similarity sometimes gets it wrong. A coincidence in retrieval can surface a fragment that shouldn't have come up. With a payslip, that isn't an acceptable failure.

So that data travels a different route: direct lookup with permissions checked server-side, field by field. There's no room for a semantic coincidence to leak what it shouldn't.

On top of that sits isolation at two levels, which is what makes it possible to host several companies on one platform:

• By company. Each client gets its own isolation at database level, with PostgreSQL and Row-Level Security, plus its own vector collection in Qdrant.
• By department. Within each company, every area has its own space. Someone in support doesn't see what's in the leadership space.

The chat produces documents too

Minor on the face of it, but it's what separates a search box from an assistant.

You ask for the summary of a process in Word, the comparison in Excel, the procedure as a PDF, and it generates it from the company's real knowledge. With the sources inside it.

It stops being a place where you search and becomes a place where you produce.

What the dashboard answers

"Admin dashboard with metrics" says nothing. What matters are the three questions it answers:

• What gets asked that nobody can answer. It's the exact map of what your company still has to document, ranked by how many people need it.
• Which areas are documented and which aren't. Usually a whole department shows up with nothing written about it, and nobody knew.
• Who looked up what. Full audit trail.

That first point is, to me, the most valuable thing in the product. No company knows what it doesn't know. This tells them.

What makes a hundred-person company sign

"Designed to protect sensitive information" is a promise. These are facts:

• Full audit trail. Who consulted what and when, exportable.
• Two-factor authentication.
• Complete erasure under the right to be forgotten. When someone requests it, their data disappears from the system, vector indexes included. No residue left in a collection nobody remembers.

None of this sells a demo. But it's what gets asked in the meeting where the decision is made.

Who it's for

Agencies, consultancies and growing software companies, roughly 20 to 150 employees.

That size isn't an accident. Below 20 people everyone knows everyone and asking works. Above 150 there's usually already a team dedicated to documentation and process.

In between is the uncomfortable stretch. You're already too many for asking to scale. You're not yet enough to have someone dedicated to writing it down.

Rollout: 90 accompanied days

It isn't plug and play, and I'd rather frame that as what it is instead of as a warning.

It's 90 accompanied days: initial load, permission tuning by department, calibrating the threshold against real questions, and the first rounds of the loop. By the end of that period the system isn't answering with what you uploaded on day one — it's answering with what the team itself has filled in.

That accompaniment is part of the product, not an extra.

Why I'm the one building it

Two reasons.

The first is that I saw the problem at four different companies before I had anything to sell. I wrote about it in detail in the article about Slovenia.

The second is simpler: I was my own first customer. I had information spread across notes, chats, documents and my head. When a client asked me something about a project from six months earlier, finding the answer took longer than giving it.

I built the first version for myself. Then I saw it worked for others.

What it isn't

• It doesn't replace your team. It replaces the share of their time that goes into repeating the same thing.
• It doesn't guess. If the knowledge isn't in there, it says so and logs it as a gap. That's on purpose.
• It isn't a search box under another name. A search box finds what someone wrote. Savia also spots what nobody ever wrote and goes after it.

Where it is now

Savia is in active development. Backend in Python with FastAPI and PostgreSQL, vector collections in Qdrant, frontend in Next.js, React and Tailwind.

I combine this with freelance work. Everything I learn building the product ends up in client projects, and the other way round.

You can see it at saviaia.es. If your company has one or two people everyone depends on for the day-to-day questions, this was built for exactly that.