We built Qonverge because we had the problem ourselves. A consulting business runs on one repeating question: who is available, and which of them actually fits the assignment on the table this week? We answered it the way most firms do, with spreadsheets, inbox archaeology, and the memory of whoever had been there longest. That works until it doesn't, and it stops working precisely when the business grows.
Qonverge is the system we built to answer that question properly. It is an AI talent matching platform for consulting firms, sourcing companies, HR teams, and recruiters, and it now runs as a product other companies can use. The live product sits at qonverge.se. This note is about how it was built, what we ruled out, and where it currently stands.
The problem: talent matching is a data problem, not a database problem
Every firm we know already owns the data needed to staff an assignment well. The trouble is the shape of it. Assignment briefs arrive as prose in an email. CVs arrive as documents in a dozen layouts. A consultant's real ambitions live in a conversation someone had six months ago and never wrote down. Availability changes weekly.
Search does not fix this. Keyword and boolean filters match strings, not meaning, so a requirement for "distributed systems experience" misses the engineer whose CV says "built the event pipeline that handles our order flow". Firms compensate by asking humans to re-read everything, which is slow, inconsistent between reviewers, and quietly biased toward whoever is most recently memorable.
So the actual engineering problem is turning unstructured demand and unstructured supply into structured, comparable representations, then keeping both current as they change. Three jobs follow from that:
- Understanding needs. Client assignments, recruitment requests, and internal HR reorganisations, read and converted into explicit requirements.
- Mapping talent. Consultants looking for their next assignment and employees looking to grow, represented by skills, trajectory, and availability rather than by job title.
- Binding supply to demand. Matching profiles to requirements, generating leads for consultants on the bench, and searching the wider market when the right person is not in house.
What we built
The platform is organised around those three jobs rather than around screens. Needs understanding parses a brief into structured requirements, including the ones stated only implicitly. Talent mapping builds and maintains a profile representation for each person. The matching layer performs profile to requirement alignment and scores candidates against a specific need, with the reasoning attached to the score.
On top of that sits the piece that surprised us most in daily use: an AI call assistant. It supports recruiters by handling technical questions, running candidate phone interviews, testing technical knowledge, assessing fit, and collecting salary expectations. The value is not that it replaces the recruiter conversation. It is that the first conversation happens at all, for every candidate, instead of for the first six a human had time to call.
What we ruled out, and why
Three decisions shaped the build more than any feature did.
We ruled out one large hosted model doing everything end to end. It is the fastest way to a demo and the worst way to run a business on someone else's terms. Talent data is commercially sensitive, the workload is continuous rather than bursty, and a pricing or deprecation change upstream would land directly on our unit economics. This is the same argument we make for clients in our reference architecture for sovereign ML, and it would have been dishonest to build our own product the other way.
We ruled out opaque scoring. A number with no explanation is useless to a recruiter who has to justify a shortlist, and worse than useless under scrutiny. Employment and recruitment are a sensitive context under the EU AI Act, so every match carries the reasoning behind it, and a human makes the decision. We wrote about turning that regulation into concrete engineering work in turning the EU AI Act into engineering tickets.
We ruled out treating candidate data casually. CVs, interview recordings, and salary expectations are personal data of the most sensitive commercial kind. Data residency, retention, and the right to erasure were architecture decisions taken at the start, not features added when a customer's procurement team asked.
Where the AI call assistant stops
We drew one line hard. The assistant gathers and structures information. It does not decide who progresses. Candidates know they are speaking to an automated assistant, the transcript belongs to the process, and a recruiter reviews the output before anything happens. An automated system that quietly filtered people out of a career opportunity is not a product we would want to run, and under the EU AI Act it is not a product anyone should want to run.
Why we run it on infrastructure we control
Qonverge runs on infrastructure we operate, under EU jurisdiction, on an open weight stack wherever the workload allows. That is not a marketing position. It is the direct consequence of the ruling out above: if the matching logic is ours, the weights are ours, and the data never leaves the perimeter, then the cost of a provider changing their terms is a migration rather than a rebuild.
It also means we are running the architecture we recommend. When we tell a client that production machine learning should be portable, auditable, and operable by their own team, Qonverge is the system we point at.
Who is using it
Qonverge is live and running in production for consulting firms in Sweden. Two of them agreed to be named and quoted.
Qonverge gave us the horsepower of an entire resourcing team without the overhead. We can finally focus on clients instead of inbox triage.
With Qonverge we don't waste time searching for assignments or preparing applications. It automatically matches our consultants to the right opportunities, letting us focus on delivering value.
What we still cannot tell you
Both quotes describe a change those teams feel day to day. Neither is a measurement, and we are not going to present them as one. What we do not have yet is a verified production number worth publishing.
We publish numbers measured against production data, or we publish none.
We could estimate a time saving per assignment. We are not going to, because an estimate presented as a result is the thing we criticise other firms for, and the rules we publish by say a project stays a work note until it can carry a name and a verified number. We have the names. The number is the part still missing.
Three things are worth measuring here, and they are what we are instrumenting for: time from assignment brief to shortlist, how much of the available bench a search actually surfaces, and how often a matched candidate is the one eventually placed. When those have run long enough on production data to mean something, this note becomes a case study and the method will be stated alongside the numbers.
Until then, this is what it is: a description of how we built a talent matching platform, in production at named companies, and the reasoning we would apply to your system too. If you are weighing something similar, the ML Feasibility Sprint is two weeks and a fixed price, and it ends in an honest answer about whether the machine learning is worth building at all.