We work directly with the leaders who own AI and technology decisions
You're about to commit to an AI or technology decision and you want to know who you'd be working with. XONIK is a consulting, advisory, research and product firm, founded in 2006. Senior people do the work, scope is agreed in writing, and an engagement ends when a named person on your side runs what we built.
In brief
XONIK is a consulting, advisory, research and product firm, founded in 2006, that advises executive teams on AI and technology decisions and builds what those decisions need. For much of its history it delivered work under other firms' names. Today it works directly with the leaders who own the decisions, and senior people do the work.
On this page
Why did a firm that built for others start working under its own name?
XONIK was founded in 2006 and, for much of its history, delivered work under other firms' names. Agencies and consultancies held the client relationship and sold the engagement; we turned what they sold into something that ran. That work reached household names in publishing, property, telecoms, retail and regulated gaming, and the name on it was always someone else's.
Working behind another firm teaches you where projects actually fail. You inherit the gap between what was promised and what has to exist on launch day. You meet the scope that assumed the systems agreed when they didn't, the pilot that had a champion and no owner, and the approval that arrived with nobody assigned to carry it out. The logos on the slides changed from sector to sector. The failures stayed the same.
The catch is that behind someone else, you can repair the build but not the brief. By the time a problem reached the people doing the work, the decision that caused it had been made earlier by someone we'd never met. So we changed who we sit across from. Today we work directly with the leaders who own the decisions, and the work starts where the brief is written.
A decision is finished when a named person owns it.
What happens when the person deciding is in the room
The first conversation goes differently. We ask what's at stake, what has already been tried, and who will answer for the result a year from now. If the answer to that last question is nobody, that's the first thing to fix, and it costs less to fix before anything is built.
The terms don't change from one engagement to the next. Scope is agreed in writing before work begins: what's in, what's out, who has the final say, and how both sides will recognize finished. Every engagement runs under NDA. Senior people do the work, so the practitioner who scopes your problem carries it through.
The NDA also shapes how you can judge us. We can't give you client names or case studies, because the agreements we work under rule them out. What we can give you is our reasoning, in public: research that states its method and where it stops, field notes on problems that repeat, and free tools you can run yourself before you ever call.
What we've learned about how this work gets done
A pilot shows a model can do a task. It doesn't show anyone will depend on it.
Dependence needs an owner, an alert that reaches a person when the system drifts, and a fallback for when the model is wrong or switched off. Somebody has to build those on purpose, and that building is the work.
Technology fails at the seams between systems and between teams.
A record that reaches one system and never the other, a hand-off agreed in a meeting nobody minuted: these are ordinary, and they're where cost quietly piles up.
Governance has to sit inside the work, or it will sit in a binder.
A policy nobody can apply on a busy afternoon isn't a control. Tie each control to a system and to a person who answers for it.
Assistants and answer engines now help form your buyers' shortlist.
A business can be missing from the answer a buyer receives and never learn the question was asked.
A claim that cannot be checked is an opinion.
State the method, the limits and what would change the conclusion. A recommendation that can't be wrong can't be tested either.
How advisory, consulting, research and our own software fit together
- 01
Advisory comes first when the decision is still open.
A senior practitioner works beside the executive who has to decide, tests the plan against your systems and your organization, and writes down what to fund, what to leave alone and who owns each choice.
- 02
Consulting carries the decision into daily use.
The integration, the process change, the pilot that has to become a system. We write the scope first, the people who wrote it do the work, and it ends with a run book and a named owner.
- 03
Research answers what a brochure cannot.
How a technology behaves under your conditions, what a market is really doing, which supplier meets criteria fixed before the demos. Some research is commissioned. The rest we publish.
- 04
Products come from what keeps repeating.
When the same problem arrives in engagement after engagement and nothing handles it well, we build software for it. The products are in development, and each product page says how far along it is.
When are we the right call, and when are we not?
If a problem isn't ours to solve, we say so early. These situations show where the line sits.
We fit if
- A decision has been agreed and nobody has been made responsible for carrying it out.
- A pilot works and nobody can say who runs it once the project team moves on.
- Your systems disagree and the people closest to them each give a different explanation.
- You want an independent read before committing money, from someone with no stake in the answer.
- Your choice depends on evidence a supplier's materials can't supply.
Look elsewhere if
- The supplier is already chosen and you want the choice justified afterward.
- You want a document more than a changed operation.
- Your question is a legal, tax or audit opinion, which belongs with a qualified firm in that field.
- You'd rather manage a group of people than have senior practitioners do the work themselves.
- Nobody in your business has the authority to act on what we find.
This way of working costs you calendar time. We need access to the people nearest the problem, someone with authority at the table, and an account of the awkward parts of the project. If the cause turns out to be inside your own organization, the diagnosis will say so.
A composite example
The assistant that worked in the pilot and has no owner in production
Picture a telecoms operator that has piloted an assistant to draft replies for its customer service agents. The pilot team has moved on to the next initiative. The head of customer operations is being asked when it goes live, the security lead hasn't reviewed what the assistant can read, and the supplier's contract covered the pilot only.
A composite, not one client's story.
- Diagnosis. We map who would own the system, what it reads and writes, and what an agent does when it's wrong or unavailable. The head of customer operations and the security lead are both in the room.
- Scope. A written scope sets out what's in, what's out and who decides. It names the owner on the operator's side before anyone agrees to build.
- Build. A review step for replies the assistant is unsure of, a connection to the case system, a monitoring threshold that alerts a person, and a rule for what gets logged and for how long.
- Handover. A run book, a named owner in customer operations, and a date to review the first full cycle of real use.
Where it endsThe assistant is in daily use with a name beside it. Or the diagnosis shows it shouldn't go live, and the operator learns that before the money is committed.
How do you judge a firm whose clients you cannot call?
There's no reference call to offer, and a case study would break the agreement it described. What we can put in front of you is the method. Read a piece of our research and check whether it says how the finding was reached and where it stops. Run one of the free assessments and see whether the result tells you something you didn't already know.
Then ask us, on a first call, how we'd examine your problem, and listen for the reasons it happens rather than a list of services. If the answer is vague, tell us.
What do buyers ask when they check us out?
Why did you work under other firms' names for so long?
The agencies and consultancies we worked for held the client relationship and sold the engagement, and we made it run. That showed us where projects fail, but we could repair only the build, not the brief. So today we sit across from the leaders who own the decisions.
Who does the work on an engagement?
Senior people. The practitioner who scopes your problem carries it through. Scope is agreed in writing before work begins, covering what's in, what's out, who has the final say and how finished is recognized, and every engagement is under NDA.
You cannot name clients, so how do we judge you?
Judge the method, which we publish. Open a piece of research and look for how the finding was reached and where it stops, or run a free assessment and see if it tells you something new. Then ask how we'd examine your problem, and listen for reasons, not a service list.
When would you tell us you are not the right firm?
Early. We say so when the supplier is already chosen and you want the choice justified, when the question is a legal, tax or audit opinion, or when nobody in your business has the authority to act on what we find. We decide on fit, never on workload.
Leadership
Amit Govil
Founder and CEO
Amit founded XONIK in 2006 and has led its delivery since, across digital, technology and now AI work. He writes the firm's research and reviews its market briefings each quarter.
Read his researchCareers
Work with us.
If you're a senior practitioner who likes staying with a result until it works, we'd like to hear from you.
Our Careers page says what we look for and what to send, even when no role is listed.
See how we hireTalk to the people who would do the work.
Tell us what you're weighing and who has to live with the answer. A senior person reads it and writes back, so the first conversation is with someone who would do the work.