For twenty years, enterprise software almost always was a pure and simple system of record. Think CRM: put the deal in, associate the right contacts and companies, route them correctly, move them from one stage to the next, run simple calculations on them, make a few encoded transformations and hand it back when someone asks.
AI changed the ask. Companies do not want a system of record any more. They want a system of work. They want the software to label the deal correctly, work out who the buyer really is, know how to talk to that person, write the deck that fits, and decide whether an exception should be escalated or handled on the spot.
They want it to behave like a colleague. But nobody onboards it. Nobody tells it how things are done here. So it behaves exactly like a new joiner who was never trained: confident, plausible, and wrong, until someone puts it back on track.
That is why every company we talk to is suddenly mapping its processes and documenting everything it can. Everyone has worked out that the model is not the constraint, and the data warehouse is not the constraint. The constraint is context. What we have learned over the last 18 months of doing this is that context is not one problem. It is two. They are moving in opposite directions, and almost all of the money is going to the one that is the least valuable and being solved as we speak.
Written context and unwritten context
Written context is anything that already exists somewhere. Documents, tickets, code, schemas, transaction history, four years of Slack, the data model of the system you are replacing. It is scattered and often contradictory, but it is real. Someone can point at it.
Unwritten context only exists in a head. Why that exception was granted. Which check always happens before an approval, even though no policy asks for it. Which step of the official process everyone skips, and what breaks when a new joiner follows it. Where to look, what to read, what matters and what does not.
Every AI project needs both. And if we only focus on one, we will never get the full value of what AI could bring.
The written half is getting solved, fast
Two years ago, getting a model to see a company’s written material was a real engineering project. Parsing, chunking, embeddings, vector stores, reranking, evaluation. Teams staffed for it.
That changed quickly. A million tokens of context is now standard across the frontier. In March 2026, Anthropic dropped the long-context price premium, so a 900k-token request costs the same per token as a 9k one (The New Stack, 16 March 2026). The connector layer got standardized too. MCP now sits under the Linux Foundation, with AWS, Anthropic, Google, Microsoft and OpenAI on the same governance board. Retrieval itself got simpler, with agents that search live files instead of a pre-built index. Meanwhile Glean crossed $300M ARR, Databricks launched an ontology it calls a self-improving context layer, and Ali Ghodsi put the thesis on the keynote stage: “AI does not have an intelligence problem, it has a context problem.”
Hard cases remain. Extreme accuracy, very low latency, tight cost ceilings, strict repeatability: those still call for a specialized ingestion and retrieval pipeline, carefully engineered, with its own parsing and enrichment. We know, because we spent twelve months building one of the most capable on the market. It was worth doing, and I would do it again.
What I understood more recently is that this pipeline was never the goal. It is a prerequisite for the part that actually matters, which is capturing the unwritten half. You cannot work on the unwritten half until the written half is searchable and usable, and the how will keep evolving as the infrastructure and the harness layer evolve. It is because you can read the documents, walk through the IT systems and go back through Slack that you know which questions are worth asking in the first place to uncover what is in people’s heads.
So we will keep working on the best way to access relevant written context, but what changed in a year is this: reading written context is only the starting point for asking the right questions. Once done, you have not started the real work yet.
What “unwritten” actually looks like
The unwritten half shows up in every transformation project we see, and uncovering it is what decides whether the project succeeds or fails. A migration off a legacy backbone. An AI programme. A group absorbing a company it has just acquired. And, for almost every large manufacturer, the moment the age pyramid catches up with them, when they have two years to off-board their key experts and bring new hires to the same level before the business slows down.
A migration. A large logistics group, built through fifteen years of acquisitions, decides to standardize its financial reporting and roll out a single ERP everywhere. Every report, legacy system and data model is available. What is missing is the reason behind the settings. Each local parameter belongs to one of three categories. Some are mandatory, because of a local accounting norm or a tax rule. Some are operationally necessary, because that unit sells a different product, carries a different service commitment, or calculates margin differently for a good reason. And some are just small decisions that piled up over the years and no longer make any difference. Nobody has ever sorted them. The real work is recovering the principle behind each one, the why. Without it, you cannot design a data model that genuinely fits every unit rather than one that only suits headquarters. Now do that across thirty units, in their own languages and their own timezones, with ten to twenty people in each, resolving the gaps and the contradictions as you go.
An expert departure. An industrial manufacturer is losing senior experts to retirement, close to 10% of its workforce, within two years. There are hundreds of drawings, schematics and specifications. Almost every project passes through one of these people at some point, for one or two hard calls. The drawings record what was built. They do not record the judgment behind it: what to build for this customer, under this constraint, and all the failed configurations in a similar situation they tried in the past. And where this experiment was documented, it describes a configuration that no longer applies. So it does not simply need to be found. It needs to be told.
A process improvement. Talk to a few hundred people about how a process really runs and you find that the documented version is not wrong. It is just not what you would use to train a new joiner on the actual work. There is always an edge case. There is always a workaround. And there are often several versions of the truth, depending on who you asked.
Take something everyone knows. A customer wants to return a product and get their money back. On paper the rule is simple: thirty days, a receipt, the original packaging. In practice, an experienced person on the returns desk will approve a refund at day forty for one of the company’s largest accounts, when the photo shows the item was damaged in transit, because the cost will be recovered from the carrier and because a good experience for that account matters far more. That can look like a simple rule to encode. But how many times is it never written down? And how many more nuanced variations of it will you find when you sit with each experienced colleague?
People absorb that kind of imprecision without noticing. Software does not. Give an AI the written policy and it will refuse the refund, miss the deadline to claim from the carrier, and upset a major customer, all while following the rules perfectly. If you want AI to run part of a process, a precise map is not enough. You need to know where the risk sits, which handovers are critical, and what makes one of them safe enough to run without a person. That usually depends on the conditions on the day. Without it, you never really take people out of the loop. And it is not something you do once. Going from a system of record to a system of work requires continuous knowledge transfer, because the conditions, the exceptions and the judgment behind them keep moving.
The bottleneck is the person who turns the work into something buildable
Watch who is being hired. Forward-deployed engineering postings were up roughly 729% year over year by April 2026, according to Indeed. Between May and July, four of the largest technology companies in the world put deployment capacity on their balance sheets: the OpenAI Deployment Company at $4B, Microsoft Frontier at $2.5B and 6,000 engineers, AWS at $1B, and Ode with Anthropic at $1.5B. Anthropic now has a Head of Forward Deployed Engineering for the Americas. That title barely existed outside Palantir a few years ago. The same person exists inside the enterprise under other names: transformation lead, technical program manager, process automation manager, deployment strategist, and increasingly whoever runs the internal AI enablement team.
AI coding tools made building the thing much cheaper. Working out what to build is going the other way. It is becoming exponentially more expensive, because the systems we ask for now depend on far more of a company’s operating reality than a system of record ever did. That is what deployment strategists and FDEs are for. Understanding what a work process really is means sitting with the people who run it, many times over. Then it means having enough synthesis and abstraction to model it at the right level of detail, and to consolidate what matters into the forms the rest of the project can actually use.
I have done this work. So has Louis-Philippe, my co-founder, at Dataiku, long before anyone called it forward-deployed engineering :)
Everyone who has done it knows how little of it is glamorous.
The calendar. Forty people, five departments, three countries, two timezones. Thirty minutes each, twice. Most of the effort goes into chasing everyone for a slot that works, and getting them in a room, sometimes, at the same time.
The follow-up. The good interview is never the first one. It is the second, the third and the fourth, and those are the ones you never manage to schedule.
Knowing what to ask. When you are not ten years into the job yourself, working out which questions matter is very hard. Ask a weak one and you lose their trust. Try to read everything first and you drown before you get there.
The contradiction. Two experts disagree. First you have to remember that it happened, then find both versions in your notes. Then you discover that asking who is right is usually the wrong question, because both of them are, under different conditions. And you are back in the calendar.
The granularity. Too shallow and the output is a diagram nobody can build from. Too deep on one process and you run out of time for the other eleven, or for getting any of it validated.
The consolidation. Thousands of pages of documents and transcripts, turned into one coherent model, while catching what nobody thought to mention. As a human job, at that volume, it is not hard. It is impossible.
Now picture ten of you running the programme, with hundreds of people to interview and dozens of sites to visit.
Who we are building for
After months of iterating with tens of clients, hundreds of active users and as many processes mapped end to end, we know exactly who this is for. We build the software that accelerates transformation from end to end, and we cut what it takes to run one of these projects by tenfold, sometimes more. Faster, and also more accurate and more granular than the manual version ever was.
That is what Clarifeye is: the software you run your transformation project on. It takes in the written context and uses it to work out what matters, which dimensions you need to grasp, what is missing and where the contradictions sit. It helps you prepare and run the interviews that are actually worth running with your experts. Then it consolidates everything into what the project needs: the process maps, the ontology, the data models, the playbooks, and the wikis and SOPs. Use it to build and deploy what you need. Scope the right tests, run them. Iterate. Continuously. Always. All of that in a versioned, fully traceable environment, where every statement traces back to who said it and where it came from. Live, portable and reusable.
It is built for teams. It is fully customizable, because you want your own expertise and your own way of running an engagement encoded in it. It is collaborative. And it is AI native.
Over the next few weeks I will go through each step of that in detail. In the meantime, if you are a deployment strategist, a technical program manager, a consultant running an ERP migration, or the person accountable for transformation inside your company, we are building this for you. Come and talk to us.