I'm not saying that's wrong. In fact, today's generative models are perfectly capable of handling many of these tasks, and they come with fairly powerful structured-output mechanisms. But there's a question I think is worth asking: does it make sense to use a model designed to generate language when all we need is to make a decision among known options?

That's precisely the proposition behind Jev, the first public model from a new family that TypeSafe calls System One Models. Other posts about Jev have already been written, but in this one, besides explaining what it is and why I find it interesting from a software architecture point of view, I'm also sharing, as usual, a repository with a small PoC so you can play with Jev yourself.

What is Jev? Where does it come from and who's behind it?

On September 15, 2026, TypeSafe AI introduced Jev, the first public model in its System One Models family.

The company is led by Diogo Almeida, TypeSafe's founder and a former OpenAI researcher. The starting idea, laid out in the launch announcement, is fairly simple: generative models have reached an extraordinary level at conversing, writing, coding and reasoning, but a good part of enterprise automation needs decisions that other programs can consume, not text that a person has to interpret.
That gives rise to a different proposal: building specialized models that take a context and answer well-defined questions through typed outputs.

The name System One refers to System 1 as described by Daniel Kahneman in Thinking, Fast and Slow: a fast, intuitive way of thinking, as opposed to the more deliberate System 2. The reference helps explain TypeSafe's intent, but it doesn't mean Jev literally reproduces how human cognition works.

And why Jev? According to TypeSafe, the name is a tribute to William Stanley Jevons, known, among other things, for the paradox that bears his name: when a technology becomes more efficient, its total consumption can go up instead of down. Applied to AI, the hypothesis is that making each decision radically cheaper will let us bring intelligence into many more processes.

I think this last idea is especially interesting: it may not be only about replacing an LLM with something cheaper, but about making viable decisions we don't even consider automating today.

What are its key features?

To understand Jev, you need to shift your mindset slightly. Instead of asking it to "read this text and answer with a JSON," we define two elements:

• state: the context we want to decide on. It can contain text or a data structure.
• questions: the questions it has to resolve, with the answer type and the criteria defined beforehand.

The application sets the space of possible answers; Jev evaluates the context and returns its decisions.

Three primitives: Choice, Score and Noul

The System One interface is built around three primitives:

You can review the behavior and output fields in the official System One documentation. One important detail: Noul is not simply a boolean, but a numeric signal that we can interpret using a threshold defined by our application. Likewise, a Score can be continuous, even if the criteria are organized in levels.

Multiple decisions in a single call

Another especially useful feature is the ability to ask several questions about the same context. Imagine we receive this alert:

The payments service is down for all customers. The logs show database connection pool exhaustion and there are no signs of unauthorized access.

In a single request, we could ask for the priority (a Score from 0 to 4), the security risk (a Noul) and the responsible team (a Choice among BACKEND, PLATFORM and SECURITY). The result would look something like this (a conceptual example, not a real API response):

{
  "priority": 4,
  "security_risk": 0.03,
  "team": "BACKEND"
}

In other words, we don't need three calls or an explanatory text to get all three decisions. The code that consumes the result can determine what to do next.

Typed responses, uncertainty and efficiency

TypeSafe puts the spotlight on three other characteristics:

• A known output contract: the questions and their valid values are defined in advance. This reduces the integration problems that come from receiving responses that don't respect the contract.
• Uncertainty signals: depending on the primitive, the model provides probabilistic values, distributions or confidence. These are not guarantees of correctness and need to be validated with real data.
• Optimized for decisions: Jev doesn't write out an explanation word by word. According to its creators, this difference substantially reduces cost and response time on the tasks it's designed for.

In its official launch post, TypeSafe reported indicative latencies of 70 to 500 ms and a public price of USD 0.042 per million input tokens, with no charge for output tokens. These are figures published by the vendor, not a promise of performance in every environment or a contractually guaranteed rate. Check the current terms before budgeting.

One last nuance: guaranteeing that a response respects the schema doesn't mean guaranteeing the decision is correct. A classifier can perfectly well return BILLING when the category we expected was OTHER.

How is it different from a traditional LLM?

A generative LLM is designed to produce content. Jev is designed to issue bounded decisions that other software can use directly.

This doesn't mean Claude, GPT or Gemini can't return structured results. They can, through tools, function calling or output schemas. The difference lies in the model's native goal and its interaction interface, not in the impossibility of getting JSON out of an LLM.

With an LLM, the response space is potentially open, even though, as I said, you can try to constrain it. With Jev, the response space is already defined by the questions themselves. Also, something we need to keep in mind is that Jev won't generate an explanation of its reasoning. An LLM can tell you what led it to that answer, and even point to the supporting quotes.

The main idea to keep in mind is that Jev doesn't have to compete head-on with LLMs or replace them. In a real architecture, the two can be perfectly complementary.

For example, an LLM can design a solution, draft a response or synthesize a document, while Jev can decide which flow to run, which category something belongs to, or whether an operation should be escalated to human review.

This echoes a fairly classic architecture principle: use each component for what it does best, and avoid adding capabilities the problem doesn't need. Heads-up: whenever we can use deterministic mechanisms, we should always go with them. They're simpler to implement, debug, test and deploy.

For which use cases can it be a good alternative to an LLM?

I think where it really has potential is in scenarios that meet conditions like these:

• They have lots of events or inputs
• They need repeatable decisions
• They have a known response space
• The goal is to reduce cost or latency.

Within those constraints we find cases like:

• Classification and routing: for example, determining whether an email is about billing, support or sales; sending tickets to the right team; classifying requests; or deciding which generative model to use for each task.
• Scoring and prioritization: for example, rating how mature a sales opportunity is, ranking incidents by impact and urgency, or identifying requests that deserve priority review.
• Semantic guardrails: for example, detecting whether an instruction seems to be trying to bypass an approval or break a rule expressed in natural language. The detection would be an additional signal; it doesn't replace deterministic security controls.
• Content verification and agent flows: for example, assessing whether a response meets certain criteria or should be escalated to a human; adding bounded decision points within broader flows.
• Multiple decisions on the same event: for example, when an incident comes in, determining priority, security risk and responsible team all at once.

From my architect's point of view, it's essentially a semantic decision component/service that lives alongside business rules, APIs, events and generative models. It's needed in scenarios where a conventional if/else falls short but a full LLM feels like overkill.

That said, it doesn't replace deterministic rules when we can fully express and verify the decision in code.

When might it not be a good fit?

Sometimes, when we analyze a new technology, we focus so much on its advantages that we stop looking at the other side. In this case, I think it pays to be especially careful. For example:

• Content generation
• Explainability requirements
• Sovereignty and control

Let's look at these scenarios in more detail.

Content generation

We need to be clear that Jev is not a generative model. So if we need to write a report, develop an architecture, explain technical alternatives, write code, summarize a document or hold a conversation, Jev is not the right model to produce that artifact.

It could take part in decisions within the flow, but generation would still be up to an LLM or another specialized system.

Explainability is a must

Jev doesn't provide an explanation of why it chose a category or assigned a score. We can get signals associated with the decision, but not a verifiable description of its internal reasoning.

Think of an email that Jev classifies as BILLING when an analyst would consider it OTHER. We can see what it returned and compare it with the expected label. What we can't do is ask it to spell out its internal reasons for picking that option.

Explainability in AI is a very important requirement in certain contexts, so it's a point to weigh carefully.

An alternative: Jev decides and an LLM explains

We can set up a hybrid architecture:

1. Jev makes the decision based on the available context.
2. The application returns that decision to the consumer.
3. An event is published or a task is queued, identified by the decision ID.
4. A low-cost generative model, such as Claude Haiku, receives the context, the decision and the available signals, and writes a justification based on the evidence in the text.
5. The explanation is stored alongside the decision for later consultation.

This hybrid model only works if the explanation isn't needed to move forward, since we can generate it asynchronously and keep the second model's latency off the critical path. In this case, we don't eliminate the explanation's latency, we decouple it from the decision's latency. On the other hand, we take on extra cost, an additional dependency and the need to manage queues, retries and errors.

Heads-up, there's an even more important limitation: the justification written by the LLM (e.g., Haiku) would be a post-hoc explanation, not Jev's internal reasoning. It can be useful for interpreting the evidence and making review easier, but it could also construct an argument that isn't faithful to the real reason behind the prediction.

That's why, in regulated or critical processes that demand an explanation validated before acting, we can't simply push it to the background and consider the requirement met.

When we need absolute control over deployment or data sovereignty

As I mentioned earlier, as of this writing, if we need to run the model without external connectivity, inside our own infrastructure or in a specific contractual location that TypeSafe can't offer, Jev may not meet the requirements, no matter how well it classifies.

Let's talk maturity: is it ready for production?

Jev is a very recent product: its public launch happened in September 2026. Obviously, we're not talking about a technology with years of widespread adoption, but about a proposal that's evolving fast.

That doesn't mean it can't be used in production. TypeSafe has already published the Jack & Jill case, a hiring platform that, by its own account, replaced a Gemini model with Jev in a candidate matching stage. The case reports 88% lower cost and shorter processing time while maintaining comparable quality on that task. It's a customer case published by the vendor: interesting as a reference, but it isn't an independent certification, and it doesn't mean those savings carry over to other systems.

TypeSafe keeps releasing versions and features. For example, in the Jev 1.14 announcement, it distinguishes the capabilities it considers sufficiently proven from experimental ones, such as certain multimodal or extended-context options.

But does it come with enterprise support?

There's a nuance here that I think deserves its own section, especially if we're thinking about bringing Jev into a large and/or very traditional company.

We can't say that TypeSafe has no enterprise support, since it has a dedicated enterprise page with a sales contact, the ability to request higher usage limits, and references to options like zero data retention. However, having a sales channel is not the same as having all the enterprise guarantees confirmed that we'd demand before a critical adoption:

• Contractual SLA
• 24×7 support
• Incident response times
• Private deployment
• Specific compliance
• Portability
• Continuity commitments

It's true that TypeSafe is moving in this direction. In the announcement of its funding round on October 9, 2026, TypeSafe explicitly says it will add more enterprise features. That's a positive sign of investment and product direction, but it also indicates that the offering is still evolving and that they know there's some maturity missing for an enterprise product.

In my opinion, right now, in an enterprise context, I'd use Jev without too many reservations in a controlled PoC, but I'd make the move to critical production conditional on a commercial, legal, security and operations review. It's not enough for the model to be fast and to get our dataset right.

If the service goes down on a Saturday night, who do we call? What recovery time are we guaranteed? What do we do if the API terms change? What data can they process, and in which region? Those answers need to be in writing, not inferred from a marketing page.

My take is that Jev deserves to be evaluated for production in bounded cases, but it requires special attention to its operational maturity and contractual guarantees. Before adopting it for a critical function, I'd review at least the following:

• Quality on our domain: a representative dataset, reviewed labels, and tests with ambiguous and out-of-distribution inputs.
• Versioning: pin versions when stability matters and rerun evaluations before migrating.
• Failure behavior: timeouts, rate limits, circuit breakers and fallbacks.
• Security and privacy: classification of the data we send, residency, retention and data processing agreements.
• Observability: latency, costs, technical errors, decision errors and trends over time.
• Business control: thresholds, human approvals and deterministic rules before risky actions.
• Vendor guarantees: SLA, support, limits and service continuity.

It's worth remembering that a probabilistic decision should never automatically become an authorization. If Jev says an action looks safe, our system is still responsible for checking permissions, policies and constraints.

Another important point: is it available as a native model from the big providers?

As of this writing, I haven't found official documentation confirming Jev as a selectable, natively managed model on Amazon, Google or Azure… So I wouldn't present it as a capability available on those platforms.

If an organization wants to use it from one of those clouds, the scenario backed by public documentation is consuming the TypeSafe API from the application. Any specific private deployment or third-party distribution agreement needs to be confirmed with the vendor.

Can it run locally?

I haven't found that it can run locally either. This limitation matters for organizations with strict isolation, data sovereignty or fully on-premises deployment requirements.

In short: we can develop and deploy our software wherever we want, but Jev's inference, according to the documented public offering, depends on TypeSafe's service.

What if we didn't really need Jev?

Text classification, scoring and anomaly detection existed long before ChatGPT. So depending on the context, we may need neither Jev nor an LLM. Take the email classification case. A classic alternative would be training a supervised model on labeled messages. We can start with TF-IDF and logistic regression, move on to an SVM, combine embeddings with a classifier, or fine-tune an encoder model like ModernBERT. They don't all require the same amount of data, hardware or operational effort.

Another option is managed solutions: Amazon Comprehend Custom Classification lets you train classifiers with your own categories, and Google Cloud Document AI Custom Classifier offers document classification options, from pretrained models to custom training. In the open source world, approaches like SetFit let you fine-tune classifiers with relatively few examples and embedding models.

So the comparison shouldn't be limited to Jev versus an LLM:

There's no universal winner. If we have millions of well-labeled historical emails and the classes barely change, a specialized classifier deployed on our own infrastructure could be an excellent option. If, on the other hand, we're exploring a new process, have few labels and need to change the criteria often, Jev can greatly reduce the initial friction.

It also wouldn't be right to claim that traditional ML is necessarily slower to develop or more expensive to run in every scenario. AutoML tools, pretrained models and few-shot approaches have lowered that barrier a lot. And there are supervised models that let you inspect which variables influenced a prediction, although that alone doesn't guarantee a causal explanation either.

As I said earlier, we should always remember the architecture principle of using each component for what it does best. In this era of big, fast-moving change, architecture work when designing solutions matters more than ever: what do we really need? A traditional classifier trained on our data, an LLM with structured output, or a decisions API like Jev or Decisions API?

The answer will depend on quality, cost, latency, explainability, privacy, maturity and deployment options.

Is the industry reacting?

The industry is moving toward increasingly structured outputs, smaller models and specialized services, although not everyone is taking the same path.

Laya, the open source competitor

Another project worth knowing about is Laya, driven by Convai Innovations. Its approach is very similar to Jev's: making semantic decisions about a context through bounded questions, instead of generating free text. In fact, it uses the same primitives: Choice, Score and Noul, and it can resolve several questions in a single evaluation.

The most interesting difference is the distribution model. Laya is an open source project, with publicly available code and weights and an Apache 2.0 license declared in its repository. That means you can download the model and run it locally, inside a Docker container or on your own infrastructure, rather than necessarily depending on an external inference service.

From an enterprise, control and sovereignty standpoint, this can matter quite a bit, since we can control where data is processed, which version we run and how we integrate the model. Picture an insurer that needs to classify documents or prioritize incidents and can't send certain data to a third-party API. Laya opens up the possibility of deploying that component within its own network boundaries.

But this isn't "free," because open source doesn't equal an enterprise-ready production solution. Like any other deployment, we have to account for and analyze the costs of infrastructure, energy, staff and so on; manage capacity, scaling and monitoring; and maintain the model and any new versions of it. Operational responsibility and support fall on the company itself, and since it's an open source project, we have no enterprise support and no guarantee that it will be maintained over time (though it could be interesting to take part as contributors).

We also shouldn't forget decision quality. We'd need to test its results against our own dataset, including ambiguous texts, different languages, category distributions and cases where escalating to human review makes sense. Accuracy, calibration and error behavior matter more than whether it's open or proprietary.

In my opinion, Laya makes a lot of sense as a candidate for PoCs and for scenarios where local execution is a requirement, but for critical production I'd demand the same rigor as with Jev: representative testing, continuity guarantees, security controls and a clear support model.

OpenAI's Decisions API and GPT-6 Luna

According to OpenAI's official changelog, the Decisions API launched in beta on October 6, 2026, with the gpt-6-luna model. Decisions API is a dedicated interface for evaluating inputs and returning typed decisions, with bounded questions. Its approach is much closer to TypeSafe's System One.

The correspondence between concepts is striking, and the way you call it is similar to System One: you specify the model, the inputs and the questions/instructions. Both offerings let you work with bounded decisions and multiple questions about a context. OpenAI's documentation also describes decisions over text and images, and probability or confidence signals for certain types of answers.

OpenAI claims this API can be roughly ten times faster than using its Responses API for this kind of task. It's important to read that number correctly: it's a comparison published by OpenAI against another of its own APIs, not an independent measurement against Jev. Nor can we conclude from it that Luna is more accurate, faster or cheaper than Jev in our specific scenario.

Hands-on: Jev Decision Lab

As usual in my posts, I try not to leave things at the purely theoretical level, and I always try to back them up with something "practical."

In this case, I've put together the Jev Decision Lab repository. It's a PoC that compares Jev with Claude Haiku and Claude Sonnet on a set of situations where we can measure results. I've also included Laya so you can run it locally.

It's not meant to be a universal benchmark or to prove that Jev always wins. Its goal is to let you play with it and see when a bounded decision can be handled without a general-purpose generative model, and what happens to quality, cost and response time.

To make the PoC more guided and easy to use, I've included a series of use cases where the comparison makes sense:

The PoC also has two modes of use:

• Playground, where we can enter our own text, select providers and compare a single run.
• Test Scenarios, where we can run repeated batches against a reference dataset. The version of the project I use includes 30 scenarios per use case (210 in total), lets you select providers, repeat the tests and upload your own JSON dataset, which is validated before the process starts.

The repository has a README with the full instructions, a description of the use cases and implementation details.

Important: the dataset labels are examples prepared for the PoC, not an independently reviewed set. A 95% match with these labels doesn't equal "95% accuracy in production." Costs are estimates, and performance also depends on the network and on external services.

Conclusions

After reviewing TypeSafe's proposal and building the PoC, I'm left with a few takeaways.

• Generation isn't always required: as tends to happen with hype, we've normalized using LLMs for any natural language input, but some problems have a result that is simply a decision among known options. It's worth telling the two scenarios apart.
• Latency and cost are potential advantages, but you need to review the whole scenario: the figures published by TypeSafe are eye-catching and justify giving it a try, but the architecture decision has to rest on the scenario's requirements, on the dataset we actually handle, on latencies and on our required quality criteria.
• Explainability is a key factor in the decision: we can ask another model to write a justification, even asynchronously, but that doesn't turn the explanation into Jev's verifiable reasoning. In certain contexts, this difference is the "go" or "no-go" for Jev.
• Maturity, support and deployment model (and sovereignty) count in an enterprise environment: it's true that there are already real production cases with Jev, but it's a recent tool that depends on TypeSafe's offering. For organizations with strict sovereignty, operations or continuity requirements, the analysis doesn't end at model accuracy or the features listed by the vendor on its website. It also takes solid enterprise-grade capabilities.
• Let's not forget other alternatives like traditional ML: a good supervised classifier, or even conventional rules, may be the most reasonable solution. Before adding another API, we should measure those options too.

So instead of making our first question when designing a solution "which LLM do we use to solve this problem?", we should start by asking "what kind of intelligence does this problem really need?". If we need to generate, explain or design, an LLM makes a lot of sense. If we need to classify, prioritize or decide within defined limits, proposals like Jev open up an alternative worth exploring. And if the set is predictable and very well defined, let's go with deterministic solutions.

We open up the black box of AI to revisit four cases that show its limitations: from a chatbot that seemed to understand human emotions to algorithms capable of amplifying financial chaos or reproducing social prejudice.

1 ELIZA, the chatbot that seemed to understand us (but didn't)

In 1966, MIT researcher Joseph Weizenbaum created ELIZA, one of the first programs capable of holding a conversation. Its trick was simple: it rephrased users' sentences and answered with questions, without actually understanding what they were telling it.

Despite its limitations, some people came to trust it and share their personal problems with it. That's how the so-called ELIZA effect was born: our tendency to attribute intelligence and empathy to a machine just because it responds convincingly.

The lesson still holds: an AI seeming to understand us doesn't mean it actually does.

2 A medical algorithm that mistook asthma for an advantage

An AI system designed to predict mortality risk in pneumonia patients found that those who also had asthma had better outcomes. The problem is that it read that correlation as if asthma were a protective factor, without accounting for the fact that these patients might receive more intensive medical care.

The algorithm spotted a pattern in the data, but it didn't grasp the context that explained it. This case shows that correlation doesn't imply causation and that, especially in medicine, an AI's recommendations need to be carefully evaluated before being applied.

3 Flash Crash: the algorithms that amplified financial panic in the US

On May 6, 2010, US financial markets suffered a sudden and extreme drop. The interaction between large sell orders and automated trading systems helped intensify the plunge, as prices swung at a speed that human traders struggled to handle.

The episode, known as the Flash Crash, showed that automation can amplify unexpected movements when several systems interact without sufficient controls. Speed is an advantage, but it can also multiply the consequences of a mistake.

4 COMPAS, the judicial algorithm that inherited our prejudices

In the United States, the COMPAS system has been used to assess the risk of reoffending among people accused of crimes and to support certain judicial decisions.

In 2016, a ProPublica investigation found significant racial differences in its prediction errors: Black defendants were more likely to be wrongly classified as high risk.

The case opened a debate about algorithmic bias and the supposed neutrality of mathematics. If an AI learns from historical data that reflects inequalities, it can reproduce them and give them an air of objectivity.

What do these mistakes teach us?

Although they come from very different fields, all four cases share the same warning: artificial intelligence is neither infallible nor necessarily objective.

Algorithms can mistake correlations for causes, learn from biased data or set off unforeseen consequences. That's why developing AI solutions isn't only about getting them to work, but also about understanding their limitations, evaluating their results and putting oversight mechanisms in place.

There is no universally winning chunking strategy. Performance varies significantly with the domain, the structure of the text and the embedding model we use. So optimizing this stage isn't a trivial piece of initial setup, but an ongoing audit process.

The biggest risk is "blind truncation," a silent phenomenon where chunks exceed the model's window and get cut off during vectorization, degrading search without raising a single error. Auditing this behavior and measuring answer relevance with real queries is essential.

This process is a necessary investment of time and analysis that makes sure your system isn't capping its own potential right from the indexing phase.

The problem? You've never measured your splitter

You've probably seen this line of code, or one very much like it. It's in the repository of almost every RAG that has been in production for a while:

splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)

That line determines how each document is split before indexing and sets the size of the segments. It's a crucial setting: a RAG system doesn't retrieve whole documents, it retrieves chunks, so the quality of its answers depends directly on how it makes those cuts.

Those thousand characters and two hundred of overlap are usually inherited from the tutorial you followed when you started the project (and you know it!). Surprising as it may sound, I'm not going to criticize using that default. A well-tuned recursive splitter is hard to beat, something backed even by sources that would stand to gain from claiming otherwise, as I'll show below with hard data.

The enemy of chunking is something else, and it's far more uncomfortable: having picked that configuration once and never measured it.

One of the decisions with the biggest impact on answer quality is usually made by default, by replicating external configurations without any prior evaluation. The most common symptom is reacting to retrieval failures by swapping the splitter for a more complex algorithm, without first quantifying its real impact.

My position is that chunking isn't an architecture decision you make on day one. It's a parameter you measure against your own documents.

That's why this article won't give you a recommended chunk_size. It will show you how to measure yours. The failure isn't one of strategy or method. It's a failure of measurement.

Oh, and if you think RAG is dead, check out another post where we discuss exactly that.

Fixed windows: a surprisingly robust strategy

Recursive splitting with a fixed window and overlap can look like a very basic, beginner-level strategy, but it works. In 2024, Chroma published an evaluation of chunking strategies across five text collections (Smith & Troynikov, 2024). Curiously, the most-quoted result from that report is exactly the one that was least convenient for them.

Recursive chunking at 200 tokens achieved 88.1% recall. Surprisingly, Chroma's own semantic chunker comes in at 87.3%.

Worth pausing on: the study was done by a company that sells vector databases, and its results tell us that the tried-and-true heuristic retrieves slightly more than the sophisticated chunker the company itself proposes.

The authors' conclusion is the full concession: simple heuristics work well in practice when they're properly tuned.

There's a second, less-cited but decisive point to keep in mind. Evaluating chunking rigorously goes far beyond changing a parameter and checking that the demo still answers. The traditional standard calls for building a dataset (ground truth) on your own corpus, which is costly and hard to scale, but it isn't the only way. Today there are alternatives validated in the literature: from automated synthesis of test cases (Ragas, ARES), to isolated analysis of the retriever using classic information retrieval metrics like Hit Rate, MRR or NDCG (BEIR benchmark), to auditing contextual relevance with the LLM-as-a-judge paradigm.

Also, and this is an opinion with no data behind it, chunking is perceived as plumbing that comes before the interesting work. It gets dispatched in the first week of the project so the team can move on to prompt engineering, re-ranking or agentic systems as soon as possible.

Four strategies, one document: which one wins and what each one breaks

Let's use a simple analysis as an example, a toy exercise to illustrate the concepts. We're not trying to do deep research here, but to show the practical steps for evaluating our chunking and how some often-ignored factors affect answer quality.

I applied four chunking strategies to a single document: an internal policy on "Days off, vacation and absences.pdf" from Paradigma Digital. It has 9 pages and 18,638 characters, with headings, FAQs and numbered lists. The classic document at any company.

The document is internal, so I'll only publish the numbers and the cuts, not the text. The model used for the test is paraphrase-multilingual-MiniLM-L12-v2 (with a maximum sequence length of 128 tokens).

When evaluating how to chunk a document, we run into four main approaches, each with a different balance of cost, predictability and contextual coherence. As Figure 1 shows, these strategies produce very different size ranges on the same document, which directly shapes retrieval effectiveness:

• Fixed window: the cheapest and most predictable option. Because it splits on a rigid count, it ignores sentence structure. Its robustness depends almost entirely on overlap to recover context between chunks.
• Recursive: implements a hierarchy of separators (paragraphs, sentences, characters). This is, apparently, a notable improvement over fixed windows, since it tries to respect the logic of the text, producing more consistent chunks and a "cleaner" split that starts at the beginning of paragraphs.
• Structural: takes advantage of syntax (titles, headings) to extract units that make complete sense. It's extremely effective when extraction is accurate, but highly dependent on parser quality. Any typo can turn a stray line into a false heading, breaking the coherence of the blocks.
• Semantic: the most sophisticated, grouping text by similarity of meaning. It produces the most topically coherent blocks, but it's also the costliest and hardest to control, since chunk size stops being an adjustable parameter and becomes a consequence of the content, creating everything from noise (minimal blocks of 2 characters, as seen in Figure 1) to excessively long chunks.

There is no absolute winner. Each method wins at something and breaks something else depending on the nature of the text. The choice shouldn't be a lottery based on the method's popularity, but a decision grounded in how each strategy handles the information units in your corpus.

Analysis results

The first thing we can observe and analyze is chunk length for each strategy. This gives us an idea of how uneven the resulting sizes are, which is the first indicator of how each strategy affects the granularity of the information.

Figure 1 shows the range of results for the reference document.

Figure 1 gives us more data on the process. Each strategy yields a specific number of chunks: 72, 56, 50 and 22, and none of the four deserves to be discarded outright. Fewer chunks is not a better indicator.

This brings us to the fundamental dilemma of granularity: a constant trade-off between overall context and fine detail. Chunks that are too small gain precision for direct queries, but risk losing the thread needed to understand the full answer.

Conversely, excessively long chunks preserve context but often "dilute" the relevant information, making it harder for the system to locate the specific fact. Finding the balance isn't an exact science but a fine-tuning exercise that depends entirely on how the information is structured in your corpus.

The table below also shows how many tokens each of those chunks takes up, compared with the 128-token window length set by the model used. This limit marks the threshold of the blind truncation phenomenon, which introduces a dangerous semantic bias:

This "blind truncation" phenomenon, illustrated in Figure 2, introduces a dangerous semantic bias by compromising the chunk's vector representation. It's a problem of "partial blindness": the LLM receives the full information, but the retrieval system, which acts as the input filter, never processed that information during the search phase. This sometimes explains why the system can retrieve an apparently relevant chunk based solely on its beginning, yet deliver a poor answer because the core of the information was in the discarded tokens.

Table 1. Comparison of the four chunking strategies applied to the document "Days off, vacation and absences.pdf".

And here's why this failure survives for years inside a production system: whatever exceeds the window is discarded at vectorization, with no error and no warning.

It's a completely silent process: no exceptions, warnings or errors in the system logs. The chunk enters the index, takes up its vector and behaves perfectly normally. Except that vector represents its first 128 tokens and nothing more.

The full text does reach the LLM, because it travels in the payload. But it took no part in the search. What decided whether that chunk got retrieved or not was a fragment of the fragment, which is an enormous loss of information.

Figure 2 illustrates this phenomenon. The 128-token threshold doesn't distinguish between effective and ineffective strategies. Instead, it cuts across the distribution of those that, by their nature, fit the document's structure better.

So before analyzing retrieval metrics or tuning window size, auditing truncation is a mandatory step. If your chunks are being blindly cut off by the embedding model, any later optimization will be in vain, because the system will be indexing incomplete information.

Evaluating this phenomenon is, ultimately, the first stress test to check whether your chunking strategy actually works or whether it's been limiting your RAG's potential from day one. That's the first piece of data worth having on the table before debating which strategy is best.

Calibrating chunk size: why the similarity score is not enough as a relevance criterion

In this case, only the fixed and recursive strategies let you set the chunk size. This calibration only makes sense with these strategies, which tend to be the most common when you start building a RAG system.

The same document was indexed with three size and overlap configurations, measured in words, and I ran a query of the kind any employee would ask: how many unused vacation days can be carried over, and until when?

The score in Table 2 is the cosine similarity between the question vector and the top-1 chunk vector, computed over an index built from scratch for each configuration. It doesn't measure whether the answer is complete, only the geometric closeness between the two.

Table 2. Result of the pilot query on three size and overlap configurations, same document.

The results show three things at once:

1. With chunks that are too small (30 words), the answer gets scattered across several pieces and the system returns text from a different page, a failure nothing fixes afterward.
2. The score doesn't pick the right winner either: 60 words gets 0.7704 versus 0.7690 for 120 words, a difference within noise, and the one that "wins" is the one that cuts the answer in half, while the one that "loses" brings back the full deadline.
3. Size determines cost: going from 30 to 120 words, chunks drop from 124 to 39, so there's less to index and compare, in exchange for sending more tokens with each query.

What this example teaches can be summed up in one sentence: a system can return a high score, on the right document and the right page, and still deliver an answer that's missing information.

That missing information may get "filled in" by the LLM in its response, which is yet another source of hallucinations we need to watch for.

Now the fine print, before anyone writes it in the comments. This is one query, one document and one top-1. In other words, it illustrates a mechanism; it doesn't measure it. With a different question, the order of the scores can change, and this table's winner is not a size recommendation for anyone. It's proof that you need to measure your corpus rather than copy anyone else's configuration.

What the latest large-scale research says

So far we've looked at a "toy" case: one document, one quick experiment and one sample query. Time to test these observations against evidence at scale and see whether emerging techniques really overcome the truncation problems we've detected.

In this study by Shaukat et al. (2026), researchers measured 1,080 configurations, applying 36 chunking strategies across six domains and five embedding models, with retrieval isolated from the rest of the system. After all that volume, the study's results confirm what we've been saying in this post: there is no single winner. For example, dynamic chunking dominates in Biology, Health and Physics. Paragraph grouping wins in Legal and Mathematics. And in Agriculture, no method stands out clearly.

One fundamental conclusion comes out of this research: there is no universal strategy, because the effectiveness of each method depends intrinsically on the domain and the corpus.

It's also a mistake to try to compensate for a poor chunking strategy by using more advanced embedding models.

Since chunking and embeddings work multiplicatively rather than as mutually exclusive alternatives, bad chunking will irreparably limit the performance of any model, regardless of its cost or sophistication.

The question that does have an answer

The question almost all of us arrive with is: what's the best chunking strategy? It's the wrong question, and as we've seen in this post, it still has no answer.

The ideal strategy isn't fixed: its performance shifts with the domain, the embedding model and the structure of your documents.

That's why the key question isn't which one is best, but how much accuracy we're losing by not auditing our own chunking configuration.

Answering it takes time and deliberate analysis. Spending a few days auditing how many chunks exceed the model's window, preparing representative queries with business experts and testing different configurations, among other things, is an investment worth making. You don't need a complex benchmark. What you need is commitment.

The essence of this article boils down to one maxim: don't adopt a chunking strategy out of inertia, measure yours.

And if you know someone who built their RAG a year and a half ago and hasn't opened the file where the splitter lives since, share this with them. They have the most to gain from spending a few days on this review.

References

• Es, S., James, J., Anke, L. E., & Schockaert, S. (2024, March). Ragas: Automated evaluation of retrieval augmented generation. In Proceedings of the 18th conference of the european chapter of the association for computational linguistics: system demonstrations (pp. 150-158).
• Ford, D. (2024, September 19). Introducing contextual retrieval. Anthropic.
• Günther, M., Mohr, I., Williams, D. J., Wang, B., & Xiao, H. (2024). Late chunking: Contextual chunk embeddings using long-context embedding models. arXiv:2409.04701.
• Lu, W., Chen, K., Qiao, R., & Sun, X. (2025). HiChunk: Evaluating and enhancing retrieval-augmented generation with hierarchical chunking [Preprint]. arXiv:2509.11552.
• Merola, C., & Singh, J. (2025). Reconstructing context: Evaluating advanced chunking strategies for retrieval-augmented generation. Second Workshop on Knowledge-Enhanced Information Retrieval (KEIR), ECIR 2025. Preprint: arXiv:2504.19754.
• Saad-Falcon, J., Khattab, O., Potts, C., & Zaharia, M. (2024, June). Ares: An automated evaluation framework for retrieval-augmented generation systems. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers) (pp. 338-354).
• Shaukat, M. A., Adnan, M., & Kuhn, C. C. N. (2026). A systematic investigation of document chunking strategies and embedding sensitivity [Preprint]. arXiv:2603.06976.
• Smith, B., & Troynikov, A. (2024). Evaluating chunking strategies for retrieval [Technical report]. Chroma.
• Thakur, N., Reimers, N., Rücklé, A., Srivastava, A., & Gurevych, I. (2021). Beir: A heterogenous benchmark for zero-shot evaluation of information retrieval models. arXiv preprint arXiv:2104.08663.
• Zheng, L., Chiang, W. L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., ... & Stoica, I. (2023). Judging llm-as-a-judge with mt-bench and chatbot arena. Advances in neural information processing systems, 36, 46595-46623.

Scaling web optimization without wrecking the user experience or degrading the infrastructure means moving past impulsive client-side experimentation. In this post, we look at how to align these three teams through a "Safe-UX" framework: a strategy built on strict guardrails (Design Tokens, Edge/Server-Side architectures and tightly scoped System Prompts) to deliver dynamic hyper-personalization at sub-100ms speed.

This is the second post in our series on dynamic personalization without wrecking the UX. If you haven't read the first part yet, here's the link:

• Dynamic AI Personalization Without Wrecking the UX: The Evolution of CRO and the Impact of GenAI on Workflow

The risk for UX: interface fragmentation and loss of Design System consistency

The pillar of any good user experience is predictability, one of the core tenets of Nielsen Norman Group's usability heuristics. When a digital product has a well-established Design System, its visual patterns, typographic hierarchy and interactions follow a unified logic that reduces the user's cognitive load.

Introducing AI-driven dynamic variants without tight control puts that consistency at risk:

• Visual and component inconsistency: if generative models change layouts, spacing or styles on their own, the interface can turn into a patchwork of misaligned components. A small tweak to a button or to the layout of a product card can break the product's global style guidelines.
• A fragmented brand experience: if two users see versions of the same website with completely different tones of voice, layouts or flows, the brand identity gets diluted. Users lose the visual reference points they recognize, which can lead to a lower perception of quality and trust.

The risk for Tech: latency, external API calls at render time and the dreaded flicker effect that ruins Core Web Vitals (CLS/LCP)

For engineering teams, injecting dynamic changes in real time is a constant architecture and web performance challenge.

When optimization and AI logic runs on the client side, critical technical performance issues appear:

• Flicker effect (FOOC/FOUC). When the page loads, the browser first renders the original version and, milliseconds later, the experimentation script applies the AI-generated variant. That visual jump, or flash, degrades the perceived experience and spikes the Cumulative Layout Shift (CLS) metric. It's a common problem with client-side scripts, and it takes specific strategies to prevent page flicker.
• Impact on latency and LCP. Relying on asynchronous calls to external APIs or language models during rendering adds milliseconds of blocking time. This delays the appearance of the main content (Largest Contentful Paint, LCP) and directly hurts your Core Web Vitals score, which in turn affects organic search ranking (SEO).
• Client-side script overload. Piling up JS libraries and heavy tags to evaluate variants in the browser degrades responsiveness and performance on mobile devices and slow connections.

The risk for Marketing / Business: hallucinations or inappropriate copy that damage brand positioning

From a business and marketing perspective, automating copywriting in real time offers unprecedented agility, but it also brings significant reputational and commercial risks:

• Hallucinations and unverified claims: language models can produce persuasive but inaccurate copy, attributing features the product doesn't have, quoting wrong prices or citing service terms that legal never approved.
• Misalignment with strategic positioning: a model aggressively focused on maximizing short-term conversion can fall back on patterns like artificial urgency, an overly pushy sales tone, or language that clashes with the company's values.
• Inconsistent value promises: if the tailored message users see on the landing page doesn't exactly match the real product offer or the service they get afterward, the initial conversion will end up driving high churn and damaging the brand.

Guardrails for "Safe-UX" generative AI: 3 best practices

1 Align with the Design System: use predefined modular components (tokens and atomic components)

To avoid visual fragmentation and make sure dynamic variants respect the brand identity, generative AI shouldn't build HTML or CSS from scratch. As analyses of AI-ready Design Systems point out, the key is to restrict what the model can do to the closed ecosystem of the design system itself:

• Governance through Design Tokens: the AI should interact exclusively with predefined design variables. Following specifications such as the W3C Design Tokens Format, instead of letting the model invent a Hex color code or a free-form typeface, you limit it to invoking existing tokens.
• Atomic composition: the AI model works with modular components approved by the UX/UI team (buttons, cards, accordions, banners). The AI only decides which component variant to show or which content to place inside its predefined slots.
• Automated accessibility validation: by using components that already have accessibility standards built in (contrast ratios, ARIA labels, keyboard navigation), you make sure the generated variations stay accessible to all users.

2 Constrained models (Prompt Engineering and Fine-Tuning): set the boundaries for tone of voice and business rules

To mitigate the risk of hallucinations, legal inaccuracies or language drift, copy generation needs to be fenced in by strict control rules at the model layer:

• Structured System Prompts: clearly define the boundaries of communication. The system prompt should include the brand style guide, banned words, allowed sentence structures and the right Tone of Voice for each user profile.
• RAG (Retrieval-Augmented Generation) and closed databases: the AI shouldn't generate answers based solely on its general training. It should query an audited knowledge base in real time (product datasheets, legal terms, approved FAQs) to make sure every claim about the product is rigorously true.
• Fine-tuning and content classifiers: use models previously fine-tuned on the company's history of high-performing copy, or add an intermediate classifier model that evaluates the generated variant and rejects it if it doesn't meet brand-alignment criteria before it's shown.

3 Edge / Server-Side architecture: process personalization before it reaches the browser to keep speed under 100ms

Technical performance and load speed are critical factors that directly affect conversion rate and organic visibility, as seen in approaches like technical validation of web experiments and Generative SEO (GEO) optimization. To eliminate the flicker effect and protect Core Web Vitals, the optimization logic has to move out of the user's browser:

• Edge processing (dynamic CDNs): move AI model calls and personalization rules to Edge nodes close to the user's geographic location, using technologies like Cloudflare's Worker scripts and HTMLRewriter.
• Server-Side Rendering (SSR): the server or Edge node evaluates the visitor's signals, asks the model for the right variant and delivers the already-modified HTML to the browser in a single response.
• Zero flicker and sub-100ms latency: by delivering an HTML document that's ready for the browser to paint, you eliminate the visual jump entirely (CLS = 0) and keep response time below the recommended threshold for instant interactions, leaving your Largest Contentful Paint (LCP) score intact.

Practical use cases (E-commerce, SaaS and Lead Gen)

E-commerce: dynamic landing pages that adapt the main benefit to the product category previously viewed

In e-commerce, one of the biggest conversion problems is the disconnect between generic homepage or landing page content and the specific interests detected during the user's browsing sessions.

By integrating AI engines and contextual personalization, you can restructure the visual and narrative proposition in real time:

• Hero section reorganization. If the user's previous interactions have focused on high-end sports footwear, the landing page's main banner will autonomously adapt the headline, background image and value proposition toward attributes like "durability, performance and cushioning." Conversely, if their previous behavior points to urban fashion searches, the message will pivot to "trends, design and style."
• Conditional social proof. The reviews and testimonials section dynamically filters the most relevant ratings based on the purchase profile. Instead of showing random opinions, it presents verified comments about the specific category the visitor has recently explored, speeding up the purchase decision.
• Frictionless contextual cross-selling. The AI predicts the complementary product with the highest likelihood of conversion and adapts the recommendation block, placing it in strategic spots on the page and avoiding a flood of generic offers.

B2B SaaS: smart forms that adapt their fields and messaging to the industry detected via IP/Reverse-DNS

In B2B SaaS environments, long forms for requesting demos or free trials create considerable friction that lowers lead capture rates. On the other hand, forms that are too short make it harder for the sales team to qualify prospects.

Combining firmographic intelligence databases (like Clearbit Reveal or Albacross) with generative AI resolves this tension by personalizing forms and capture pages at the moment of access:

• Real-time company identification. When a corporate user lands on the website, the system processes their IP address through a Reverse-DNS lookup and identifies the company, industry and estimated headcount.
• Dynamic form shortening. If the data intelligence system recognizes the visitor's company, it hides manual fields like "Industry," "Company name" or "Number of employees." The user only needs to enter their work email, which drastically cuts the number of fields and increases conversion.
• Contextual adaptation of the value proposition. The AI rewrites the form's headline and call to action (CTA). For a financial services company, the copy can highlight "Regulatory compliance and bank-grade security," while for a tech startup it will emphasize "Scalability and API integration in minutes."

Media / Services: content recommendations and calls to action (CTAs) based on the user's funnel stage

On digital media platforms, service portals and Inbound Marketing strategies, treating every reader the same means missed opportunities to move them toward conversion or subscription.

AI-assisted classification models make it possible to adapt the content architecture and action buttons to the visitor's level of digital maturity.

Conclusion: balancing the triangle is the new CRO standard

The success of a generative AI CRO strategy doesn't depend on how sophisticated the language model is, or on how fast we can generate variants, but on how solid the defensive framework we build around it is.
The tension between Marketing, UX and Tech stops being a bottleneck the moment clear rules of the game are in place:

• Marketing and Business get the contextual relevance and performance they need by anchoring models to closed knowledge bases (RAG) to eliminate commercial hallucinations.
• UX and Product protect visual consistency and brand identity by forcing the AI to operate only within predefined atomic components and Design Tokens.
• Tech guarantees speed and strict compliance with Core Web Vitals by moving processing to Edge architectures and Server-Side Rendering, reaching imperceptible response times.

Personalizing at scale is no longer about chaotically altering the website on the fly. The real future of digital optimization is about building a living system where automation and artificial intelligence operate within a controlled environment: invisible to the user in terms of latency, but with maximum impact on conversion.

References

• Nielsen Norman Group. (n.d.). Consistency and Standards: 10 Usability Heuristics
• Google Web.dev. (n.d.). Optimize Cumulative Layout Shift (CLS)
• Optimizely Glossary. (n.d.). Server-Side Testing vs. Client-Side Performance
• VWO Blog. (n.d.). Understanding VWO SmartCode and Preventing Page Flicker
• Harvard Business Review. (2023). Managing the Risks of Generative AI in Marketing
• McKinsey & Company. (n.d.). The Value of Getting Personalization Right—or Wrong—Is Multiplying
• HubSpot Blog. (n.d.). Personalized Calls to Action Perform 202% Better Than Basic CTAs

One version started with its context written down from day one: a spec and a file telling the agent what the project was like (architecture, conventions, what to respect). The other started with little more than an installation README, and stayed that way for months.

The repository told the story by itself. The version with context had a clean, coherent architecture with no loose ends. The other had decisions made on the fly, half-finished error handling, several abandoned TODOs in the code, and an architecture document that showed up late, once the mess was already made. The one variable that set them apart was context.

Picking up the message from how important it is to specify things so the model doesn't wander off: an agent will always fill information gaps with the first thing that works, so context matters even more, because it decides whether those gaps get filled with information from your project or with inventions that happen to fit.

To keep this from getting abstract, we'll use the same example that runs through the whole series: a shared-expenses app. You know the type: the ones for splitting the bill on a trip or at a dinner with friends. Its MVP is deliberately modest: create a group per event, add an expense saying who paid, split it in a configurable way, see a balance screen showing who owes whom, and settle up.

What's out of v1 has also been decided: no real payments inside the app, no multi-currency, no offline mode. We'll hang everything relevant about context on this app, because good ideas only really sink in when they run into a concrete feature.

What is an app's “context,” really?

An app's context is the contract the agent reads before touching the code: the documents that tell it how this particular app works. It's not an installation README or decorative documentation. It's what turns “build me a screen” into “build me a screen that fits in here.”

This is worth spelling out because it's easy to miss. It's tempting to think context means “telling the agent what the app does,” but it isn't that, or at least not only that. Context is telling it which decisions have already been made, so it doesn't make them again. In the shared-expenses app, the fact that a split can be equal, by percentage, or by fixed amounts is a product decision the agent has to respect, not reinvent every time it touches that area.

In our projects, this contract lives in three layers for each app:

Turned into a file, the shared-expenses app's contract looks something like this. It's the CONTEXT.md we leave at the root of the repo so the agent reads it before anything else:

# CONTEXT — Shared-expenses app

## What it is
Split an event's expenses (trip, dinner) among several people.
MVP:
- Create a group per event.
- Add an expense saying who paid.
- Configurable split: equal shares / percentages / fixed amounts.
- Balance screen: who owes whom.
- Settle up.
Out of v1 (DO NOT implement):
- Real payments inside the app.
- Multi-currency.
- Offline mode.

## How it's built
Clean Architecture. Layers: ui / domain / data.
- ui    → screens and state, no business logic.
- domain→ use cases and rules (the split lives here).
- data  → repositories and data sources.

## Persistence
Local database → source of truth for the data.
Backend → only for syncing between devices.
FORBIDDEN to call the backend from the UI. The UI talks to domain;
domain talks to data; data decides local vs. backend.

## Conventions
Screen state: loading / error / data.
Errors: never a TODO; always real handling.

None of this is exotic. Half the file describes things the app doesn't do. That “out of v1” section carries as much weight as the MVP, because it's what stops the agent, the moment it smells an amount field, from building you the currency conversion nobody asked for. What matters isn't what it says, but that it's written down before the agent starts making decisions on its own.

Without context, the agent doesn't stop. It improvises

An AI agent with no context doesn't stop to ask. It improvises a plausible architecture and keeps going. Since it never says “I don't know,” it fills every decision we didn't give it with whatever it finds reasonable, and what it finds reasonable almost never matches what we've already built.

In the version without context, that played out predictably: errors patched “just to get by” with a TODO instead of real handling, no rule about when to use the local database and when the backend, and patterns that changed from one screen to the next. The agent wasn't wrong by its own logic. The problem is that it didn't have ours.

It's easier to see with a feature from the expenses app. Say we ask it to add percentage-based splitting to a group. Without context, a request like this:

Add the ability to split an expense by percentages among the group members

The agent, helpful to the point of being overbearing, does everything at once: it puts the split logic inside the screen widget, calls the backend directly to “save the percentages,” invents a new model instead of touching the expense that already exists and, while it's at it, leaves a “//TODO: validate that they add up to 100%” just in case.

It works in the demo, but the result was three core principles broken in a single feature: business logic embedded in the interface, a backend connection that violated the contract, and redundant domain code.

It didn't do it in bad faith. We asked for a split… without telling it where the split lives in our app. And where there's no rule, there's improvisation.

The agent doesn't improvise because it's bad. It improvises because we didn't give it the information it needed, so it had to.

With CONTEXT.md in front of it, you don't even need to phrase the same request differently. The same task, now read through the contract, sounds like this:

Add percentage-based splitting to an expense.
- The split rule goes in domain (use case), never in the UI.
- Reuse the existing expense model; don't create a new one.
- Persist to the local DB; the backend only syncs (don't call it from here).
- Screen state: loading / error / data. No TODOs: validate that they add up to 100%.

The difference isn't that we write more. It's that those four lines were already written once, in the contract, and the agent carries them into every task. The piece fits instead of landing wherever it lands. And the best part: the next feature (an expense filter by person, say) inherits exactly the same rules without us repeating them.

The trap of after-the-fact context

Documenting the architecture after writing the code isn't building context. It's performing an autopsy. In the version that went wrong, that document arrived late, with most of the code already written. It didn't steer a single one of those decisions. It just described, in neat handwriting, the mess that already existed.

And that's the nuance most people skip: a contract you sign after the work is done isn't a contract, it's minutes of a meeting. Context only does its job (stopping the agent from improvising) if it exists before the code it's supposed to guide.

I say this from experience. In the version that went wrong, we ended up with an architecture document with diagrams, well-named layers, the works. And it was useless, because it described code that had already decided otherwise.

Documenting after the fact is an autopsy: you learn what killed the project, but the project is already on the table. The balance feature, for instance, calculated who owes whom in three different places in that version, and no later document was going to unify that for me.

How to set up context before you start

Context gets built at the beginning, before the code, and across the three layers we've already seen: what it is, how it's built, and what not to touch. It doesn't have to be long. It has to exist before the first line of code. In our best-structured apps, each one starts with its own documentation folder (spec, decisions, design), validated before anything gets programmed.

In practice, for the shared-expenses app, that meant a short session with the agent discussing the contract, not writing code. Something as simple as this before the first commit:

repo/
|–– CONTEXT.md       <-- what it is, how it's built, what not to touch
|–– docs/
|   |–– spec.md      <-- the detailed MVP: groups, expenses, split, balance
|   |__ decisions.md <-- why local DB as the source of truth
|__ (still not a single line of code)

It looks like very little, but with half an hour of definition we're saving ourselves weeks of fighting an agent that pulls in a direction you don't want. When we later asked for the balance screen, we didn't have to explain again that the “who owes whom” calculation lives in domain, because it already knew.

To make the contract work:

• Write it before the first commit, not halfway through.
• Keep it short: decisions and rules, not an encyclopedia.
• Update it when a decision changes, not after it has already broken something.

Context is a living contract, not an archive document.

And a warning, because the pendulum easily swings to the other extreme: context isn't a dump of everything you know. If you stuff in an encyclopedia, the agent gets lost just as it would with nothing. Context is the contract: the decisions and rules that truly bind it, not every implementation detail. If it doesn't constrain a decision, it doesn't belong.

Context isn't just for new apps. It's for a single feature too

Most of the time we're not building an app from scratch. We're adding a feature to one that already exists. And there, context matters just as much, or even more. The agent needs to know where the piece fits, what to reuse, and what to leave alone, or it will reinvent what we've already built.

A down-to-earth example from the expenses app: ask it to “add a filter for expenses by person on the group screen.” Without feature-level context, the agent might build us a brand-new data layer, duplicate the expenses repository that already exists, or solve the filter with a different pattern than the rest of the app. It works, but we end up with two ways of doing the same thing. It's the snowball again, now at feature scale.

With feature-level context, the request changes in nature:

Add a filter for expenses by person on the group screen.
- Filter using the existing ExpenseRepository; don't create another source.
- Follow the pattern of the expense list screen.
- Filtering is domain logic: solve it in the use case, not in the widget.
- Don't touch the expense model.

The agent stops inventing and simply puts the piece where it belongs. It's the same leap as with percentage-based splitting, but at an even smaller scale, which makes it easier to forget to provide context, and that's exactly when it bites.

A feature's context:

• Where it fits: the screen or module, and the pattern to follow.
• What to reuse: the repositories, components or utilities that already exist.
• What not to touch: whatever falls outside this feature's scope.

It's the same contract, one size smaller.

It's the same “define and scope” idea from the first article in the series, applied to context: every task, however small, has its own slice of context. Providing it before you start is what keeps the agent, while helping you with one feature, from messing up the other twenty.

Pain or boost: it changes how we talk to the agent

Setting up context changes, above all, how you communicate with the agent. Without it, in every session we repeat the same rules, correct the same drifts, and check every output in case it has made something up. With context, we point at the task and the agent stays on the rails we laid down once.

With the expenses app, you notice it in that we stopped writing three-paragraph messages explaining the architecture every time. We went from “build this, but remember the logic goes in domain, and don't call the backend, and reuse the repository, and please no TODOs…” to simply “add the filter by person,” and the contract did the rest of the work in every prompt.

That's the difference between AI being a pain or an accelerator. It isn't set by the model you use, but by whether we gave it the contract before asking it to work. At its core, it's the difference between directing and praying.

In this series, context grows out of the definition phase from the first article and sets up the next ones: design, stack, spec and development. The immediate next step is giving the agent reusable capabilities (skills), which lean on precisely this contract to know how and where to act. But the order never changes: first the contract, then the first line of code.

Shakira has just wrapped up her Las Mujeres Ya No Lloran World Tour with a historic residency of thirteen concerts over four weeks in Madrid, drawing more than 600,000 people. The bet wasn't simply to repeat the same concert many times, but to create a one-of-a-kind experience around the Macondo Park stadium, an ephemeral city that extended the experience into territories like gastronomy, literature, fashion, and culture.

The music is still at the center, of course, but the product grows around a much broader understanding of what connects with her community, through knowledge of what her fans think on social media, how her songs are listened to on digital platforms, and even how far her followers are willing to travel and what other experiences they want to live when they go to one of her concerts.

Something similar has just happened a few kilometers away, with the Spanish F1 Grand Prix at the new Madring circuit in Madrid. The organizers didn't just host an existing race, they premiered a brand-new layout built for the Grand Prix and conceived from the start as more than a circuit.

Combining urban and permanent sections, along with a banked corner aiming to become its icon, they've managed to offer an experience around the race with concerts, food, and fan zones. The competition is still 57 laps and 22 cars chasing the finish line, but around it a new experience has been deliberately designed, thanks to a deep understanding of what truly moves fans when they aren't looking at the track, and of how to turn a two-hour race into a weekend nobody wants to miss.

Behind both examples is an idea that should make us rethink how we understand innovation: the winner isn't whoever accumulates the most data or adopts the latest technology, but whoever knows how to turn what they know into something others can't offer. Because technology can be bought, AI models will be increasingly within everyone's reach, and data isn't going to stop multiplying.

What can't be bought so easily is the knowledge an organization has built over the years about its customers, its business, and its way of doing things. And, above all, its ability to connect that knowledge with the right context and turn it into experiences, opportunities, and decisions that make a difference. Technology can be the same for everyone. What each organization knows, and what it's capable of doing with it, can't.

And what does all this have to do with a financial institution? A lot more than it seems. Few industries accumulate as much knowledge about their customers as banking: how they earn, how they pay, what they need, what risks they take on, and how their circumstances evolve. And yet, a good part of that wealth remains trapped in systems, processes, and departments that barely talk to each other.

Meanwhile, customers are starting to demand something different: it's no longer enough to offer them products and make transactions easy; they expect their bank to understand their situation better, anticipate their needs, and support them in the decisions that really matter.

The challenge is no longer to keep piling up information, but to get all that knowledge working. To turn what an institution knows into what it's capable of doing for its customers. Because that's where the opportunity lies to transform one of its most valuable, and often most underused, assets into its new competitive advantage. Or rather, its new cognitive advantage.

A cognitive bank isn't a bank with more AI

It's worth clarifying this early, because artificial intelligence has a knack for turning any interesting idea into a collection of pilots and demos. A cognitive bank isn't an institution that adds a chatbot, hands out copilots, or puts a few agents to work on the same old processes. It's an organization able to connect data, knowledge, and context to better understand its customers, anticipate needs, make better decisions, and, when it makes sense, act autonomously within clear limits.

And this is precisely the idea we drive at Paradigma with Cognitive Products: turning an organization's differentiating knowledge into cognitive capital and using it to build products that understand context, recommend, decide, or act, learn with every interaction, and always keep control in the organization's hands.

But the real earthquake isn't being caused by technology — it's the shift in customer expectations. After years of adapting to their banks' processes, menus, and apps, customers are now starting to demand exactly the opposite: that the bank be the one to understand them, anticipate, and adapt to them. And that shift is starting to move the tectonic plates of the financial sector in Spain.

For years, we celebrated that a customer could do practically any transaction from their phone. But now they're starting to ask for something a lot more uncomfortable: that the bank understand them and adapt to them, not the other way around. It's no longer just about offering better products or simpler apps, but about anticipating needs, understanding context, and being present at exactly the moment when value can be delivered to the customer. And that starts to change everything: who interacts with the bank, where that relationship takes place, and how far its business can reach.

After all, if Shakira has understood that the experience doesn't end with the last song, and Formula 1 that there's much more beyond the checkered flag, why should the financial experience end when the customer taps "Confirm transaction"? Few industries accumulate as much knowledge about their customers as finance. The challenge is to stop having it scattered everywhere and start turning it into better experiences, opportunities, and decisions. To move from managing transactions to understanding everything that happens around them. That's where real cognitive banking begins.

And we're not talking science fiction or yet another nice presentation about the future. We're talking about four signals that are changing the rules of the business, and a fifth that deserves to play in another category: the one reminding us that, no matter how much intelligence we add, transformation will still depend on people.

1 Welcome to the agentic era: your next counterpart may not be human

For years, banking worked hard to move its customers into unattended channels for certain transactions. First the ATM, then the web, and finally the app. "Do it yourself," we were told. Well, today the tables are starting to turn: customers are the ones starting to bring banks into their own unattended channels: their AI assistants or agents.

Imagine asking your AI agent: "Find a personal loan for the family Christmas trip, compare five well-rated banks, and tell me which one fits our plans best." And instead of opening five apps, the assistant talks to those institutions' systems (or agents). You start out gathering information and end up transacting, or even signing up directly. Careful, this isn't science fiction. Since February 2026, BBVA has had an app inside ChatGPT in Italy and Germany to check and compare accounts, cards, and savings products. For now.

And here comes the jolt: that "new representative" for customers doesn't get excited about their bank's campaign, doesn't need to click through eight screens, and can compare offers in seconds. After so many years trying to disintermediate banking, we may be entering its most intermediated stage yet. The one deciding which proposals reach the customer could be their own assistant.

That's why the race doesn't start with building an army of agents; it starts with something much less flashy: offering clear, machine-accessible product information, opening reliable interfaces, and exploring which decisions can be delegated with identity, consent, and clear limits. You can have the best banking app in the world, but what good is it if your customer's AI never even considers opening it?

2 The end of the bank as a destination: don't just compete on products, orchestrate ecosystems

For years, we assumed a digital banking relationship began when a customer walked into a branch or opened the app on their phone, but that boundary is starting to blur. Financing can show up while we're buying a car, insurance when we book a trip, and a treasury solution inside the ERP a small business uses to run its day-to-day operations.

The channel dissolves and the business starts behaving like an ecosystem. It's not simply another sales channel: it's a change in the commercial distribution model and, along with it, in the customer relationship. Banking stops waiting for someone to come looking for a product and starts showing up where a need arises. And in that scenario, banks, retailers, manufacturers, and platforms can share one and the same experience. The uncomfortable question is who leads it, and who ends up carrying the balance sheet without knowing the customer.

In Spain, Cajamar is already offering some clues with its Plataforma Tierra, an ecosystem for the agri-food sector that combines knowledge, market information, training, and digital tools. With more than 30,000 registered users and 1.2 million visits, it shows that the relationship with a farmer can start long before they need financing.

That also changes what it means to compete. It's no longer enough to offer an attractive loan: what matters is being present when the decision to invest, buy, or grow is made, and understanding the context well enough to offer something useful. The opportunity doesn't require building the grand banking ecosystem tomorrow: it can start by identifying a moment of need, connecting a relevant service, or partnering with someone who's already there. The difference will come from using what we know about each customer to offer them what they actually need, when they need it. Because you can have the best financial product, but if you're not where decisions get made, you may not even get into the conversation.

3 Precision finance: segmentation is dead, unless the segments are your own

Banking has spent years fine-tuning segments, offers, and predictive models, and it hasn't done a bad job. But the new AI models open up a new game: moving from offering what's best for someone like you to offering what makes sense for you, right now. Personalization with context, in real time.

There's no shortage of raw material. There's explicit knowledge (goals, preferences, or plans the customer shares) and tacit knowledge, which emerges from their income, payments, habits, and interactions, and even knowledge that exists only in the head of the personal banker. The bank already holds a good part of those signals. The leap is in connecting them, with the right permissions and security, to anticipate a liquidity squeeze, propose an investment only when it makes sense, or decide that today it's better not to sell anything at all.

Revolut made its move this very summer with Pragma, a model developed alongside Nvidia that learns from financial behavior. In initial evaluations with historical data, it reports 41% more relevant product recommendations and 2.3 times more accuracy in identifying default risk. These are preliminary results, but they point to something our common sense already anticipated: understanding context better improves what you offer and the decisions you make.

And then comes the visible part: content, explanations, or even AI-generated videos for each customer, adjusting tone, channel, and timing. But careful, this isn't about producing a million different ads to push the same consumer financing campaign. It's about adapting the service as well: what you propose, when, and why. You can start with one specific moment, connect the necessary knowledge, and check whether the response adds value.

If you speak differently to each customer but end up offering them the same quarterly campaign, you haven't built cognitive banking. You've just automated marketing.

4 Your next competitive advantage may come from Brussels, not just Silicon Valley

I can think of few industries more regulated than banking. And rightly so: managing other people's money demands trust. But we have a habit of looking to Silicon Valley to imagine the future and to Brussels to find out what will hold us back. What if we've been looking at regulation from the wrong side?

There are already signs. DORA requires strengthening digital resilience and keeping an eye on technology providers; MiCA sets common rules for crypto-asset services, and PSD3, still on its way, will aim for more competitive and secure payments. These obligations can also open up businesses that were previously hard to build with confidence.

In Spain we have a good lab to test this: the financial sandbox, which since 2021 has received more than 110 projects, 40 of which have reached real-world testing. And this very summer a reform was presented to open applications year-round and speed up timelines. It's still just a proposal, but the message is clear: innovating under supervision shouldn't be an obstacle course.

In cognitive banking, this matters even more. When an AI goes from informing to recommending or acting, it's not enough for it to get things right. You need to know what information it used, what the customer authorized, and where the limits are. There, proprietary knowledge, connected and governed, can become an advantage that's hard to copy.

There's no need to wait for the next regulation or sign up for a five-year transformation: you can start with one specific decision, test it with controls in place, and put business, risk, and technology at the same table. While some banks keep calculating how much it'll cost them to comply with the next regulation, others are already designing the business that regulation will make possible.

5 Fewer people working like machines, and more machines making people extraordinary

In the race to automate everything, we can forget an important detail: customers are still people. And so are the people who work at the bank. Cognitive banking shouldn't take humans out of the equation, but free up their talent to listen, decide, and build trust.

Klarna, the Swedish-born financial company, taught us one of those lessons that sting. In 2024 it was celebrating that its AI assistant handled two-thirds of its customer conversations, doing the work equivalent of 700 agents. A year later, its CEO admitted that prioritizing savings had hurt quality and announced more human support. Because resolving a case doesn't always mean caring for a relationship.

The opportunity is in building hybrid organizations: agents that look up information, prepare decisions, and execute tasks hand in hand with people who bring judgment, empathy, and accountability. But careful, those agents will only be as differentiating as the proprietary knowledge that feeds them. If they work only with a generic model, your competition will have that same intelligence one click away. The advantage will appear when you connect AI with your professionals' experience, your customers' context, and what's been learned across thousands of decisions. That's what it really means to give a banker superpowers.

And no releasing an army of agents and crossing your fingers. This new workforce needs governance: permissions, limits, traceability, oversight, and clear owners. You can start with one specific process, measure quality, and let knowledge grow with every interaction. You can put the most advanced AI in the world behind the wheel, but if it doesn't draw on what only your bank knows and doesn't keep people in charge, you're not building cognitive banking. You're putting your bank on autopilot.

A new cognitive opportunity

After these five jolts, it would be easy to reduce all of this to a new technology architecture full of boxes, arrows, and acronyms. And yes, we'll have to talk about APIs and integration patterns to connect ecosystems, about protocols like A2A so agents can collaborate, about knowledge graphs and semantic layers so data makes sense, and about security and governance so everything works with guarantees. But careful: having all the technology pieces doesn't mean you've understood which game you want to win.

The real challenge is a lot less flashy than a good demo. An institution's knowledge is spread across transactional systems, CRM, risk tools, documents, historical decisions, and, above all, people who have spent years understanding the business. Connecting it, structuring it, and putting it to work so every banker, product, or agent can make better decisions is much harder than rolling out the latest AI model, and also much more valuable.

That's why we may be starting too many conversations from the wrong place. Instead of asking where we can drop in a new agent or which processes we can automate, we should ask ourselves a much more uncomfortable question: which important decisions in our business would improve radically if we were able to make use of everything we already know? That's where business and technology should start working together. There's no need to wait until everything is figured out: we can start with one relevant decision, connect the necessary knowledge, measure the impact, and learn from every interaction.

Shakira's songs will keep playing, and Formula 1 cars will roar again in Madrid next year. Apparently, more of the same. But something will have changed: everything they already knew about their audiences will be joined by what they learned at every concert, every race, and every experience. And if they know how to use it, the next edition won't start from scratch, it will start knowing more.

I'm convinced the same will happen with banking. We'll keep financing projects, managing savings, and assessing risk. But every interaction, every decision, and every outcome will enrich that body of knowledge, allowing us to better understand our customers and offer them increasingly relevant experiences.

AI models will be within everyone's reach, but what an organization learns with every decision can't be downloaded from any marketplace. At Paradigma, we believe that's where the real opportunity lies: turning knowledge accumulated over decades into cognitive capital that never stops growing and lets us build, every day, a new competitive advantage. A new cognitive advantage.

Ditching free-form text generation to focus on probabilistic determinism changes the rules of the game completely in enterprise architecture. That's exactly the premise behind Jev, the new "System One" model TypeSafe AI unveiled on September 15, 2026, an AI that completely abandons text writing to focus on evaluating information in parallel and returning strictly typed decisions in milliseconds.

If you already know what an LLM is and you're tired of using an expensive reasoning engine for conditional-logic tasks, this is the context you need to understand how to optimize your automations.

Why do we keep forcing LLMs to structure data?

Asking a generative network to return a structured object is like using a cannon to kill a fly. Autoregressive architectures calculate the next token based on a sequential history of prior words. When we try to automate routing support requests into our database, we usually instruct the model with endless rules, asking it to respect JSON quotation marks and not add noise. We end up building very fragile parsers that try to interpret completely unpredictable algorithmic responses.

When the model fails to close a tag, the system falls into an endless retry loop. Reacting to this kind of formatting failure breaks any transactional flow. We're talking about inference latencies that scale from three seconds all the way up to three hundred seconds of waiting. No commercial platform would accept keeping a user waiting half a minute to execute simple conditional logic. This approach turns the company's analytics layer into a black box.

When should you use Jev, and when your classic LLM?

Kahneman's psychological theory defines fast, intuitive thinking versus slow, deliberate reasoning. TypeSafe AI's Jev model brings this concept to life by eliminating the neural capacity to generate language. This architecture evaluates input states against a static schema using parallel sampling. Understanding this taxonomic split lets you design much more agile composite systems.

Let's look at exactly where Jev shines and where it falls short compared to a traditional generative engine.

• For mass ticket routing or triage, Jev is the clear winner. Corporate support systems receive messy information where text-analysis teams fail spectacularly and prove far too slow. Send a message about a duplicate charge and ask the algorithm to assess urgency, and it returns an exact typed classification in milliseconds. Using a frontier generative model here would be a waste of compute budget.
• Robotic interface control (RPA) and web agents require instant, iterative decisions. Community experiments integrating Jev into autonomous browsing projects show full flight-booking cycles in around seven seconds. Median operational latency drops to the 150-millisecond range, enabling reactive loops where a classic model would cause the system to collapse.
• Big Data processing demands this kind of architecture for strictly economic reasons. Using a traditional autoregressive network for this task would require hours of processing and the subsequent review of thousands of JSON records prone to typographical errors.

There are scenarios where deploying Jev makes no sense at all, because of its own structural blindness.

• If you need to write a summary, take part in a conversation thread, or generate source code, this system is computationally useless. It lacks the iterative decoding phase needed to articulate text. Here, you do need a generative model, and you need to let it reason.
• Regulated industries that demand analytical explainability face a similar roadblock. When you deny an insurance policy or reject a credit application, an auditing body will demand traceable reasoning written in natural language. Jev returns mathematical confidence percentages without arguing why it made its choice. To comply with strict financial transparency rules, you'll inevitably need an LLM's reasoning.

How does this change the way we design infrastructure?

Leaving behind the operational hell of these integrations means rethinking how we design our infrastructure. Instead of putting so much weight and effort into prompting, you'll now need to parameterize strict decision schemas.

The backend team no longer interacts with a character generator. Operating under a parallel-sampling model means configuring binary evaluations that the engine resolves without emitting a single word. Declaring the schema gives us technical determinism that takes costly syntactic-validation routines for text strings out of production.

That said, you do need to account for certain limitations in the original design. The context memory budget caps out at 64,000 tokens per call, and the architecture doesn't natively accept images.

Conclusions

Holding on to monolithic architectures that try to solve every type of use case seriously hurts commercial competitiveness. We've been forcing LLMs to behave like simple routers while paying unsustainable bills.

Bringing architectures like Jev's into our pipeline helps cut these costs, delivers more accurate answers, practically eliminates hallucinations, and shortens deployment times.

References

• Jev System One Model by TypeSafe - AY Automate
• A deep dive into Jev, TypeSafe's System One model - Flavio Copes
• What Is Jev? A Guide to TypeSafe AI's System One Model - LangChain
• TypeSafe AI's Jev: What "System One Models" Actually Are

Among them is a generation that doesn't remember a world without a smartphone: they order dinner from an app, watch the series a platform recommends before they've even searched for it, and have never set foot in a bank branch.

For them, a service that works on its own, remembers who they are, and doesn't make them repeat the same process three times isn't a luxury, it's the baseline.

The competition is no longer the university next door, it's platforms like Amazon or Netflix

For years, a university was compared, experience-wise, with other universities. That comparison is over. Today, students measure their university by the same yardstick they use for Netflix, Amazon, or their banking app: services that know them, anticipate what they need, and solve things without friction.

It's an unfair comparison (nobody expects a university to run like a streaming company), but it's the one students make, and the one that counts. And when the digital experience doesn't measure up, students conclude the university doesn't work. Sometimes they say so where it hurts most: in the satisfaction survey, or in a chat with the friend who's deciding where to enroll next year.

That's why digital experience has stopped being an internal systems matter and become a matter of attracting and retaining students.

Four systems for a single process

Let's follow the student. To check a grade, pay a fee, or request a certificate, they go from the academic management system to the virtual classroom, from there to the e-government portal, and sometimes to the CRM that wrote to them back when they were still a prospect.

Each with its own address, its own look, and its own login. Each asking them who they are, as if they hadn't just told the previous one. Nobody designed it this way — each system was bought at the time to solve a specific problem, and it does solve it.

What wasn't designed was how they would talk to each other. And the one who ends up acting as the link between them all is the student.

From the inside, however, it doesn't always look that way. Three out of four universities consider their level of digital transformation adequate and on par with other sectors (Fundación CYD, 2023).

And it's not for lack of effort: a lot has been invested, but mostly in what's visible (connectivity, equipped classrooms, screens...). As the Higher Education Spaces 2025 report sums it up, infrastructure has advanced, but the model hasn't been rethought.

Why a new app won't fix this

When the experience fails, the natural response is a better app. It makes sense: the app is what people see and what takes the complaints. But the app is just the experience layer, and it can't stand on its own.

If underneath, the academic system, the virtual classroom, the CRM, and the e-government portal don't share data or identity, the new app gathers them on one screen without truly joining them: often, each service shows up as another system's window embedded inside the app.

Students notice right away: the look changes, but they still have to identify themselves again, still can't find their things in the same place, and still get bounced out to another system halfway through a process.

You can redesign the screen as many times as you like, but if the process still runs through four systems that don't know each other, the experience will stay broken. It's the difference between repainting the facade and fixing the wiring behind the wall.

Five signs the problem isn't on the screen

These five signs aren't about architecture or technology: they're about what happens in a normal school year. If you recognize several, the problem isn't on the surface:

1. Students type the same piece of data more than once during the year, in different systems, because some don't know what others have already stored.
2. A routine process forces them to leave the app and log into somewhere else, with a different login, just to finish it.
3. Changing anything on the platform depends on a third party: on their timelines, their priorities, and their budget, not yours.
4. Nobody has the full picture of a student on a single screen: admissions, the registrar's office, and the teaching staff each see different pieces of the same person.
5. The last digital improvement was an app or a redesign, not a change in how the systems connect underneath.

None of these signs, on its own, is serious. The problem is when they pile up, because then they stop being isolated incidents and become the same symptom repeating: the gap between what a student takes for granted and what they actually find.

The urgency isn't about who's arriving today

So when they arrive at university, they want to check their schedule, apply for a scholarship, book a study room… and for the process to be simple, fast, and effective.

Those born from 2013 onward (so-called Generation Alpha) will start arriving at university around 2031. For Gen Z, a fragmented experience is a letdown; for Alpha, who won't have known anything else, it will be a flaw.

Five years may seem like a long time. It isn't for this decision: an academic platform isn't swapped out every two years. It's chosen, implemented, and carried for a decade.

The ecosystem decision a university makes this year is the one that will greet those students. Today the question isn't how to serve the student who's in the classroom right now: it's how to serve the one who's still in primary school.

In the same spirit, as a representative of the upper end of the demographic curve, alongside metaphors, I think it's worth backing up the argument with numbers.

Only 11% of consumers in the United States are willing to let AI decide a purchase for them, even in low-risk categories like personal care or household supplies, according to a Gartner survey published in May 2026. That figure demolishes the narrative that's taken hold in most leadership committees: that the consumer is already ready for autonomous purchasing. They're not. And yet, 58% of customers prefer a generative AI system to recommend products to them, according to Capgemini.

The contradiction isn't a measurement error — it's a clue to how each party involved sees the future, and that's an insight in itself. Shoppers aren't rejecting AI, they're rejecting losing control while using it.

54% of people who've used AI to shop have had to double-check the information the system gave them, and 62% consider that information a waste of time, according to the same Gartner study. This isn't an adoption problem, it's a design problem being attacked from different angles. Platforms are tackling it from availability and accuracy, while managing the actual experience falls on those of us who want to build differentiated value with it.

The symptom: scattered agents, broken experience

Over the last three years, most ecommerce businesses have followed the same script: a chatbot in customer service, a recommendation engine on the catalog, a dynamic pricing system at checkout, maybe a personalization agent in email.

Each piece works fine on its own. Each vendor can show off its own success story. The problem shows up when the customer moves between those pieces and discovers that none of them knows what the other just did — and this doesn't just break the experience, it can also be a source of problems at multiple levels whenever actions get automated across the whole martech stack.

To put it simply with an example: as a customer, I might have just closed a car insurance claim successfully with the tow truck, while at the same time considering canceling my policy for other reasons — and that combination could make me furious if I then get hit with the wrong upsell campaign. Response-time indicators, handling costs, or NPS can all look great in isolation and still completely miss why the problem exists.

Back to my number obsession: only 14% of the more than 20,000 consumers surveyed across 26 countries say they're satisfied with their online shopping experience, according to the IBM Institute for Business Value. Given how much technology has been rolled out over the last decade, that number should embarrass anyone of us sitting on this side of the equation (understanding, designing, implementing).

There's also a structural threat that few leadership committees are prioritizing, that we SEOs haven't managed to communicate properly, and that Gartner has been warning about for a while: back in 2024 it forecast a 25% drop in traditional search volume by 2026, displaced by AI chatbots. If the traffic that reaches you today from Google starts arriving (or not arriving) through a conversational assistant answering on the user's behalf, the question is no longer how to rank a page. It's how to get an external agent to understand, cite, and recommend your catalog. That fight is won with structured data, context, and cross-channel consistency. Not with one more chatbot.

The marketing name for this is zero-click search; the precise business term for it is "I'm losing visibility into my customer's context" (to put it politely).

The thesis: what's missing is a layer that perceives, interprets, and learns

The mistake isn't having too few AI agents — it's having them disconnected. Each agent perceives one slice of the customer (what they buy, what they ask, what they abandon in the cart), but none of them builds a combined picture. And without that combined picture, no real interpretation is possible: recommendations get generated off a fragment of behavior, not the full journey.

The cost of not having it is already measured, and not just by consulting firms: 70.22% is the average cart-abandonment rate in ecommerce, according to the Baymard Institute, which aggregates 50 independent studies published between 2006 and 2025. It's not a new problem, nor one exclusive to AI, but it's exactly the symptom a well-designed cognitive layer should reduce: the customer doesn't abandon because technology is missing, they abandon because nobody connects what every piece of that technology already knows about them.

What's missing is shared context — not one more agent, but the logic that connects the ones that already exist. Picture that customer from the car-claim example earlier: first, someone perceives that they just closed an incident with the tow truck, and, in parallel, that they've spent weeks looking at the cancellation policy. Then, someone interprets those two signals together, not separately, and understands this isn't the moment for an upsell. The system feeds that decision back: if the customer responds well to a different message, it remembers that for next time. And all of that turns into augmented experience at the one moment the customer actually sees: a message that, finally, makes sense given what's happening to them.

That's what, in the physical world, we'd call "breaking out of silos to work toward a shared goal." Here, it's four functions feeding into each other: perception, smart interpretation, feedback, and augmented experience. Without this layer, every agent keeps optimizing its own metric in isolation. With it, agents stop competing for the customer's attention and start building on what the previous one already learned.

This augmented experience no longer lives inside a fixed interface. For thirty years, ecommerce was a screen the product team designed once, and the customer always navigated the same way. That's dissolving: when the purchase happens inside ChatGPT, inside a Copilot assistant, or inside whatever interface an agent controls (what ECDB calls the Interface-First model), the brand no longer has a page to design — it has a conversation to win, different every time, assembled in real time based on whatever that agent decides to show. It's what design circles are starting to call liquid interfaces: there's no fixed layout to memorize anymore, there's a surface that reassembles itself with every interaction based on context, the agent, and the customer's moment.

And this is where Fantasia's broom comes back. If the interface is no longer fixed, and the logic governing it doesn't exist either, every agent not only acts on its own, it also presents itself on its own, with its own judgment about what's relevant to show the customer in that instant. The cognitive layer is optional in a world of fixed interfaces, where the error shows up on a dashboard. It's essential in a world of liquid interfaces, where the error shows up (or doesn't) inside a conversation nobody else is watching.

The point most people skip: governance, not total autonomy

This is where a lot of AI projects in ecommerce aim at the wrong target. The default ambition tends to be "more autonomous," as if autonomy itself were the sign of maturity. The same survey cited at the start disproves that: 72% of users say generative AI shows up in their experience without them having asked for it. That doesn't build trust, it builds rejection.

Kate Muhl's quote sums it up better than any internal report could: consumers aren't looking to hand purchase decisions over to AI, they're looking for AI to help them find better information while keeping final control themselves. That has a direct translation for any ecommerce leadership team: the goal isn't to automate more, it's to decide precisely which parts of the process can be coordinated between systems, which ones need explicit governance (rules, limits, human approval), and which ones can run with real autonomy because the risk of error is low and the cost of review is high.

That distinction (coordinated, governed, autonomous) isn't a technical nuance — it's the difference between a system a director can defend in front of a risk committee and one they can't. It's also why most AI pilots in ecommerce stall out: they're designed to maximize autonomy instead of maximizing trust, and the consumer (and the internal team itself) ends up switching off whatever they don't understand or control.

The market is already moving

Agentic commerce is set to move $8 billion in 2026 and is projected to reach $3.5 trillion by 2031 — a 43.24% growth rate over five years, according to ECDB/Juniper Research. This isn't an abstract forecast: traffic that already arrives from ChatGPT converts at 11.4%, 54% above the average for every other source, direct traffic included. And the infrastructure to capture that value is being built around an aggressive pricing strategy: ChatGPT's referral fees sit well below the take rates Amazon (15.8%), Walmart (15.0%), or eBay (10.9%) charge today — the same "come in cheaper, grab share" play Amazon used to eat traditional retail alive twenty years ago, now aimed at who controls the transaction, not just the catalog.

And there's no irony to spare here: the same firm telling you only 15% of retailers use AI to recommend products is the one rating the 19 vendors already selling it to them.

Gartner's Magic Quadrant for Digital Commerce, published on November 3, 2025, evaluates 19 vendors (Adobe, Salesforce, SAP, Shopify, commercetools, among others) and confirms that investment in AI capabilities and agentic commerce is already part of the roadmap for every major platform in the category. This isn't an early-adopter bet. It's the direction the entire category is moving in.

And the business case for moving now isn't new, it's just gotten more urgent: companies that get personalization right generate 40% more revenue from those activities than the industry average, according to McKinsey — a 2021 figure none of the platforms Gartner evaluated has managed to overturn in four years, precisely because the underlying problem (connecting signals, not stacking up tools) hasn't changed.

Even so, the gap between what the customer expects and what the retailer delivers remains enormous: only 15% of retailers use AI for product recommendations, and only 10% have automated inventory management with AI, according to Quid's State of AI in Ecommerce Report (2025), against 58% of customers who already prefer that kind of recommendation. That gap between demand and delivery capability is, right now, the cheapest competitive advantage in ecommerce. You don't need to convince the customer of anything — you need to build what they're already asking for.

What this means for whoever's in charge, not whoever's implementing

No ecommerce director needs to understand the technical architecture of a conversational agent. They do need to ask themselves three questions before signing off on the next AI project:

• Does this agent share what it perceives with the rest of the systems, or does it just add another silo with an "intelligent" label on it?
• Do we know, precisely, which decisions the system can act on alone and which ones need human governance — or are we figuring that out as we go?
• Does the customer notice a more coherent experience, or do they just notice there are now more chat windows?

If the answer to any of the three is "we don't know," the project isn't ready to scale, no matter how good the demo looks.

The cognitive layer isn't a fancier AI layer, it's the one that decides how the ones you already have coexist, and the one that turns every new agent into an improvement to the whole system instead of one more tool someone has to check by hand.

To wrap up, because you already know I'm a sucker for numbers: this article draws on twelve different sources, and more than a few years of personal bias, which is the polite way of saying experience.

I split them into two camps: the consultancies (Gartner, McKinsey, IBM) see moderate growth and a challenge that's mostly emotional — trust — while the product platforms see explosive growth and a challenge that's mostly technical. Neither side talks much about the conflict the other one clearly sees. And both agree, without ever having compared notes, on the same vanishing point: control, trust, and verified data as the lever that actually matters.

Two ways of seeing the world, one point of connection we believe in.

At Pleg, we're designing exactly this layer for several ecommerce teams who already have agents deployed but no logic coordinating them. If you want to see how we're building it, or just compare notes on where your organization stands on this axis of perception, governance, and autonomy, let's talk.

Thanks to Generative AI, CRO is evolving from traditional A/B testing toward real-time adaptive contextual personalization. AI no longer just assists with content creation — it calibrates the interface based on who's browsing and when. But the real strategic challenge has shifted sides: how do you personalize at scale without tanking latency, hurting SEO, or fragmenting brand identity?

Below, we break down GenAI's impact on every layer of the optimization workflow, and in upcoming posts we'll cover best practices for Safe-UX with Generative AI and the profile of a CRO Specialist working with AI, plus FAQs.

The evolution of CRO: from static A/B testing to hyper-personalization

The limit of traditional A/B testing: "one-size-fits-all" optimization is no longer enough

For years, the reigning methodology in Conversion Rate Optimization (CRO) has been the classic A/B test, where we split traffic 50/50 between a control version and a variant. After gathering enough data volume to reach statistical significance, we declare a single winner.

However, this approach rests on a fundamentally flawed premise: the assumption that a single "winning" design exists capable of satisfying every user equally. The reality of modern web traffic is diverse and unpredictable. We treat the audience as a homogeneous block when, in fact, two users landing on the same page can differ radically in search intent, channel of origin, digital maturity level, and context.

"One-size-fits-all" optimization is hitting a performance ceiling: by applying one fixed variant to the entire audience, we force profiles with opposing needs through the same funnel, losing valuable opportunities within a data-driven CRO strategy for secondary segments.

What changes with Generative AI in the conversion pipeline?

The arrival of Generative AI (GenAI) breaks the bottleneck of the various static A/B testing formats, letting the experimentation cycle scale up to real-time dynamic hyper-personalization.

GenAI doesn't just act as a writing assistant to churn out copy faster — it's an active engine driving this new paradigm of web personalization:

• Contextual variant generation: automatically adapts micro-copy, the tone of the value proposition, and visual elements based on user input signals (search keywords, browsing history, device, or B2B firmographics).
• Adaptive models (Multi-Armed Bandits): instead of waiting weeks with traffic split 50/50, dynamic allocation algorithms continuously evaluate variant performance. If the AI detects that variant C performs better for mobile traffic coming from social media, it redirects that segment to it immediately.

We move from a slow, linear pipeline to a living ecosystem where the interface continuously mutates and optimizes itself in real time.

The main challenge: personalizing in real time without sacrificing brand consistency or technical performance

Implementing Generative AI at the interface layer isn't friction-free. The real challenge of this model isn't the technical ability to generate variants — it's controlling the side effects on user experience and web infrastructure:

• For the UX/Product team: there's a real risk of fragmenting visual and narrative consistency. If AI alters text or design patterns without limits, the brand risks losing its identity, drifting away from its Design System, or, in the worst case, falling into inconsistencies and hallucinations that erode trust.
• For the Technical/Engineering team: modifying content "on the fly" from the browser usually means uncoordinated calls to external models or heavy client-side scripts. This causes the dreaded flicker effect (visual flashing or jumping during load), spiking Cumulative Layout Shift (CLS) and delaying Largest Contentful Paint (LCP). Wrecking Core Web Vitals hurts SEO rankings and destroys conversion itself.

The strategic goal of modern CRO is achieving personalization in milliseconds: applying technical guardrails (Edge/Server-Side architectures) and design guardrails (locked-down Design System components) so AI can alter content safely and transparently to the user.

GenAI in the CRO workflow: 3 layers of impact

Layer 1: mass generation of hypotheses and variants (Copy & UI)

Creating ad-hoc micro-copy based on search intent, traffic source, and user maturity level

In the traditional model, the CRO bottleneck usually wasn't technical implementation, but creative and writing capacity. Designing personalized variants for five different segments meant manually writing dozens of value propositions, calls to action (CTAs), and headlines.

Generative AI transforms this process by acting as a mass, context-based variant generation engine. Industry reports like Gartner's highlight content creation as one of the top use cases for GenAI. By ingesting real-time input parameters (source ad keywords, UTM parameters, device, location, or B2B firmographic data), language models can dynamically generate tailored micro-copy:

• Based on search intent: if a user arrives searching for "cheap accounting software," the headline can emphasize cost savings. If the search is "accounting software to scale my company," the message automatically pivots toward automation and process integration.
• Based on maturity level: a returning visitor who's already read three blog posts doesn't need the same explanatory value proposition as a cold visitor. AI can adjust message complexity and offer type to match the exact stage of the funnel.

This capability isn't limited to text. Integrated with modular design systems, or applied through a practical guide to Multivariate Testing (MVT), AI can select layout variants, adapt images contextually, and even adjust screen information density with no direct human intervention.

Layer 2: dynamic allocation algorithms (Multi-Armed Bandits vs. A/B tests)

How AI redirects traffic in real time toward winning variants, without waiting weeks for statistical significance

One of the biggest drawbacks of conventional A/B testing is the opportunity cost during the testing phase. In a test with a 50/50 traffic split, 50% of visitors keep getting a lower-performing version for however long it takes the experiment to reach statistical significance (often weeks or months).

Bringing AI into the decision infrastructure replaces fixed traffic splitting with reinforcement-learning algorithms known as Multi-Armed Bandits (MAB):

• Continuous traffic evolution: the algorithm initially assigns a small fraction of traffic to each variant. As it gathers real-time conversion data, it dynamically redirects a growing share of users toward the variants performing best for each given profile.
• Lower conversion cost: instead of "wasting" impressions on losing variants for weeks, the system progressively routes traffic toward the most efficient options, maximizing the total number of conversions recorded even during the testing period itself.
• Contextual optimization: while an A/B test tries to determine which variant is best overall, an AI-driven contextual bandit algorithm identifies which variant works best for a specific type of user at a specific moment.

Layer 3: automated qualitative analysis

Synthesizing thousands of survey responses, user feedback entries, and session transcripts into clear friction patterns

Quantitative analysis tells you where users drop off in the funnel, but qualitative analysis explains why. Until now, processing qualitative information was slow and prone to bias: reviewing hundreds of session recordings, reading exit-survey comments, or analyzing user interview transcripts took dozens of hours of manual work.

Generative AI solves this bottleneck by acting as a qualitative analyst at scale, capable of processing huge volumes of unstructured data — even leaning on advanced methodologies like synthetic users in CRO research:

• Real-time friction clustering: models can process thousands of free-text responses (such as intent surveys or checkout feedback) and automatically group them into friction categories (e.g., "uncertainty about shipping costs," "payment method failures," or "unclear warranty terms").
• Sentiment analysis and transcripts: it's possible to analyze customer support transcripts or B2B sales calls at scale to spot recurring doubts or objections that the landing page isn't addressing.
• Automatic hypothesis generation: by cross-referencing these qualitative patterns with quantitative analytics data, AI doesn't just pinpoint the drop-off point — it proposes optimization hypotheses grounded in the exact words and objections users themselves expressed.

Conclusion: CRO shifts from being an event to being a living ecosystem

Bringing Generative AI into the optimization workflow doesn't mean replacing CRO methodology — it means freeing it from its traditional bottlenecks. Moving from rigid A/B testing to dynamic personalization lets you iterate hypotheses at unprecedented speed and eliminate the opportunity cost sitting in unoptimized traffic.

That said, the competitive edge won't go to whoever generates the most AI content variants, but to whoever implements the right brand and technical architecture guardrails. Hyper-personalization only works if the user never perceives the friction: minimal latency via Server-Side/Edge delivery, consistency guaranteed by the Design System, and a strategic vision that puts user experience at the center.

References and bibliography

• CXL. (n.d.). A/B Testing Guide: Beginner to Advanced Methodology.
• Braze. (n.d.). Multi-Armed Bandit vs. A/B Testing: When to Use Which.
• McKinsey & Company. (2023). How generative AI can boost consumer marketing.
• Ideario Digital. (n.d.). Tipos de tests A/B en web: Guía completa.
• Ideario Digital. (n.d.). IA y personalización web: El nuevo paradigma de optimización
• Ideario Digital. (n.d.). Estrategia de CRO y optimización basada en datos
• Persado / Gartner Report. (n.d.). Gartner Identifies AI-Generated Marketing Content as a Top Use Case for Generative AI
• VWO. (n.d.). El algoritmo Multi-Armed Bandit explicado para experimentación web
• Optimizely Support. (n.d.). Run a multi-armed bandit optimization in Feature Experimentation
• Ideario Digital. (n.d.). Usuarios sintéticos en CRO: Investigación con IA
• Ideario Digital. (n.d.). Calculadora Bayesiana para A/B Testing
• Ideario Digital. (n.d.). Guía práctica de Test Multivariante (MVT)

If your supply chain still plans in monthly cycles and signs off decisions in weekly meetings, here’s the bad news: your competitors already make those decisions with AI agents under human oversight. Worse: the data says it works.

Spend on supply chain management software with agentic AI will grow from under €1.8Bn ($2Bn) in 2025 to around €46Bn ($53Bn) in 2030 ^[1], and Gartner predicts that by 2031, 60% of supply chain disruptions will be resolved with little to none human intervention ^[2]. This isn’t a fad. It’s a paradigm shift to autonomous orchestration, combining processes, people and ways of working with AI.

First, let’s bust a myth: automating is not delegating. Automation replaces repetitive tasks; delegation hands over operational decisions (and, increasingly, strategic ones) to systems that can sense, reason and act within defined guardrails.

Traditional plan-review-correct cycles are giving way to near-real-time decision networks run by cognitive agents. In this model, supply chain stops being a cost center and becomes an engine of dynamic resilience: it captures margin in real time by adjusting prices, flows and inventory in volatile markets, instead of documenting the problem three weeks late.

Just another fad? If you’re wondering, here’s why it’s real: 2 in 3 companies plan to make significant progress toward autonomy over the next decade ^[7], and 69% of surveyed operations executives admit that failing to adopt AI will put them at a competitive disadvantage.

The uncomfortable truth: only 28% have a low-touch supply chain today ^[16]. Walk the talk is the next real battleground.

Function by Function: Where Autonomy Already Delivers Value

End-to-end autonomy isn’t something taken for granted. It’s built brick by brick tying every investment to each function’s pain point to address. Here’s what the evidence supports today, function by function, with examples:

• Planning (S&OP, forecasting). Traditional statistical forecasting, as we know it today, is dying: 70% of large organizations will adopt AI-based demand forecasting by 2030, aiming for “touchless forecasting” that removes recurring manual intervention ^[3]. Planning shifts from periodic cycles to continuous demand sensing and daily granular optimization, and product design connects to market signals from day one.
• Procurement and Sourcing. This is where agentic maturity is highest today, precisely in structured, transactional processes (P2P, source-to-pay) ^[15]. Agentic orchestration can free up around 60% of procurement team capacity for strategic work ^[14]: better negotiations, tighter supplier risk management and no more chasing invoices.
• Manufacturing and distribution (IT/OT, warehousing, logistics). Smart factories and hybrid warehouses (robots + people) already deliver measurable results: up to −28.4% operating cost and +21.8% warehouse efficiency in advanced automation deployments ^[8].
• Sales, aftersales and customer service. The emerging frontier is agentic commerce: agents that don’t just handle issues but proactively pick the most profitable, satisfying fulfillment option for each customer. When your customer also buys through an agent, the question changes: you’re no longer designing experiences only for people, but also for the AI agents acting on their behalf ^[13].

The Impact Is Multidimensional: Process, Technology and People

Autonomous tech on broken processes just creates chaos faster. The three lenses don’t change. They’re the three pillars, no exceptions:

• Process redesigned end-to-end to break down silos before agents orchestrate it.
• Technology, where the real differentiator isn’t the control tower but the semantic layer: knowledge graphs that let an agent understand business context, not just correlate numbers.
• People, the most fragile pillar. Here’s the trust paradox: only 27% of organizations trust fully autonomous agents, down from 43% a year ago ^[6]. Yes, you read that right: trust is falling while investment rises. It’s reality catching up with early hype, and it’s healthy if managed well.

Value Levers: What Makes the Business Case

One warning before the table: autonomy without metrics is an act of faith, and acts of faith don’t survive an investment committee.

Each dimension in the table is an agentic improvement lever. Setting direction means turning them into measurable targets, each with a baseline, a target and an owner:

• Pick a few levers you can measure. Cost improvement, inventory reductions, margins enhancement, increase productivity, freed-up capacity, increase resilience, improve sustainability and lower the emissions: that’s the menu. Pick the two or three where the pain is real, baseline them before deploying the first agent, and set targets using the table’s ranges as an order of magnitude ^[7][10][11].
• Measure the P&L, not activity. A lever only counts if it moves EBITDA, ROCE, working capital or service level ^[7][11]. “Tasks automated” or “tickets resolved” are activity metrics: they dress up reports, they don’t justify investments.
• Make measurement your scaling engine. Each validated lever funds the next phase (self-funding) ^[8] and is what defuses the trust paradox: you defend autonomy with proven results, not promises ^[6].

Adoption Challenges: What Nobody Puts in the Brochure

Here’s what the vendor won’t tell you in the demo: Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value or inadequate risk controls.

It also estimates that of the thousands of vendors calling themselves “agentic”, only about 130 really are. It calls the rest “agent washing” ^[5].

The structural obstacles are well known and stubborn:

• Data quality. The number one barrier, according to procurement leaders themselves: without clean, harmonized data, AI can’t make reliable decisions ^[15]. IDC puts a number on it: companies that don’t prioritize AI-ready data will lose 15% in productivity when trying to scale ^[17].
• Trust and governance. The drop from 43% to 27% in trust in full autonomy ^[6] won’t be fixed by evangelizing. It takes transparency, traceability and autonomy earned in stages.
• Security and IT/OT convergence. Connecting the shop floor to the decision layer expands the attack surface and opens the door to “dark operations”: agents making unwanted decisions in unsupervised environments.
• Legacy systems and fragmentation. Integrating agents into legacy systems is technically complex and expensive; Gartner notes it often pays to redesign the workflow from scratch rather than patch the existing one ^[5].
• The human factor. 95% of executives believe they’ve provided adequate training, but only 20% of employees feel like real contributors to the change ^[9]. That perception gap kills more projects than any technical limitation.

Strategic Recommendations: How to Execute Without Getting Burned

None of these is optional if the goal is autonomy in production, not another pilot for the annual report:

1. Make the transformation pay for itself (self-funding). Start with fast-payback operational quick wins (eg. route and load optimization, SKU rationalization, P2P automation) and reinvest the savings in bigger capabilities (semantic layer, control tower, planning agents). It’s the most pragmatic, viable approach.
2. Data readiness in parallel with agents. Non-negotiable. Deploying agentic AI on inconsistent master data is burning budget. The right sequence: harmonize master data with data agents, establish ownership and measurable data quality, and build the semantic layer (knowledge graph) in parallel to give agents business context. Procurement leaders are unequivocal: analytics and AI create no value without good, reliable data ^[15].
3. Agentic governance: autonomy is earned, not granted. Define autonomy levels by decision type (inform → recommend → execute with approval → execute and report) and set mandatory “human release gates” for decisions with high financial or reputational impact. Gartner recommends exactly this: start with low-risk decisions and expand autonomy in a controlled way while building the data and governance foundation ^[2]. Every agent must be traceable, explainable and auditable. If you can’t reconstruct why it made a decision, it shouldn’t be making decisions.
4. Scale by pattern, not by hype. Start where maturity is real: structured transactional processes (P2P, order management, shipment tracking) ^[15]. Measure impact with business metrics (not activity), resolve the trust paradox with verifiable results, and only then replicate the pattern in more complex processes. And apply Gartner’s anti-hype filter: if the use case doesn’t need agentic intelligence, don’t throw an agent at it ^[5]. Cheap, deterministic RPA is still the right answer to many problems.
5. Redesign roles before the vacuum redesigns them for you. 43% of the function’s working hours will be affected: 29% automated and 14% augmented ^[9]. The human role shifts to “human-in-the-loop”: strategic oversight, decision design and exception management. That means investing in new skills (interpreting agents, AI governance, data management) and, above all, closing the engagement gap: make teams co-authors of the change, not spectators of the executive committee ^[9].
6. Set kill criteria as clear as your investment criteria. If over 40% of agentic projects will be canceled ^[5], make sure yours either die fast and cheap or scale on evidence. From day one, set the value, cost and risk thresholds that decide whether a pilot scales or gets shut down. The discipline to kill projects is as strategic as the discipline to launch them.

The provocative but honest conclusion: the autonomous supply chain isn’t here to replace the expert. It’s here to free your time from low-value tasks and decisions that a machine already handles better and faster, and move you up to the ones that need expertise a machine can’t provide.

Technology is no longer the main barrier ^[13]; leadership, process redesign and decision ownership are. The question is no longer whether your supply chain will be autonomous, but whether you decide how… or your competitors will leave you behind.

Acronyms

• P2P — Procure-to-Pay; the transactional procurement process, from purchase requisition to invoice payment.
• RPA — Robotic Process Automation; rule-based, deterministic automation of repetitive tasks, with no decision-making capability.
• S&OP — Sales & Operations Planning; the process that aligns demand, supply and finance in a single plan.

References

^[1] Gartner (2026.04.07). "SCM Software with Agentic AI Will Grow to $53 Billion in Spend by 2030"

^[2] Gartner (2026.03.18). "60% of Supply Chain Disruptions Will Be Resolved Without Human Intervention by 2031"

^[3] Gartner (2025.09.16). "70% of Large Organizations Will Adopt AI-Based Supply Chain Forecasting by 2030"

^[4] Gartner (2025.05.21). "Half of Supply Chain Management Solutions Will Include Agentic AI Capabilities by 2030"

^[5] Gartner (2026.06.25). "Over 40% of Agentic AI Projects Will Be Canceled by End of 2027"

^[6] Capgemini Research Institute (2025). "Rise of Agentic AI: How Trust Is the Key to Human-AI Collaboration" (informe adjunto al proyecto).

^[7] Accenture (2026.07). "Autonomous Supply Chain by Design" (TL Autonomous SC Design Report, documento del proyecto).

^[8] Accenture (2026.03). "Making Self-Funding Supply Chains Real" (documento del proyecto).

^[9] Procurement Magazine / Accenture (2026). "How AI Drives 23% Higher Supply Chain Margins"

^[10] McKinsey (2026.07.22). "Powering Supply Chains with Agentic AI" (podcast/transcripción, documento del proyecto)

^[11] BCG (2026.05). "Executive Perspectives: AI’s New Mandate in Supply Chains" (documento del proyecto).

^[13] Deloitte Canada (2026.04). "The Agentic Supply Chain" (documento del proyecto).

^[14] BCG (2026.07). "From AI Assistance to Agentic Orchestration in Procurement" (documento del proyecto).

^[15] The Hackett Group (2026). "Procurement Executive Insight Report 2026" (documento del proyecto).

^[16] EY (2026). "Autonomous Supply Chain Planning with AI"

^[17] IDC (2025.10.23). "IDC FutureScape 2026: The Rise of Agentic AI"

^[18] World Economic Forum (2025.11.03). "Why Autonomous Orchestration Is the Next Frontier in Supply Chain Management"

The conclusion is uncomfortable for both ends of the spectrum: employees afraid of losing their jobs, and decision-makers who, chasing cost savings, are laying off entire teams. AI is extraordinarily capable.

But there's one thing it's completely incapable of: making the right calls when nobody's steering. As I've said before, AI is our copilot, but the decisions are ours.

The context

I laid out the initial context: "SaaS platform for centralized record management, integration with external channels, subscription model." Working from an architecture PNG and 4 analytics spreadsheets as context, I pulled together a map of the client's current architecture, without much of a clue yet as to what path we'd end up taking.

After 2 meetings to figure out what the client wanted, and following those classic kickoff sessions where we dream up "ideal" solutions, we landed on a 15-microservice architecture. Documented APIs, data models, databases all designed.

Consistent down to every line, with an incredible level of detail.

It included a Transaction Service with Redsys (I steered it toward this solution based on integration level, since I'd spent several years working with payment gateways), an Analytics Service with an ROI dashboard, a Billing Service with Free/Premium/Enterprise tiers. The exact solution any architect would design facing those requirements. Ambitious, coherent, consistent — nothing a specialist could really object to.

Technically flawless.

After presenting the initial sketch, the validation process with the client revealed that the market and the business model called for a more measured approach. Transforming a business model is a complex process that demands moments of reflection to align the technology with day-to-day operational reality.

Strategic decisions get made by the people who live the business. Our role is to support that vision, understanding that technical design has to be an enabler, not an obstacle.

Iterating and adjusting scope

In an iteration-based process, the goal is to surface the possibilities that open up, letting the client decide which battles to fight at each stage. After analyzing the context, we decided to adjust the project's scope:

1. Prioritization: we identified functionality that, while valuable down the road, wasn't critical for the immediate launch.
2. Optimization: the roadmap was simplified, going from 15 services down to 3 essential ones, ensuring a more agile, realistic path to production.
3. The human factor: this decision came out of human judgment and commercial instinct — things technology alone can't replicate.

AI's role as support, not as guide

This case underscored how important direct communication is. AI, while extremely efficient at refining technical solutions, depends entirely on human strategic direction. When we pivoted to the new model, the technology adapted within hours, but the vision for that change was born out of meetings and notes shared between people.

The pattern that keeps repeating: volatility

This course correction isn't an isolated event — it's a constant in building high-level solutions. Over my 20 years in the field, I've seen firsthand that prioritization is a living organism: budget changes, technical challenges, or strategic pivots in the business model are our daily bread. What gets defined as essential today can stop being essential tomorrow, in favor of the project's viability.

In this landscape, the human factor is irreplaceable. Without precise communication of these changes, technology — and specifically AI — is limited to refining the instructions it was given before. AI is a management amplifier: if direction isn't updated with precision when the business throws a curveball, we risk amplifying the mistake instead of the win.

That's why the key to success isn't just technical capability — it's the agility to communicate a change in context and pivot the technology in real time.

The power of asking the right questions

A critical turning point came up in the technical proposal. The AI, working off abstract architecture patterns, initially suggested replacing the central record-management system with a new, independent microservice. The logic made sense from a theoretical standpoint: split off a consolidated system to modernize it.

However, after looking at how mature and stable the current system actually was (a platform with years of iterations behind it and multiple critical integrations), the strategic question shifted: do we actually need to replace what already works, or is it more efficient to evolve it?

The solution: hybridization and a focus on value

Instead of a full replacement that would have meant months of unnecessary risk and cost, we went with a smart-coexistence approach:

• Preserving the core: keeping the current system as the single source of truth, leaning on its robustness and stable APIs.
• Targeted innovation: designing a new, dedicated microservice for the new functionality that was actually the core of this evolution.
• Delivery agility: thanks to this "divide and conquer" approach, we were able to present a solid, validated execution plan even two days ahead of schedule.

This decision shows that AI can produce the textbook architecture, but only human judgment can determine whether that architecture fits the client's actual context. AI churned out the documentation and models for this new scheme in record time, but the strategic call to keep what delivers value and build only what's necessary is what made the proposal a success.

Why mass layoffs are a logic error

Organizations cutting technical teams because "AI does it now" are confusing execution speed with the ability to direct. As productivity rises, where two development roles used to be needed, now one person with good judgment will do. Does that affect us? Of course it does — but like everything in life, I think there's a middle ground.

AI brings speed. But direction is still a human responsibility, or it isn't direction at all.

A team of 5 people with well-directed AI produces more than a team of 20 without it. Cutting that team of five down to zero doesn't multiply productivity. It destroys it.

What disappears when you remove the person who actually understands isn't the code or the academic design — you eliminate common sense. That's the ability to know whether what you're proposing is really what you need.

The real shift

AI doesn't make technical knowledge irrelevant. It makes technical knowledge without judgment irrelevant.

What it amplifies is the capability of someone who:

• Understands the business and its constraints
• Knows what not to do (that's the hard part)
• Can communicate changes to the team
• Recognizes when the context has shifted

That person, with AI, produces what an entire team used to produce. But only if they know how to direct it. What matters isn't proposing components or writing code — it's deciding which components are actually needed, or what code to write. That's simply more visible now. AI executes at a speed that doesn't forgive a lack of direction: an architecture that used to take months to reveal its flaws now reveals them in weeks.

Conclusion

I don't think AI is going to replace people who know what they're doing. I think it's going to make the people who genuinely know what they're doing a lot more visible.

AI is an extraordinary amplification lever, but its real power lies in the fact that it amplifies whatever you feed into it. It's a multiplier of intent: apply good judgment, and you get an augmented, precise vision; apply confusion, and all you'll get is chaos scaled at a speed no human team could ever match.

In the project I described, AI didn't work instead of people. It worked with someone who knew what to ask, when to change course, and how to communicate decisions, at a speed that would have previously required an entire team.

The difference between that and a disaster came down to a handful of human decisions made at the right moment.

Projects move forward, teams keep delivering, steering committees meet, reports come in with positive news. But when you ask where the value is, what the impact is, what return we're getting, which initiatives should be accelerated or which ones should be stopped, the answers are no longer so obvious.

And that's where one of the biggest challenges facing many organizations shows up: it's not just about executing more, it's about improving the quality of the decisions that connect strategy, investment, capacity, and execution.

The traditional PMO is no longer enough

For years, project offices at large companies have played a critical role in helping organizations structure, govern, and professionalize project management. Thanks to them, many companies have managed to increase delivery capacity, improve control over execution, and reduce operational uncertainty.

But today's context demands something more. The speed of market change, digital transformation, new capabilities driven by AI, pressure to show faster results, and organizations juggling more initiatives than they can realistically absorb.

In this landscape, "just managing projects" is no longer enough. We need to be able to decide better. Decide which initiatives create the most value, decide where to invest, decide what to accelerate — and above all, decide what to stop doing. That's why more and more organizations are evolving from traditional project management office models toward value management office approaches. Not because they need a new office, but because they need a new way of connecting strategy, investment, capacity, and execution.

An evolution that means shifting:

• From measuring activity to measuring impact.
• From managing projects to managing portfolios and value chains.
• From tracking deliverables to validating outcomes.
• From rigid budgets to adaptive investment models.
• From static reporting to real-time, actionable information.
• From prioritizing by gut feeling to prioritizing by evidence.
• From keeping everything running to having the maturity to accelerate, pivot, pause, or stop.

Because a project moving forward doesn't always mean value is moving forward.

A project can be on schedule, within budget, with flawless reporting, and still not be generating the impact that justified the investment in the first place. In the same way, an initiative might need to change direction because the context has shifted, because the original hypotheses didn't hold up, or because higher-value opportunities have emerged.

That's where a VMO (Value Management Office) can make the difference.

VMO and its key capabilities

It's not just about knowing whether projects are moving forward. It's about knowing whether they're still the best way to move forward toward the organization's strategic goals.
To get there, a VMO needs to build several capabilities:

1. The first is strategic portfolio management: deciding which initiatives get in, which ones continue, which ones should make room for other priorities. Prioritizing isn't sorting a list once a year, it's keeping the conversation alive about where it's still worth investing.
2. The second is value measurement. It's not enough to measure completed tasks, milestones hit, or percentage of progress. We need to connect outputs to outcomes: what we deliver, what changes because of what we deliver, and how that change impacts the business, customers, people, or operations.
3. The third is capacity management. Many organizations don't fail because they lack strategy — they fail because they have more open initiatives than they can actually absorb. Without a realistic view of available capacity, strategy risks becoming little more than a statement of intent.
4. The fourth is building decision cadences. The difference isn't having better dashboards, it's creating spaces where business, technology, and operations review the information that matters, compare what they're learning, manage dependencies, and make timely decisions.
5. And the fifth is organizational learning. A mature VMO doesn't just watch metrics — it also helps the organization understand what it's learning, which patterns keep repeating, which capabilities need developing, and which ways of working need reinforcing to deliver value more sustainably.

At REV by Paradigma we've spent years helping organizations through this kind of evolution, and there's one thing we've learned over and over: the most resilient organizations aren't the ones executing the most projects — they're the ones that best understand where to create value and can adapt their decisions in time when the context shifts.

That's why our vision of a VMO goes well beyond a tracking or governance office. We see it as an organizational capability that helps align business, people, technology, and execution under one common direction.

And to get there, we don't just build a better PMO with new processes, tools, or governance mechanisms. We help build more adaptable organizations by combining multiple solutions and initiatives spanning everything from portfolio management, value-based prioritization, capacity management, organizational design, leadership development, role evolution, knowledge management, impact metrics, communities of practice, effective use of artificial intelligence, and many other solutions — all with the same core goal: connecting strategy and business.

Conclusion

Evolving toward a value-driven mindset requires building much deeper organizational capabilities and a culture grounded in transparency, shared accountability, data-driven decision-making, and continuous learning. You need a shared language for what "value" actually means. You need to define metrics that are actually useful. You need transparency to see what's happening, and shared accountability to act on it.
You also need to accept an uncomfortable truth: prioritizing means giving something up.

If everything is a priority, nothing really is. If every initiative keeps getting greenlit, if nothing ever gets reviewed, if nothing ever gets stopped, and everything competes for the same capacity, the organization ends up generating nothing but scattered effort, friction, and lost focus. This shift also demands rethinking how we fund initiatives, moving toward more incremental, flexible models that can adapt as the context changes and new information emerges.

A VMO helps precisely by making those tensions visible. Not to replace business judgment, but to improve the quality of the conversations different areas need to have together.

No methodology transforms an organization on its own. It's culture, leadership, and decision-making mechanisms that turn that vision into something that actually holds up over time.

Adaptive organizations have the competitive edge that separates the ones that evolve from the ones that get left behind. In a world where scope keeps shifting, priorities keep evolving, and uncertainty is just part of the day-to-day, the organizations that stand out aren't the ones running the most projects — they're the ones that innovate, prioritize, and decide where to put their time, money, and talent better than anyone else.

The challenge is no longer just having more data — the challenge is turning it into better decisions. And maybe that's the real evolution many organizations still have ahead of them: stopping at just asking how much progress we've made, and starting to systematically ask what value we're generating, what we're learning, and where it's still worth investing.

Moving from managing projects to managing value isn't about renaming an office — it's about evolving the organization's capabilities.

There's a move almost everyone repeats the first time they try building a mobile app with an AI agent: open the chat, ask it for the entire app in one go, and sit back and wait. A few seconds later you've got screens, navigation, and something that compiles. It feels like magic.

That feeling lasts right up until you try to build the second feature on top of the first one.

Because a model never tells you "I don't know." It always hands you something that looks finished, even when it isn't. And if you haven't marked out the path, that "something" comes from what the model assumes you wanted, not from what you actually wanted. It wanders off, goes its own way, makes its own calls. For an afternoon experiment, that's perfectly fine. For an app headed to production, it's where the problems start.

The problem isn't that it fails — it's that it never fails

An AI agent always hands you a solution because that's exactly what it's trained to do: fill the gap with the first thing that lets it deliver something. And that's the risk: it hands back an answer that looks finished but almost never respects what you've already built, and it doesn't warn you about what it made up along the way.

Anyone who's seriously tried this will recognize the example. Throughout this series, we're going to build a shared-expenses app — the kind you use to split what a group spends (a dinner, a trip, a shared flat) and figure out who owes who at the end.

So, we start by asking the agent for the add-expense screen, and instead of following the project's architecture, it takes the fast lane. All the logic — UI, API calls, split calculation, parsing, persistence — crammed into a single giant class.

// A screen that does EVERYTHING at once:

class AddExpenseActivity : AppCompatActivity() {
    private val db = AppDatabase.get()    // data
    private fun save(amount: Double, payerId: String) {
        lifecycleScope.launch { 

        // business rules stuffed into the UI:

            val members = db.groupDao().members(currentGroupId)
            val share   = amount / members.size   // split
            members.forEach { m ->

             // persistence

                db.balanceDao().add(m.id, share, payerId)                          
}
         // and while it's at it, syncs with the backend right here:

            // direct API call

            val res = api.post("$BASE_URL/expenses", body)
            Json.decodeFromString<ExpenseDto>(res) // parsing
            runOnUiThread { showBalance() }        // UI + state
        }
    }
    // ...and below that, 400 more lines drawing the form.
}

It compiles, it works in the demo, but you've just broken one of the most expensive rules to break on mobile (the UI calling the backend directly, with the split baked right into the screen), and the next screen is going to be built on top of it.

If we repeat this on the balances screen, the settle-up screen, and the create-group screen, we'll realize we no longer have an app — we have a snowball, where every new piece drags along the mess from the last one, and untangling it costs more than doing it right from the start.

The first time you run into something like this, it takes a while to sink in, because even though it "works," the solution doesn't hold up. The code is there, it compiles, and the demo goes fine — but the problem was never that one file: it was that every file after it was going to copy its bad example.

That's the trap of asking and waiting: it doesn't break on day one, it breaks on day 20.

Defining is the new craft

Well defined, that same agent gets you moving at a speed that didn't exist two years ago. And the whole difference fits in one word: defined.

The more you break the task down and the more tightly you close off what you're asking for, the less room you leave the model to fill in with what you didn't want. Asking for "the add-expense screen" and leaving it at that is not the same as scoping the request so tightly there's no room left for improvisation:

The same screen, tightly scoped:

• Task: Composable AddExpenseScreen — UI only
• Follows the existing ui/domain/data layer pattern
• No business logic or backend calls from the screen
• The split is calculated by the SplitExpense use case (already implemented)
• Persists to the local DB. Syncing isn't this layer's concern
• States: loading / error / data

One task, one scope, one layer.

If you notice, the second version doesn't leave the agent a single decision it can make up on its own: the split calculation lives in its own use case, persistence lives in the data layer, syncing lives somewhere else. The screen just renders. That same task, directed with this level of precision, usually comes out right on the first try. And when it doesn't, the failure is contained to the UI: there's no need to chase it across five tangled responsibilities.

The concrete difference shows up best when you contrast how it's asked:

// ✖️ Open-ended - the model decides the architecture for you
"Build me the screen for adding an expense to the group."

// ✔️ Scoped - you decide and the agent executes
"Composable AddExpenseScreen, UI layer only.
- Takes an AddExpenseUiState and emits events to the ViewModel.
- The split is resolved by the SplitExpense use case — do NOT calculate it here.
- No backend calls from the Composable.
- States to render: loading | error | data."

The first version invites the mega-class. The second one leaves no room to improvise. That's where the developer's job shifts: the skill isn't just typing code anymore, it's defining things precisely enough that the code coming out of the agent is yours, not its.

They're not using different models. They're defining things differently.

For me, that's the line that separates people who say AI "isn't good for anything serious" from people who actually use it to ship.

Start before the code: let the agent interview you

The first thing to do when starting an app isn't coding, it's specifying. We need to flip the usual script: instead of asking the agent to build, we ask it to interview us.

We give it the context of what we want and let it ask questions. It lays out the possible paths, puts the options on the table, tells us which one it recommends, and we make the final call. That interview brings to light the decisions we didn't even know we had to make — the same ones that, left unresolved, are exactly what turns into the snowball later on.

Example:

- You: "I want an app to track shared expenses."

- Agent: Are groups fixed, or created per event? Is the split even, or by percentage? Do you need offline mode from day one? My recommendation: groups per event, configurable split, no offline for now. Shall we go with that?

- You: Done: groups per event, configurable split, no offline.

In three questions, the agent has locked down three decisions that, left unasked, it would have assumed on its own — almost always the opposite of what we wanted. That's what specifying is: surfacing what you'd take for granted before the code takes it for granted on your behalf.

Out of that conversation comes, almost without trying, the scope of the first version. The shared-expenses app ended up looking like this:

Shared-expenses app MVP

• Create a group per event (a dinner, a trip).
• Add an expense and record who paid.
• Configurable split: even, or by percentage.
• Balance screen: who owes who.
• Settle a debt and mark it as paid.

Deliberately out of v1: in-app real payments, multi-currency, and offline mode.

Saying out loud what's not included is half the work. Three lines ("no in-app payments, no multi-currency, no offline") save the agent from the temptation to build a payment gateway nobody asked for, and save you the time of ripping it back out.

You don't need to lock everything down at once, either. It's enough to close off just enough that the first task has no gaps the model can slip through. The rest gets defined when its turn comes, one piece at a time.

Defining isn't writing a giant document before you start — it's not leaving any important decision to chance. Once those decisions are made, the next step is writing them down where the agent can check them while it codes (we'll get to that in the post about context) and breaking the "what" down into closed specs, which is a topic for another article altogether.

Specifying first isn't bureaucracy — it's moving the moment of thinking to before you write the code, when changing your mind costs one sentence instead of a refactor.

Loose to experiment, tight to ship

It's worth not mixing up two worlds that look alike but aren't. For a prototype, a quick test, or a weekend of tinkering, let the agent run loose: it's disposable, and the speed more than makes up for the mess. Nobody's going to maintain that.

For something headed to production, open-endedness comes at a cost, with interest. Every shortcut the model invents is technical debt someone — you, three months from now — will have to untangle. The difference between the fun experiment and the maintenance headache isn't in the agent: it's in how much discipline you put in front of it.

In the shared-expenses app, that discipline fits into one rule repeated to the point of boredom: the UI never talks to the backend. The screen asks the domain, the domain decides, the data layer saves locally, and the backend only comes in to sync.

Written down like that, the rule is trivial — and respected on every screen, it's the difference between an app that scales and a snowball.

// The layer that decides lives in domain/, outside the screen:
class SplitExpense(private val repo: ExpenseRepository) {
    suspend operator fun invoke(expense: Expense, split: Split) {
        val shares = when (split) {
            is Split.Equal   -> expense.equalShares()
            is Split.Percent -> expense.byPercent(split.weights)
        }
        repo.save(expense, shares)   // to the local DB; sync happens elsewhere
    }
}

The screen just calls SplitExpense and renders the result. It doesn't know how the split is calculated or where it's stored, and precisely because it doesn't know, the day the split logic changes, only this file gets touched. We'll get into how to chain these pieces together with the agent without it skipping layers in another post about development.

Natural language: one more layer, not a threat

A lot of people still resist this, and almost always for the same reason: they'd rather see and touch the code with their own hands. I get it, I come from that world too, but I think that's looking at the shift from the wrong angle.

In the beginning, we programmed the processor directly, in assembly. Then high-level languages arrived, and we stopped fighting with registers and memory. Every leap hid the layer below so we could think at a higher level. Directing an agent in natural language is the next rung on that same ladder: one more layer of abstraction, not the disappearance of the craft.

And just like every leap before it, we still need to know what we're building. Whoever coded in C understood what was happening underneath; whoever directs an agent has to understand the architecture they want, or the agent will make it up.

In the expenses app, if we're not clear that the split logic lives in the domain layer and not on the screen, the agent decides — and decides badly, not because it's clumsy, but because nobody told it where each thing belonged.

Abstraction frees you from the keyboard, not from judgment.

Conclusion

The invitation is straightforward: try it for real, and do it right. Don't ask for everything at once and expect it to turn out well. Define it, break it into pieces, let it interview you, and direct it yourself. Speed shows up on its own once the foundation is locked down.

In the next articles in this series, we'll look at exactly how to lock it down, phase by phase: the context the agent reads before touching anything, the skills you use to teach it to do things your way, the specs that break the work into pieces, and finally, development.

If there's one line to take away from all this, let it be this: with an agent, the bottleneck is no longer writing the code — it's knowing exactly what you want.

The shared-expenses app we'll be building throughout this series isn't going to fall apart because of the model. It'll hold up based on what we lock down before it writes the first line. And that part, fortunately, is entirely up to us.

The effect of problem management on projects is an almost endless chain of decisions that, at times, drives the business, the technical team, and the management profile that arranges and monitors them as a servant leader to distraction. To handle disagreements and bring some order, we usually turn to a prioritization matrix if we're in a sensible, coordinated context. If we're in a different context, we fall back on experience by similarity, and if not, on impulsive decisions based on perceptions, urgencies, or fears.

The problem isn't that problems exist. The problem is treating them all the same. Problems aren't challenges, but they can be challenging. Poorly conceptualized challenges (true need, sponsorship, expected outcome, deviations) turn into problems.

Cynefin: understanding the context first

Almost three decades ago, Dave Snowden taught us about Cynefin and the 5 context domains where problems live:

• Clear/Simple: a stable, obvious, and known cause-effect relationship. Standards exist and no experts are needed.
• Complicated: the cause-effect relationship exists but isn't obvious; you need to analyze it or bring in specialists to find it. More than one correct solution exists once diagnosis is done.
• Complex: the cause-effect relationship can only be understood in hindsight, because the system has many interacting variables that are hard to visualize, with emergent and unpredictable results. Since no established best practices exist, challenges are approached experimentally.
• Chaotic: no cause-effect relationship can be discerned, either before or after, since the environment is in crisis and/or changing too fast. The approach is to first stabilize, then observe, and then try to establish some order toward standardization.
• Disorder: a state in which it isn't clear which domain you're in; there's confusion, and each actor interprets the situation according to their own bias. The goal is to diagnose and classify the situation, moving the problem into one of the four domains above so it can be acted on appropriately.

It's an abstract taxonomy that lets us pinpoint the nature of the challenge. Before solving, it's worth understanding what type of context we're operating in. There are also frameworks and methodologies that define problem typologies more closely tied to a specific area of work.

ITIL: incidents and problems are not the same thing

In ITSM, there's the classic ITIL approach to problems/incidents from a proactive or reactive standpoint, assessing them with the simple and effective impact and urgency matrix.

ITIL reminds us of something basic: putting out the fire and understanding why it started are not the same activity.

Aware that both coexist within a continuous improvement approach, ITIL establishes a framework to reduce the probability of impact and places emphasis on avoiding recurrence by learning from experience. To do this, it distinguishes between incidents and problems:

Incident management

• Objective: restore the service quickly, "put out the fire," even by rolling back changes or using workarounds.
• Horizon: short term, focused on operational continuity and user experience.

Problem management

• Objective: understand why incidents occur and how to prevent them from recurring, through structured root cause analysis.
• Horizon: medium to long term, focused on service stability, reliability, and continuous improvement.

In practice, a serious or recurring incident usually triggers the opening of a problem to investigate its causes. And the findings from problem management usually give rise to change requests to permanently fix the service.

A matrix for executive problems

If what we need is an order of magnitude and logic for executive-level problems, one that isn't purely tied to technology nor as abstract as Cynefin, I'd like to propose a matrix combining two well-known typologies that you might find inspiring.

I base it on combining Peter Drucker's typology with Art Smalley's:

Peter Drucker's generic typology

Peter Drucker distinguished four types of problems that appear in organizations based on how they arise and persist:

1. Truly generic: cases that are symptoms of a recurring pattern within the organization — today we would call them "systemic." Drucker explains that most problems are of this nature, and that although symptoms may vary in how they manifest, they are just adaptations of the original. This clears the path considerably if we're able to find the root cause.
2. Unique: your organization experiences them only once, but the situation is common in other organizations. They aren't anomalous or rare, and you can seek support by looking at similar situations faced by competitors or partners.
3. Truly exceptional, truly unique: singular situations that can't be treated as textbook cases; they usually have complex, multifactorial causes that rarely converge again.
4. Early manifestations of a new generic problem (Earlys): weak signals of a trend that will become recurring if not addressed. Extremely interesting and profitable to tackle before they contaminate the ecosystem.

From my experience in Lean, this classification forces you to decide whether to act with improvement responses (Kaizen), design new policies (Kaikaku), or engage in deeper strategic reflection (Kakushin).

Art Smalley's typology

Art Smalley also proposes four types of problems, but from the angle of how they're approached:

1. Troubleshooting: a reactive response to "stop the bleeding" and return the situation to the known standard as quickly as possible.
2. Gap from standard: using structured problem-solving to eliminate root causes preventing the standard from being met. The measures remain reactive but systematic and planned.
3. Target state: a proactive, continuous-improvement approach aimed at reaching a performance level better than the current one, defining a new standard.
4. Open-ended: proactive, creative exploration of radical solutions or new models that go well beyond current levels of value.

Each type calls for different methods, management cadences, and mindsets. All of them share, as their guiding axis, their relationship to the standard as an ideal.

Crossing the nature of the problem with its method of resolution

What I apply in projects is a combined matrix. Its power lies in crossing the nature of the event (Drucker) with the resolution methodology (Smalley). This avoids the classic mistake of applying "engineering solutions" to "management problems", or vice versa.

Drucker helps you understand the nature and recurrence of the problem within the system, while Smalley points you toward the practical resolution approach from Lean.

How to use this matrix in projects

This matrix lets you categorize any deviation in a project and select the appropriate resolution "style." You can start from the row (Drucker): is this problem generic, unique, exceptional, or an early signal of something that will recur? Then you choose the column (Smalley): should we contain it, tackle a deviation from standard, pursue a target state, or open up a space for innovation?

Consciously using this double classification helps avoid two very common mistakes: treating strategic crises as simple operational incidents, or, the other way around, using "innovation" when in reality it would be enough to standardize and fix a recurring deviation in the project. Both inappropriate actions are forms of Muda: management waste that should be identified and eliminated.

Problem management is a cross-functional effort: it requires participation from development, operations, security, business, and other teams to investigate causes and design effective solutions.
Once the process for approaching problems is established and understood, problems become the cornerstone of growth and adaptation: true treasures of the organization, levers of competitiveness and learning.

At Rev by Paradigma, thanks to our experience in agility, lean, and digital product design, we build simple processes for approaching problems in situational or systemic circumstances, which can be surgical or sustained depending on our clients' needs.

Classifying a problem well doesn't automatically solve it, but it keeps you from starting in the wrong place. And in complex projects, that alone is a huge advantage.

References

• Cynefin Framework
• Snowden & Boone - A Leader's Framework for Decision Making, Harvard Business Review
• Peter Drucker - The Effective Executive
• Art Smalley - Four Types of Problems