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

This article reviews the scientific literature to test two hypotheses that argue for RAG's obsolescence: the redundancy of retrieval given extended context windows (1M+ tokens), and the displacement of this technique by agent-based systems. The data says otherwise on both counts, and it also explains why ignoring them costs you dearly.

If your system still retrieves information the way it did in 2023, this is for you. The question is no longer whether RAG is dead. It's how much context budget you're wasting without realizing it.

Has RAG really died?

You've probably seen the same headline on LinkedIn, "X," or in some technical newsletters: "RAG is dead." It's said with the same conviction as in 2022, when we were promised that prompt engineering would be the profession of the future, or in 2025, when we were assured that autonomous agents would leave us all jobless. Like every tech prophecy, there's some truth to it, but also a healthy dose of posturing.

Let's do what we do best: debunk the myths with data, not opinions.

In 2023, RAG (Retrieval-Augmented Generation) was a simple architecture: a question, an embedding, a fragment search (with luck, a re-ranker), a prompt, and done. It was a series of boxes with arrows, one after another, that got companies excited just by seeing it on a slide. In 2026 that architecture is history. Models handle context windows of a million tokens or more, agents grep through repositories, run SQL, call APIs, reformulate a search if the first one doesn't work, and carry working memory across steps. The four-box diagram no longer describes almost any real system.

Hence the controversy of the headline. But my position is different: RAG has not died. It has stopped being a closed-off solution to become a basic piece of engineering. The fact that it's just one more tool in the system, rather than the whole system, is proof that the technology has matured.

From an objective standpoint, what part of RAG really has died

Before defending RAG, I want to be honest with those who consider it buried, since they have a point. There are pieces of the 2023-era RAG that make no sense in a serious system today. I'm thinking, for example, of fixed top-k with no justification, of 512-token chunks just because, of using a single embedding as a universal search engine, or of relying on dense retrieval with no lexical component. That linear pipeline of five boxes in a row is, indeed, what has died.

There is a compelling technical reason for this shift. More than a failure of power, we've become aware of limits we used to ignore. When generating embeddings, we face an almost impossible balancing act: capturing a text's overall meaning while also distinguishing very fine-grained nuances. This is the so-called "granularity dilemma." Text encoders systematically fail when two passages share the same semantic field but differ in one specific entity or fact.

The interesting part is that model size doesn't solve this on its own. A recent study shows that a model of just 0.1B parameters, fine-tuned specifically for this task, outperforms 7B models (Xu et al., 2025). The failure isn't one of power, it's one of design. That's why a single vector search channel never was, and still isn't today, a solid foundation.

The exact same thing happens with chunking. Splitting into large blocks mixes different entities into the same vector and dilutes the nuance; splitting into tiny fragments gains precision on the entity but loses the context that gives it meaning. That's why the solutions that work in production don't look for an "optimal chunk size," but instead use schemes like hierarchical chunking: index the small fragment, but retrieve the paragraph or document that surrounds it.

Long context has also genuinely improved, and I won't dispute that with anyone. There are models today that support windows of one, two, or even ten million tokens, and this obviously shifts the rules a bit as to what's worth retrieving as a unit. Before, you had to chop up a document because it didn't fit whole. Now, in many cases, you can fit the whole document in. That's not marketing, it's a real architectural improvement. But this doesn't justify dumping the entire corpus into a prompt, and this is where the "infinite context" narrative starts to collide with the numbers and with reality.

Myth 1: "Giant context windows make RAG unnecessary"

This is the argument that grabs the most headlines: if models already handle windows of one or two million tokens, why bother retrieving anything? Just inject everything. The technical problem is that a model doesn't pay attention uniformly across that entire window. This phenomenon is known as Context Rot (or context degradation): the more information we inject, the more noise we introduce, and the worse the model reasons (Liu et al., 2024).

The RULER benchmark exposed this mirage back in 2024. At that point, although most models claimed to support windows of 32K tokens or more, only 50% maintained acceptable performance under real-world usage conditions (Hsieh et al., 2024).

The result that, in my view, most changes the perspective on this problem is NoLiMa. While RULER usually lets the model find the answer through mere lexical matching, NoLiMa removes that "hint" and forces the model to reason semantically. The results were revealing: of 13 models claiming to support contexts of at least 128K tokens, 11 dropped below 50% of their performance by the time they reached 32K. Even a benchmark model like GPT-4o went from 99.3% accuracy in short context to 69.7% under long-context conditions (Modarressi et al., 2025)*.

*Given the dizzying pace of new model development, it's essential to verify the specific versions and architectures referenced in Modarressi et al., 2025, before generalizing their results.

We should also consider that almost all of this evidence is measured in English. When this capability is tested across 26 languages at once, the performance gap between high-resource and low-resource languages triples as the window grows (Kim et al., 2025; Hengle et al., 2026; Wang et al., 2026; Qi et al., 2025).

All of this evidence points in the same direction:

Just because a model can afford the cost of reading a million tokens doesn't mean that million tokens is useful attention.

That's why I prefer to see retrieval not as a technique competing with long context, but as the manager of our budget. Every call to the model is a finite resource that we must divide between instructions, history, memory, and retrieved documents. Retrieval is the function that decides which part of the world deserves to occupy that space. The bigger the window, the more expensive it is to waste it. Retrieving information precisely is more critical today than ever.

Myth 2: "Agents replace RAG"

This is, in my view, the strongest argument from those who consider RAG dead. Let's examine it closely, though. Most agents decide their next step based on what they just observed, not on a fixed script, and at some point in that loop, the same question almost always comes up: what do I need to know before continuing? That question is retrieval, even if it no longer carries that label.

An agent doesn't follow a linear flow. It must plan, search, evaluate results, decide whether it needs more information, consult tools, and compare before writing a single word. Even when the search strategy becomes multi-level, the operational essence remains data retrieval. What has evolved isn't the act of retrieving itself, but the system's orchestrating intelligence to discern which channels to consult and exactly when to execute each strategy.

Current evidence shows that letting an agent perform exhaustive searches isn't just costly, it's often counterproductive. A recent benchmark, ContextBench, analyzed the behavior of different models (GPT-5, Claude Sonnet 4.5, and Devstral 2) operating as autonomous agents on hundreds of real incidents. The results dismantle the intuition that "more searching equals a better answer."

The analysis is clear: aggressive exploration, where the agent runs excessive rounds of search, drives up token consumption and operational cost, and, moreover, doesn't guarantee higher quality (Li et al., 2026). By contrast, models that adopt a moderate approach achieve a superior balance and reach better performance without needing to saturate the system with redundant queries. The lesson from all this is that aggressive exploration by agents only inflates spend, not accuracy. Reading more doesn't equal retrieving better.

In practice, what we're seeing consolidate in 2026 are hybrid pipelines that optimize resources. A successful pattern usually looks like this:

1. Initial retrieval: combine sparse representations (BM25) with dense embeddings to get a broad set (50-100 candidates).
2. Re-ranking: pass that set through a cross-encoder that computes real cross-attention between the query and each fragment.
3. Selection: keep only the 5 to 10 most relevant blocks before calling the generator model.

This approach is more expensive than a simple embedding, yes, but infinitely more efficient than saturating the LLM with a hundred random fragments. As confirmed by the study by Assadi et al. (2026), in semantic search, a good embedding model beats any combination that tries to use an LLM to re-rank results from scratch. Spending the expensive model where it isn't needed not only increases cost; it often doesn't even improve the result.

Another successful pattern, based on an architecture built around a reflective reasoning loop, usually looks like this:

1. Decomposition and planning: the agent receives the complex query and unfolds a dynamic planning graph to break the problem into sub-tasks, avoiding static sequences.
2. Intent routing: it evaluates the type of data required and routes each sub-task to the appropriate specialized retrieval tools (such as vector engines, structured SQL queries, or knowledge graphs).
3. Execution and retrieval: it runs queries against the selected channels to extract the necessary empirical evidence.
4. Self-reflection: it recursively assesses whether the retrieved evidence is sufficient, accurate, and relevant to resolve the query.
5. Automatic re-planning: if the internal relevance or data-sufficiency metric fails, the system triggers automatic re-planning to iterate or search new sources.
6. Evidential reasoning: it consolidates and adjusts its strategy in real time, using validated evidence to synthesize the final answer.

Obviously, this orchestrating sophistication raises a first-order pragmatic challenge: accumulated latency and cost per query. However, delegating every micro-decision of this loop to a frontier LLM is economically unsustainable. Architectures that scale apply a layered approach: they use embedding models and re-rankers (cross-encoders) to filter context efficiently, reserving the heavy LLM only for the final synthesis phase. This specialized filtering drastically reduces noise and operational cost, ensuring that only the highest-quality evidence reaches the reasoning model.

On the other hand, when a query requires connecting related concepts across multiple documents, vectors fail. This is where knowledge graphs solve the equation, allowing the model to reason over explicit connections.

These have proven superior to pure vector search (Pan et al., 2024; Chen et al., 2024). In the past, the problem was the cost of building the entire graph. But recent implementations like GraphRAG (Edge et al., 2024) and optimized solutions such as LazyGraphRAG (Edge et al., 2024), HippoRAG (Gutiérrez et al., 2024), or LightRAG (Guo et al., 2025) allow complex semantic relationships to be extracted with reduced indexing costs, with GraphRAG-bench (Xiao et al., 2025) serving as a key reference for evaluating reasoning capability in these environments.

Ultimately, this ecosystem of techniques (from hybrid retrieval to orchestration via agents and knowledge graphs) doesn't offer universal solutions. Success lies in the modular composition of these mechanisms according to the complexity and intent of each query.

So the useful debate in 2026 is no longer "RAG or agents?" The right question is: which retrieval mechanism should each agent use, at what point in its reasoning, and with what budget? The agent doesn't replace RAG, it absorbs it as an internal capability.

The metric we tend to forget: latency and cost

In corporate environments, the bottleneck usually isn't the technology, it's the budget. Forcing models to process immense contexts by default wrecks the economic viability of any product. Precision in filtering information isn't just a technical challenge, it's financial discipline so that the cloud bill doesn't eat into the business margin.

A million tokens costs money and time. Meanwhile, an efficient hybrid search filters data in milliseconds. Forcing the model to process the entire repository before writing the first word drives latency up to several seconds. For a conversational assistant, sending hundreds of thousands of tokens per call isn't just expensive, it's a terrible user experience. The goal in production is never to saturate the model with superfluous data, but to deliver, with great precision, the few tokens that actually determine the decision.

The providers themselves confirm this by launching features like context caching (Gemini's or Claude's context cache). These tools are a complement to smart retrieval, never a substitute, designed precisely so you don't have to pay for or wait on the same data over and over.

The data backs up this caution. Assadi et al. (2026) show that, although LLMs achieve competitive results, the cost is disproportionate. Using a model like Gemini 3.1 Pro for retrieval tasks can be up to 1,431 times more expensive than using a specialized embedding model. Moreover, LLM processing speed is drastically lower. In terms of efficiency, tokens devoted to "reasoning" account for between 28% and 81% of the total cost. Often, the model goes back and forth over relevance judgments it had already settled on the first read, inflating the bill without improving the result.

The lesson is clear:

Use embedding models for the bulk of the work and reserve the LLM for the final reasoning that truly needs it.

The question for anyone designing a generative AI system should no longer be "how many tokens does my model support?" but "what is the optimal context budget for each step of my system?"

So, what do we do with our 2023 RAG?

It's time to set aside theoretical debates and be pragmatic. If your current system is still anchored in 2023's assumptions, such as static chunking, blind vector search, and a rigid linear flow, it's only natural that the results fall short.

The problem isn't that RAG has died. The problem is that you're trying to solve today's challenges with an obsolete architecture. Your pipeline needs to stop being a simple search engine and become a decision-making system.

To modernize it, any production solution must answer these six critical questions:

1. What to retrieve? Precisely isolate the exact information that resolves the query, going beyond simple similarity.
2. When to act? Determine the precise moment for the query so as not to saturate the system with unnecessary searches.
3. How to search? Choose the right path (vector, lexical, structured, temporal, hybrid, or agent-assisted) based on the nature of the query.
4. Who has access? Guarantee security filters and user permissions before injecting any data into the context.
5. Is it still current? Validate the temporal freshness of the information to avoid feeding the model outdated data.
6. Where does it come from? Ensure full traceability and exact attribution of sources, a non-negotiable requirement for business decisions.

My hypothesis for 2026/2027

The term "RAG" has lost the spotlight to the agent narrative, but information retrieval hasn't disappeared. It has simply stopped being a standalone component. It no longer needs a name of its own because it is, quite simply, an inherent capability.

Retrieval is the connective tissue of the agent. Whether querying a database, a document, code, or an internal policy, the flow is constant: the agent determines the need, the system validates access, the retriever filters the content, and the model reasons over the selected information.

That's why "has RAG died?" strikes me as the wrong question for 2026. The real unknown we need to solve in every project is more technical and less about appearances: how much context budget are we wasting?

RAG should no longer be understood as a rigid architecture drawn on a slide, it's a basic function of any generative AI system. The bigger the context windows get, the more vital it becomes to execute this function with precision.

So:

What has died isn't RAG. It's your 2023 pipeline.

If you found this review useful, share it with anyone still arguing over whether "RAG is dead" instead of discussing how their system should be retrieving.

References

• Assadi, A. E., Muennighoff, N., & Lee, J. (2026). The Embedder's Dilemma: LLMs Are Better, but at What Cost?. arXiv preprint arXiv:2608.12875.
• Chen, Z., Zhang, Y., Fang, Y., Geng, Y., Guo, L., Chen, X., ... & Chen, H. (2024). Knowledge graphs meet multi-modal learning: A comprehensive survey. arXiv preprint arXiv:2402.05391.
• Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., ... & Larson, J. (2024). From local to global: A graph rag approach to query-focused summarization. arXiv preprint arXiv:2404.16130.
• Edge, J. L. D., Trinh, H., & Larson, J. (2024). Lazygraphrag: Setting a new standard for quality and cost. Microsoft Blog.
• Guo, Z., Xia, L., Yu, Y., Ao, T., & Huang, C. (2025, November). LightRAG: Simple and Fast Retrieval-Augmented Generation. In EMNLP (Findings) (pp. 10746-10761).
• Gutiérrez, B. J., Shu, Y., Gu, Y., Yasunaga, M., & Su, Y. (2024). Hipporag: Neurobiologically inspired long-term memory for large language models. Advances in neural information processing systems, 37, 59532-59569.
• Hengle, A., Bajpai, P., Dan, S., & Chakraborty, T. (2026, March). Can LLMs reason over extended multilingual contexts? Towards long-context evaluation beyond retrieval over haystacks. In Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 6128-6152).
• Hsieh, C. P., Sun, S., Kriman, S., Acharya, S., Rekesh, D., Jia, F., ... & Ginsburg, B. (2024). RULER: What's the real context size of your long-context language models?. arXiv preprint arXiv:2404.06654.
• Kim, Y., Russell, J., Karpinska, M., & Iyyer, M. (2025). One ruler to measure them all: Benchmarking multilingual long-context language models. arXiv preprint arXiv:2503.01996.
• Li, H., Zhu, L., Zhang, B., Feng, R., Wang, J., Pan, Y., ... & Ye, H. (2026). Contextbench: A benchmark for context retrieval in coding agents. arXiv preprint arXiv:2602.05892.
• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the middle: How language models use long contexts. Transactions of the association for computational linguistics, 12, 157-173.
• Modarressi, A., Deilamsalehy, H., Dernoncourt, F., Bui, T., Rossi, R. A., Yoon, S., & Schütze, H. (2025). Nolima: Long-context evaluation beyond literal matching. arXiv preprint arXiv:2502.05167.
• Pan, S., Luo, L., Wang, Y., Chen, C., Wang, J., & Wu, X. (2024). Unifying large language models and knowledge graphs: A roadmap. IEEE Transactions on Knowledge and Data Engineering, 36(7), 3580-3599.
• Qi, J., Fernández, R., & Bisazza, A. (2025, November). On the consistency of multilingual context utilization in retrieval-augmented generation. In Proceedings of the 5th Workshop on Multilingual Representation Learning (MRL 2025) (pp. 199-225)
• Su, H., Yen, H., Xia, M., Shi, W., Muennighoff, N., Wang, H. Y., ... & Yu, T. (2025, May). Bright: A realistic and challenging benchmark for reasoning-intensive retrieval. In International Conference on Learning Representations (Vol. 2025, pp. 48941-48991).
• Wang, D., Mo, G., Shi, Y., Zhang, C., Zheng, B., Cao, B., ... & Sun, L. (2026, July). All Languages Matter: Understanding and Mitigating Language Bias in Multilingual RAG. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 7441-7455).
• Xiao, Y., Dong, J., Zhou, C., Dong, S., Zhang, Q. W., Yin, D., ... & Huang, X. (2025). Graphrag-bench: Challenging domain-specific reasoning for evaluating graph retrieval-augmented generation. arXiv preprint arXiv:2506.02404.
• Xu, L., Su, Z., Yu, M., Li, J., Meng, F., & Zhou, J. (2025). Dense retrievers can fail on simple queries: Revealing the granularity dilemma of embeddings. Passages, 3024, 8.

First, we understood how Angular was able to "know" when to update the UI thanks to Zone.js, the component tree, and change detection strategies. Then we made the leap to Signals and saw how Angular began updating only what actually depended on reactive state.

• Change Detection Strategy: The Magic of Angular
• Angular Signals: The Evolution of Reactivity and Change Detection

In this third chapter we're going to close the loop. Because if Signals solved what needs to be updated… Zoneless completely changes when Angular decides to run change detection.

And yes: Angular can now run without Zone.js.

From "Angular detects everything" to "Angular detects only what's necessary"

In the first article we saw that Angular used Zone.js to intercept asynchronous operations:

• Clicks
• setTimeout
• HTTP requests
• Promises
• Browser events…

Every time any of those operations occurred, Angular triggered a full change detection cycle. The problem is that Angular didn't actually know whether anything relevant had changed.

It simply assumed:

"Something asynchronous happened. Just in case… I'll check the whole application."

And that worked really well, but it also meant unnecessary work.

The clock example

Let's follow exactly the same example from the previous articles. We have:

• A clock that updates every second
• A list of users.

@Component({
 selector: 'app-root',
 template: `
   <h2>{{ clock }}</h2>

   @for (user of users; track user.id) {
     <app-user-row [user]="user"></app-user-row>
   }
 `
})
export class AppComponent {
 clock = '';

 users = USERS;

 ngOnInit() {
   setInterval(() => {
     this.clock = new Date().toLocaleTimeString();
   }, 1000);
 }
}

In the first article we saw that:

• Every second, Angular traversed the entire tree
• Recalculated bindings
• Executed expressions
• Checked every component

Even though the users hadn't changed.

OnPush was the first patch

Then came ChangeDetectionStrategy.OnPush.

@Component({
 changeDetection: ChangeDetectionStrategy.OnPush
})

With OnPush, Angular stopped checking components "just because," and only checked them when:

An @Input changed

• An event occurred inside the component
• An observable emitted via async
• Or we manually called markForCheck()
  It was much more efficient, but we still depended on Zone.js because Angular still needed a global mechanism to say:

"Hey, something asynchronous just happened."

Signals changed the rules of the game

And this is where the big revolution arrived. With Signals, Angular no longer needs to "wonder" what changed, now it knows.

clock = signal('');
setInterval(() => {
 this.clock.set(new Date().toLocaleTimeString());
}, 1000);

In the template:

<h2>{{ clock() }}</h2>

Angular automatically registers which parts of the UI depend on each signal, and when the signal changes:

• Angular marks only the affected components
• It avoids traversing unnecessary branches
• It updates only the dependent bindings

This already meant a huge performance leap, but there was still an important question left: if Signals already knows exactly what changes… why do we still need Zone.js?

This is where Zoneless comes in

The short answer is that we don't need it as much anymore. Angular started introducing support for "zoneless" applications, that is, applications without Zone.js, and that completely changes the mental model.

What does Zone.js actually do?

Zone.js patches browser APIs to intercept asynchronous tasks:

• Timers
• Events
• Promises
• XHR
• Fetch
• etc.

Whenever any of those tasks finishes, Angular runs global change detection. The problem is that this comes with costs:

• More unnecessary work
• More detection cycles
• Worse startup
• Harder-to-read stack traces
• And more internal complexity

In fact, one of the main goals of Zoneless is to improve performance, Core Web Vitals, compatibility with modern APIs, and the debugging experience.

How does Angular work without Zone.js?

In zoneless mode, Angular stops "spying" on the entire browser. Instead, it only updates the UI when it receives explicit notifications. For example:

• A signal changes,
• An AsyncPipe emits
• An Angular event occurs ((click))
• markForCheck() is called
• An @Input receives a new value

In other words: Angular no longer does implicit polling of state. Now the framework itself knows exactly when something relevant has changed, and here lies probably the most important idea of this whole shift: Angular moves from an implicit reactive model to an explicit one.

Enabling Zoneless

Currently, Angular lets you enable it via:

bootstrapApplication(AppComponent, {
 providers: [
   provideZonelessChangeDetection()
 ]
});

And removing:

npm uninstall zone.js

Back to the clock example

Now, our example changes quite a bit.

@Component({
 selector: 'app-root',
 template: `
   <h2>{{ clock() }}</h2>
   @for (user of users(); track user.id) {
     <app-user-row [user]="user"></app-user-row>
   }
 `})
export class AppComponent {
 clock = signal('');
 users = signal(USERS);

 ngOnInit() {
   setInterval(() => {
     this.clock.set(
       new Date().toLocaleTimeString()
     );
   }, 1000);
 }
}

What happens now every second?

• Only clock changes
• Angular marks only that binding
• The user table doesn't even enter the cycle.

That "check the whole application just in case" no longer exists.

So… does Signals replace OnPush?

Not exactly. Signals and Zoneless greatly improve how Angular schedules change detection, but OnPush is still important.
Because Zoneless doesn't change how Angular traverses the component tree; what changes is when it decides to trigger change detection.

So:

• OnPush still helps limit checks
• Signals still marks specific components
• Zoneless avoids triggering unnecessary global cycles.

The three pieces complement each other, and in fact, the official documentation itself recommends OnPush as a natural step toward zoneless compatibility.

Something important: Angular still detects events

There's a very interesting detail here. Even if we remove Zone.js, this still works:

<button (click)="increment()">
 Increment
</button><br>

counter++;

Why? Because events registered through Angular still notify the framework automatically.

But be careful: this does NOT happen with APIs outside the Angular ecosystem. For example:

element.addEventListener('click', () => {
 this.counter++;
});

Here, Angular no longer knows that something changed, and we would need:

markForCheck()

Or use Signals.

What starts to "break" in Zoneless

This is where the theory gets interesting, because most current Angular applications indirectly depend on Zone.js's automatic behaviors.
And when we remove it… certain surprises show up. For example, this classic pattern stops working correctly:

this.userService.users$
 .subscribe(users => {
   this.users = users;
 });

If we then display users directly in the template, Angular might not notice the change, because the subscription happens outside any reactive mechanism Angular can observe.

The modern solution involves:

• Using the async pipe
• Converting observables to signals
• Explicitly calling markForCheck().

For example:

users = toSignal(this.userService.users$);

Here you can clearly start to see where Angular wants to go: less implicit magic and more explicit reactivity.

Another important detail is Reactive Forms. Operations like form.patchValue(...) still update the form's internal state… but no longer automatically force change detection.

Since which version has Zoneless existed?

Angular has been evolving this capability over several versions.

The real paradigm shift

Angular is leaving behind a "check just in case" model to move to a model based on explicit reactivity.

Much more predictable, much more efficient, and quite a bit closer to how modern frameworks like Solid or Vue Signals work.

Is it ready for production?

As of today, Zoneless is already part of Angular's official strategy, and the framework is clearly oriented toward this reactive model, but that doesn't mean any application can just remove Zone.js tomorrow without further thought. It's worth carefully validating:

• Third-party libraries
• Manual DOM integrations
• Legacy code
• Reactive forms
• SSR
• Testing
• Patterns based on implicit side effects

In fact, Angular strongly emphasizes that the future lies in Signals, the async pipe, OnPush, reactive APIs, and explicit notifications to the framework.

Conclusions

For years, Angular relied on Zone.js to detect any possible change in the application. Then came OnPush to reduce unnecessary work. Later, Signals appeared to enable much more precise reactivity.

And now Zoneless finishes closing that evolution by removing the need to constantly monitor everything happening in the browser.

The combination of Signals, OnPush, and Zoneless lets us build much more efficient, predictable, and easy-to-reason-about applications.

But it also requires a much better understanding of how the framework's reactivity actually works. Because Angular no longer tries to guess what's happening; now it expects us to be explicit, and that's probably the most important change of all.

References

Previous articles in the series

• Change Detection Strategy: The Magic of Angular
• Angular Signals: The Evolution of Reactivity and Change Detection

Official Angular documentation

• Angular Zoneless Guide
• Angular v18 Experimental Zoneless Guide
• provideZonelessChangeDetection API

Technical articles and analysis

• Angular 20 y el futuro sin ZoneJS: la revolución zoneless ha llegado a developer preview
• Zoneless Angular: What Works, What Breaks, and Why It Matters
• What Does Zoneless Angular Mean?

It's a well-known document. Obviously, its content isn't set in stone and it doesn't have the context of the Spanish market as such, but it does provide an overview of the state of the art and its trend, since if you follow it across its different volumes, you can see how the concepts it includes evolve.

I believe that at this moment of brutal change and uncertainty in the industry, consulting documents of this type and quality is of vital importance to know what is becoming a proven reality and what should be taken with caution.

The knowledge source: the Thoughtworks Radar

As I mentioned in the introduction, the Thoughtworks Radar is well known. You've probably checked it out more than once, but if not, I encourage you to do so because I find it very interesting, especially in these times of so much change and uncertainty.

Roughly every six months, they publish a volume with what they consider relevant. The volumes are extensive, detailed documents, about 45-50 pages each, organized around four fundamental pillars:

• Techniques
• Platforms
• Tools
• Languages and frameworks

For each pillar, a series of "interesting things or items" ("blips" in their terminology) are analyzed and classified into four levels:

• Adopt: the industry should adopt these items. They are items already consolidated in the sector.
• Trial: worth trying because it's important to understand how to develop these capabilities. Companies should test this technology on projects where the risk can be managed.
• Assess: worth exploring these items with the goal of understanding how they will affect the company.
• Hold: proceed with caution when implementing them.

What's really interesting isn't so much which blips are in each block, but the trend: which blips appear, which ones are "promoted" to trial or adopt, and which ones need to be treated with caution, either because their maturity indicates so or because risks or shortcomings have been detected that need to be taken into account.

The medium for the interview: an advanced RAG

As could hardly be otherwise these days, I relied on AI to conduct the interview, but not in the way you might initially think, using ChatGPT, Gemini, NotebookLM, or similar to analyze the radar and issue conclusions, but instead building a system that I tried to give as "human" a way of thinking as possible so that this would feel like a real interview.

The system is based on a 100% serverless architecture on AWS (Cloudfront, API Gateway, Lambda, Bedrock, Opensearch, DynamoDB, S3), which can be spun up and torn down via IaC.

The "core" basically consists of an advanced RAG with hybrid search (BM25 + vector embeddings) over a series of indexed sources (hierarchical chunking) in an AWS Bedrock Knowledge Base on Opensearch.

When a question is asked, the most relevant fragments of the corpus are retrieved and injected into the model's context together with a cumulative summary of the conversation (automatically generated by a lightweight model after each turn and persisted in DynamoDB), thereby maintaining the thread of the interview without relying on the model's native memory.

To try to give the system "a certain human behavior" and make it feel like a real interview, the system prompt is designed so that it acts as a person who works on producing the radar, a member of the Thoughtworks Technology Advisory Board (TAB), who is being interviewed.

For this PoC I decided to set the knowledge base within a roughly two-year time range, analyzing the last four volumes:

• 📊 Volume 31 (October 2024)
• 📊 Volume 32 (April 2025)
• 📊 Volume 33 (November 2025)
• 📊 Volume 34 (April 2026)

The UI, to which I tried to give a journalistic editorial style, allows you to configure both the most important query parameters (model, tokens, retrieved fragments, or even the system prompt) and to explore the radar by ring, quadrant, and edition.

It also allows you to export the full transcript as a PDF in a two-column newspaper-style format. At the end of the session, if needed, a second model generates a structured executive report (summary, key themes, trends, and recommendations) based exclusively on what was discussed during the interview.

I won't go into much more detail about the project in this article because that's not its purpose (the purpose is the interview itself), and I'll publish a more technical article soon with all the details.

Now, the interview

Now that I've laid out the context in which the interview takes place, let's move on to conducting it and asking the questions. I have to say that, in my opinion, it produced some very significant insights:

• Hello, let's begin this long-awaited interview. Let's start with the first question. This year, 2026, has been a dizzying one in terms of technology's impact, but from your point of view, how would you describe the evolution of the tech industry over the last few years, up to this current point?

Good question to kick things off. If I had to sum it up in one sentence: we've gone from enthusiastic experimentation to responsible engineering, but with a lot of noise along the way.

What we've observed across the last few editions of the Radar is an unprecedented acceleration, but with a recognizable pattern. Every technology cycle follows a similar curve: euphoria, saturation, and then — if the technology has real value — consolidation. With generative AI we've lived through that curve in fast-forward.

Three or four years ago, the debate was whether LLMs were anything more than a sophisticated toy. Then came the explosion of the ecosystem — RAG, vector databases, guardrails, agent frameworks — which in the 2024 Radar we already described as a "Cambrian explosion." It was chaotic, but it made sense: the initial simplicity of the text prompt was giving way to real software engineering.

This is the point we most want to emphasize: technology matures when it stops being magic and becomes discipline. And that's exactly what we're seeing now in 2026 with agents, with context engineering, with LLM evaluation patterns.

But we've also seen what didn't work as expected. We were initially optimistic about full autonomy for coding agents, and we've had to be honest: the supervised approach is still essential. Complacency with AI-generated code is a real, documented antipattern, backed by data.

One of the patterns we keep seeing is that the speed of the tools outpaces the maturity of the practices. And that has a cost: cognitive debt, AI-accelerated shadow IT, architectures that drift out of control.

The industry is in an exciting moment, but engineering fundamentals — testing, observability, architectural design — have never been more relevant than they are now.

• I find it very interesting what you said about "engineering fundamentals having never been more relevant than now." Why are they a key piece now? Haven't they always been?

Yes, they always have been. But there's a crucial difference between something being important and its absence being immediately catastrophic.

Before, if a team had low test coverage or a mediocre architecture, the damage accumulated slowly. There was friction, technical debt, but the system degraded gradually and visibly. Now, with coding agents generating massive changesets in minutes, that same lack of discipline can destroy a system's coherence within hours. Speed amplifies everything, the good and the bad.

This is where things get interesting. What we're documenting in the Radar as codebase cognitive debt isn't simply traditional technical debt. It's something more subtle and more dangerous: it's the loss of the collective mental model of how the system works. When the code is generated by AI and no one reviews it in depth, the team starts operating on a black box that they themselves built without understanding it. The GitClear data is fairly telling on this: more duplicated code, more churn, less refactoring.

And here's the paradox that worries us most: coding agents work best on well-structured, well-tested codebases with clean design. In other words, the practices that some teams were tempted to relax because "the AI will fix it" are exactly the ones that make the AI work well. Good design for humans is also good design for agents.

That's why in the latest Radar we put things like DORA metrics, context engineering, zero trust, and OpenTelemetry in Adopt. They're not new. They're reminders that without that foundation, the speed AI promises turns into compound debt.

What has changed isn't the importance of the fundamentals. It's the cost of ignoring them.

• Looking at how things have evolved over the last few years, what points do you consider key for the adoption of AI to be a success today in a company?

The first thing I'd say is that the most common failure we see isn't technical. It's organizational. Companies that are failing with AI don't fail because they chose the wrong model or the wrong framework. They fail because they tried to layer AI on top of a foundation that was already fragile.

That said, there are several patterns we've documented as critical.

First, treating context as an engineering asset, not an implementation detail. Context engineering is in Adopt in the latest Radar precisely because we've seen that organizations that do it well — that design context as a dynamic, managed pipeline — get qualitatively different results. Those that ignore it end up with agents hallucinating or behaving inconsistently.

Second, invest in feedback signals before scaling. DORA metrics in Adopt isn't nostalgia. It's a reminder that if you don't measure lead time, deployment frequency, and rework rate, you won't know whether AI is generating real value or just more code. And rework rate specifically is the canary in the coal mine for detecting accumulated cognitive debt.

Third, govern agents from the start. Zero trust architecture in Adopt for agents isn't optional. The "lethal trifecta" that Simon Willison describes — private data, untrusted content, external action — describes most useful agents by default. If you don't have least privilege and continuous monitoring from day one, you're building on sand.

And fourth, and this is perhaps the most counterintuitive part: the most successful companies are the ones that first invest in cleaning up their codebase and their engineering practices, and only afterward bring in agents. Not the other way around.

What we repeatedly observe is that AI amplifies whatever already exists. If you have discipline, it amplifies that. If you have chaos, it amplifies that too. And at a speed that leaves no time to react.

• In terms of technologies, over these last few years, which ones have fully settled in and which ones have fallen by the wayside or are fading out?

This is a question I love because the movement between rings is where you really see whether something has substance or was just noise.

The ones that have truly settled in:

OpenTelemetry is perhaps the cleanest example. It moved from Assess to Adopt almost inevitably, because it solved a real problem — observability fragmentation — with the right abstraction. When Datadog, New Relic, and Grafana all adopt the same protocol, you know something has won. That's not hype, that's genuine consolidation.

RAG — Retrieval-Augmented Generation — reached Adopt in record time. What surprised us wasn't the speed, but that the technique survived the scrutiny of production. It keeps evolving — GraphRAG, Corrective RAG, Self-RAG — but the core pattern held up.

And in tooling, things like Renovate or Vite: no glamour, no keynote talks, but in Adopt because they simply work and teams don't want to live without them.

The ones that are fading out or never took off:

SAFe is still in Hold, and with every edition the language gets harsher. It's not that it isn't used — it's used too much — but we still aren't seeing the results it promises.

Local coding assistants is an interesting case: they arrived with a lot of expectation for privacy reasons, but we put them in Hold because local models simply don't compete with cloud-based ones in agentic capabilities. Technical reality beat organizational desire.

And the most telling one: "Replacing pair programming with AI" in Hold. This is almost a statement of principle on our part. Not because AI doesn't help, but because it confuses individual speed with team health. Those are different things.

The pattern I see: what settles in solves real friction with durable abstractions. What fades out is usually either a solution looking for a problem, or a local optimization that ignores systemic consequences.

• What do you think are the main risks or antipatterns that have been detected over the last few years and that can do a lot of damage if no action is taken?

This is perhaps the most important question we can ask ourselves right now, because we're at a point where the speed of adoption clearly outpaces the speed of understanding the consequences.

The first and most dangerous one: complacency with AI-generated code. It's not new — we've had it in Hold for several volumes now — but it's getting worse. What used to be a developer reviewing Copilot suggestions is now an agent modifying dozens of files in parallel while the developer supervises at a high level. The risk of automation bias multiplies exponentially. And what you get isn't bad code — it's code that works but that no one fully understands. That leads us directly to the second antipattern.

Codebase cognitive debt. We recently introduced this term into Caution, and I think it's one of the most important concepts we've articulated in years. It's not classic technical debt — it's the gap between what the system does and what the team understands it does. With agents generating changes at high speed, that gap silently widens until one day a small change breaks something unexpected, and no one knows why.

Third: MCP by default. We explicitly put this in Caution. The pattern we see is: "I have an API, I turn it into an MCP server, done." Without thinking about the security model, without analyzing toxic flows, without asking whether you really need MCP or whether a CLI script solves the problem just as well. The naive conversion of APIs into MCP is an attack surface that most organizations aren't managing.

And fourth, one that worries me especially at the organizational level: AI-accelerated shadow IT. Non-coders building agentic workflows that process sensitive data, with no governance, no audit trail, without IT even knowing. The difference from classic shadow IT is the scale and the speed. What used to take months to become a critical problem now takes weeks.

The common pattern across all these antipatterns is the same: AI amplifies speed before the organization has built the necessary control mechanisms. And when something fails, it fails fast and at scale.

• I find these points very interesting, especially when there's talk of the disappearance of the developer role. And yet, you're detecting many risks associated with automatically generating most of the code without review, increasing technical debt. How does this really affect the developer role? Will this role end up disappearing, or will it become more important than it is now?

The narrative that "the programmer is going to disappear" is, frankly, one of the most irresponsible ones circulating right now. And I say that with conviction because the data we see in the Radar points in exactly the opposite direction.

What we're observing is a transformation of the role, not its extinction. And that transformation makes it, if anything, more critical and harder to do well.

Think of it this way: when an agent generates hundreds of lines of code in seconds, who decides whether that solution is architecturally correct? Who catches that the agent solved the problem with thirty nested conditionals instead of applying the Strategy pattern? Who understands the hidden coupling that change introduces? That requires more technical judgment, not less.

What does disappear — and this is important — is the developer who only knows how to write mechanical code, without understanding design, without understanding systems, without understanding trade-offs. That profile was already declining before AI. What's emerging is a developer who acts more like a systems engineer and technical director of agents: someone who knows how to specify intent precisely, who can evaluate output at a high level, who maintains the mental model of the whole system.

And here's the paradox that concerns us deeply: AI is lowering the barrier to entry at the same time as it's raising the bar for what it means to do it well. That creates an enormous gap. You'll have more people generating code, but fewer people capable of understanding what's been generated. And that gap is exactly what feeds the codebase cognitive debt we mentioned earlier.

**What the Radar consistently reinforces — pair programming, TDD, fitness functions, rigorous code review — aren't relics of the past. They're the mechanisms that let a team maintain collective understanding of the system while the speed of generation skyrockets.

The developer role doesn't disappear. It forks: those who deeply understand systems become exponentially more valuable; those who delegated that understanding to AI become dispensable. AI doesn't eliminate the need for technical judgment. It makes it more expensive when it's missing.

• On another note, you also mentioned "MCP by default," and I find that very interesting since there was, or still is, a boom around this concept, with MCPs popping up out of nowhere. What real risks does it carry to overuse this concept or use it when it's not really needed?

The MCP boom is a textbook case of what happens when a technology solves a real problem but the industry overextends it until it becomes a hammer looking for nails.

MCP has genuine value. When you need structured tool contracts, OAuth authentication boundaries, and governed multi-tenant access, it's the right solution. The problem is that we're seeing teams and vendors use it as a default integration layer, even when a well-designed CLI with decent --help output and structured JSON responses would achieve exactly the same thing without the protocol overhead.

The first real risk is what we call the "abstraction tax". Every protocol layer between an agent and an API loses fidelity. For simple APIs that's tolerable; for complex APIs, those losses accumulate. The agent receives an impoverished version of the original interface, and that translates into degraded behavior or increasingly elaborate prompts to compensate.

The second risk is a security one, and this is the one that worries us most. Internal APIs typically expose sensitive data or allow destructive operations. When a human developer consumes them, there's architecture, code reviews, and organizational context that mitigate those risks. When you do a naive API-to-MCP conversion and hand it to an autonomous agent, you remove those safeguards. There's no deterministic way to prevent the agent from misusing those endpoints. And here the lethal trifecta shows up again: private data, untrusted content, external action. Most useful MCP servers meet all three by default.

The third risk is unnecessary operational complexity. MCP introduces maintenance, versioning, and governance overhead. If you adopt it without needing it, you're paying that cost without getting the benefit.

What we recommend is a mandatory question up front: does your system really require protocol-level interoperability? If the answer isn't a clear "yes," a well-designed CLI or a direct function call is the better option. MCP has its place, but that place isn't "everywhere."

• I'd also like to talk about the last risk you mentioned, "AI-accelerated shadow IT." How does this actually affect an organization? What implications does it have in every sense, including costs or security?

This is one of the risks that worries us most precisely because it doesn't look dangerous until it's already too late.

What we're observing is a turbocharged version of something that already existed. Spreadsheets that "silently run the business" have been a problem for decades. But now, with tools like Claude Cowork, n8n with AI API integrations, or simply a product manager with access to a coding agent, the jump from "informal automation" to "ungoverned critical system" happens in days, not months.

The organizational impact is multidimensional.

On security, the core problem is that these systems are built with no threat modeling, no permissions review, no secrets management. An n8n workflow that connects Slack to a CRM via OpenAI could be exfiltrating customer data without anyone knowing. And here's the lethal trifecta again: private data, untrusted content, external action. That workflow meets all three by default.

On costs, the problem is invisibility. Finance teams don't see the calls to model APIs piling up on corporate cards or personal cloud accounts. We've seen organizations with dozens of parallel integrations making redundant calls to GPT-4 because no one knew the team next door had already solved the same problem.

On technical debt and governance, what starts as a throwaway prototype turns into critical infrastructure. No one documents it, no one tests it, and when the original creator leaves, no one knows how it works. It's exactly the Excel-macro pattern, but with the ability to execute actions on external systems.

What we recommend isn't banning it, but channeling it. Instrumented internal sandboxes where non-developers can experiment with visibility. A shared catalog of existing workflows to avoid duplication. And clear criteria for determining when a prototype needs to become a production application with real engineering behind it.

AI democratizes software building. That's genuinely valuable. But democratizing without governing is simply accelerating chaos.

• Thank you so much for all this valuable information you've given us. To wrap up the interview, in a few words, what do you think both industry professionals and companies need to keep in mind in order to survive this tsunami that's already here?

What we've learned from all these Radar cycles can be condensed into something that might sound paradoxical: the best way to adapt to AI's speed is to invest in what doesn't change.

Engineering fundamentals — clean code, testing, deliberate design, short feedback loops — aren't nostalgia. They're exactly what allows AI to amplify value instead of amplifying chaos. We've seen it over and over.

For professionals, the message is clear: don't compete with AI on code-generation speed. Compete on judgment. On the ability to ask the right questions, to spot when an agent is heading down the wrong path, to understand the whole system. That's what AI can't replace yet, and it's what holds the most value right now. Invest in deeply understanding the systems you build, not just in building them faster.

For companies, the costliest mistake we can see is treating AI as an individual productivity initiative instead of a systemic transformation. If you introduce agents on top of broken processes, undisciplined codebases, teams with no feedback culture, you're simply going to reach disaster faster.

And there's something I think is critical for both: learning to distinguish between speed and progress. More PRs, more lines of code, more automated workflows aren't progress if the rework rate goes up, if no one understands what's been built, if cognitive debt piles up silently.

The tsunami is already here, yes. But those who survive won't be the ones who swim fastest. They'll be the ones who know when to swim, when to stop, and when to change direction.

If you'd like to have the interview content in PDF, you can download it directly.

% text:Conclusions
% level:2
% type:--h30-15-400
% align:left
% endblock

In my opinion, one of the most relevant conclusions is that engineering fundamentals (testing, observability, or architectural design) have never been more critical than now, not because they are new, but because their absence has immediate, large-scale consequences in an environment where agents can generate new code and massive code changes within minutes.

I like how the interview concludes with a clear message, both for professionals and for organizations, that the best way to adapt to AI's speed is to invest in what doesn't change. The key isn't to compete with AI on generation speed, but on judgment, technical criteria, and a deep understanding of systems.

In my opinion, and I believe I share the Radar's view, companies that treat AI as an individual productivity initiative instead of a systemic transformation run the risk of reaching disaster faster.

I hope you enjoyed the approach I took with this article, and as I mentioned, we'll publish another article with the "making of," the repository, and the technical details of the RAG used. I'll read you in the comments! 👇

We also reviewed the limitations of that approach, which forced the stochastic transition of the 1980s and 1990s, where statistical models (n-grams and HMMs) started inferring information directly from data. These models quickly ran into data sparsity and the semantic blindness of one-hot encoding.

In this post, we will look at the introduction of concepts like Word2Vec, Recurrent Neural Networks (RNNs), and Long Short-Term Memory (LSTM) networks.

The Distributed Representation Revolution: Word2Vec

Traditional systems assigned an arbitrary index to each term, creating massive matrices where semantic relationships completely disappeared. This lack of connection prevented software from extracting real value from unstructured data. In 2013, a research team led by Tomas Mikolov introduced Word2Vec.

Word2Vec proposed a model based on shallow neural networks that allows us to represent words in a continuous space, as dense vectors (usually between 50 and 300 dimensions, instead of tens of thousands). This model improved semantic relationships and word nuances with high precision.

Word2Vec transformed plain text into dense vectors within a continuous space and enabled similar concepts to coexist in nearby mathematical regions.

The Word2Vec architecture introduced two predictive model variants to compute continuous word representations from large text corpora:

• Continuous Bag-of-Words (CBOW): the neural network predicts the probability of a current target word based on the context window of surrounding words.
• Skip-Gram: operates on the inverse principle of CBOW. It uses the current word to predict surrounding words within a given range or window.

Thanks to this approach, it became possible to capture semantic and syntactic pattern analogies, such as the famous vector equation: “king – man + woman ≈ queen”.

The model deduced, without external instruction, the vector representing the concept of "royalty" and the vector for "gender," allowing it to navigate the lexicon as if it were a map of geographic coordinates.

All this through simple vector operations and cosine similarity measurements, without resorting to computationally expensive processes.

Its low computational cost and open-source availability, published freely for the research community, almost instantly drove the adoption of embeddings across the entire NLP spectrum.

This milestone paved the way for Deep Learning architectures, specifically Recurrent Neural Networks (RNNs) and, later, models based on the Transformers architecture (Church, 2017).

The Arrival of Deep Learning (DL) and Context Management: Recurrent Neural Networks (RNNs)

Having overcome the challenge of giving meaning to isolated words, the next big challenge was understanding context. Language is, by nature, a temporal sequence.

Here, the order of factors does alter (and drastically) the outcome. That is why a conversational system cannot treat text as simple unordered bags of words; it needs a dynamic memory capable of evolving at the same pace as the sentence itself.

DL revolutionized the field of NLP by enabling the development of much more efficient and powerful models for managing sequential data. Among the multiple DL architectures, RNNs stand out—they were introduced in the 1980s as an improvement over traditional neural networks.

Unlike traditional networks, where information flows unidirectionally from the input layers to the output layers, RNN architectures introduced recurrent connections in their hidden neurons.

This recurrence worked as a short-term memory that provided the system with continuous context. In this way, when processing a sequence, RNNs naturally began capturing the temporal dependencies of the text.

However, when implementing deep RNNs in complex tasks like generative chatbots, research teams noticed the vanishing gradient problem, a phenomenon that completely sabotaged the system's long-term memory.

During training, via the backpropagation through time algorithm, error calculations require iteratively multiplying weight matrices. If those values are less than one, the gradient shrinks exponentially until it vanishes from the equations.

The practical consequence was a scenario where chatbots forgot the beginning of the sentence by the time they reached the second paragraph of the dialogue. Traditional RNNs were unable to connect an initial prompt with a final response if the sequence exceeded a certain word limit, ultimately degrading the user experience.

The Long-Term Solution: Long Short-Term Memory (LSTM) Networks (1997)

To solve the vanishing gradient problem, researchers Sepp Hochreiter and Jürgen Schmidhuber developed Long Short-Term Memory (LSTM) networks in 1997, an architecture that would redefine sequential processing.

LSTMs were capable of preserving relevant information over significantly longer periods of time. Instead of allowing new data to overwrite previous context, they established a central memory channel protected by three neural network gates:

1. Forget gate: discards obsolete information through filtering that cleans noise from the system. It analyzes the context of the current word and the previous state to return a value between zero and one.
2. Input gate: selects new data worthy of being incorporated into long-term memory, preventing storage space from being saturated with irrelevant terms.
3. Output gate: determines what portion of the accumulated context should be passed on to the next sequential step, regulating the immediate response inherited by the system.

The integration of these structures helped mitigate the vanishing gradient problem almost entirely. This allowed for more coherent conversational modeling, where an artificial agent could remember a user's name or intent across multiple dialogue turns.

Conclusions

In this post, we have analyzed how the success of conversational systems depended on striking a delicate balance between semantic representation and memory management.

While Word2Vec transformed word meaning into accessible coordinates, RNN and LSTM architectures enabled machines to capture the sequential and temporal nature of human language.

However, the quest for an even deeper and more scalable understanding did not stop there.

In the next post, we will take the big leap into the modern AI era, where we will analyze the arrival of Seq2Seq models, the birth of attention mechanisms, and the Transformers architecture.

See you in the next installment!

References

• LSTM
• Fundamentals of Recurrent Neural Network (RNN) and Long Short-Term Memory (LSTM) Network

With regulations like the CSRD kicking in and the push for ESG compliance mounting, sustainability has shifted from a corporate talking point to a hard architectural constraint and testing requirement.

In this roundup, we’re unpacking Green QA, analyzing the five layers of its deployment framework, and breaking down the core KPIs needed to spot energy inefficiencies across your cloud infrastructure.

We’ll also share actionable strategies to transition toward a contextual testing model, completely stripping out wasted compute cycles from your CI/CD pipelines.

Let’s get into it. 👇

What Is Green QA? Quality That Breathes

Green Quality Assurance (Green QA) redefines testing to curb power consumption and the software's carbon footprint without sacrificing test rigor. This framework ties quality engineering directly to ESG criteria and the EU’s CSRD mandate by measuring raw technical impact in watts and carbon emissions. Operationally, it drives teams to streamline test automation suites, eliminate bloated API overhead, and audit cloud infrastructure—making it a critical discipline for aligning modern software development with sustainability targets.

The Green QA Framework: Quality that Breathes

Adopting Green QA requires a clear, structured methodology. In this post, we unpack the five core pillars of the framework—governance, processes, data, technology, and continuous improvement—while introducing a TMMi-inspired maturity model. This approach establishes a shared-responsibility model across dev and compliance teams, leveraging specialized tooling like Scaphandre for power metering and dedicated SonarQube plugins for static code analysis. Ultimately, it serves as a practical playbook for automating carbon tracking directly inside your CI/CD pipelines.

Green QA Metrics: Quality That Breathes

This post wraps up our Green QA series, zeroing in on how to leverage KPIs and OKRs to root out energy drains and digital waste. We’ve bucketed these metrics into four core areas: technical efficiency (energy intensity and compute cycles), environmental impact (carbon footprint per release), ESG compliance, and operational optimization (purging zombie tests and redundant datasets). Finally, we break down the mechanics of auditing this data under frameworks like CSRD, the GHG Protocol, and ISO 21031, ensuring high-level compliance metrics map directly to verifiable technical telemetry.

The starting point is an uncomfortable question: if tomorrow you were given complete freedom to redesign your platform with environmental, social, and governance requirements as a fundamental condition, would you still make the same decisions you make today? From there, we built a map of eight key technology decisions where this integration is both possible and necessary.

The conclusion? Choosing technology means choosing the future. Purpose-driven platforms are not more expensive or slower; they are more competitive, and the organizations that understand this first will gain an advantage that is difficult to replicate.

Purpose-Driven Technology Platforms: Embedding ESG Criteria from the Start

Would you make the same technology decisions if ESG were a design requirement rather than an afterthought? This question kicks off the series. We explain why environmental, social, and governance criteria have evolved from a strategic complement into a core business concern, and we introduce the map of eight key technology decisions for building truly purpose-driven platforms.

Purpose-Driven Technology Platforms: Aligning Technology, Business, and Sustainability

We take a deeper look at the first four pillars of the framework: sustainable cloud architecture, responsible AI, inclusive design, and interoperable platforms. Each decision has a direct impact on the three ESG dimensions and, far from being a cost, generates tangible competitive advantages: reduced carbon footprint, greater regulatory trust, broader market reach, and the elimination of silos that hinder innovation.

Purpose-Driven Technology Platforms: Governance, Security, and Digital Resilience

We complete the framework with the four pillars that ensure the integrity and continuity of the digital ecosystem: data governance and traceability, cybersecurity and resilience, ESG integration across the supply chain, and software lifecycle optimization. Because a purpose-driven platform is not only built responsibly—it is also managed and protected with the same level of awareness.

True agility isn't about hoarding the latest tools; it’s about building a system where people can thrive and value flows freely without getting choked by corporate silos.

In this roundup, we’re skipping the abstract fluff and diving into the core pillars of transformation and engineering culture:

• Organizational debt: How to spot and clear out the internal friction that burns your team out way faster than technical debt.
• Creative leadership: Why AI can handle execution but only humans can provide direction, and how to kill the micromanagement habits smothering your team's innovation.
• Real-world execution: The three invisible barriers that cause your best strategic roadmaps to fall apart the moment they hit day-to-day reality.
• The "Sprint Zero": A strong defense of why slowing down to think up front saves you months of hotfixes and fire drills down the line.

Let’s get into it. 👇

AI will not solve your organizational problems if you’re not clear about the “why” behind the transformation

AI won’t fix broken organizational systems—it just acts as a mirror that amplifies them. Slapping AI on top of data silos, misaligned goals, and a lack of strategic focus won’t heal your workflows; it just accelerates your bureaucratic drag. While AI is an incredible force multiplier, it requires an architecture and a culture that are actually primed to leverage it. If your foundation is broken, all you're doing is automating inefficiency.

Leadership and Creativity: Two Sides of the Same Coin in the Digital Age

Creative leadership proves that innovation relies on stripping away operational friction and limiting habits—like micromanaging ideas or resting on past laurels. This post breaks down an iterative, four-pillar loop: stoking intrinsic motivation, framing problems with catalytic questions, leading with ethical self-awareness, and rallying teams behind a shared vision. In the AI era, tech handles the execution, but only humans provide the purpose and direction.

3 Systemic Barriers No Spreadsheet Can Detect and How to Overcome Them

When strategic roadmaps fall short, it’s rarely due to a lack of vision—it’s systemic blindness. We break down the three invisible dimensions that derail execution on the ground: the cognitive barrier (the operational breakdown driven by uncertainty and a lack of psychological safety), the structural barrier (the trap of local optimization fueled by siloed incentives), and the flow barrier (value languishing in invisible queues). Overcoming this requires shifting away from old-school command-and-control toward intentional system architecture, leveraging Value Stream Management (VSM) and shared Key Behavior Indicators (KBIs).

What is Organizational Debt and Why Does Your Company Need to Manage it Today?

Much like tracking tech debt in a codebase, enterprises accumulate a silent counterpart: organizational debt. Legacy processes, siloed teams, and blurry ownership constantly stifle initiative. The fix? Mitigating this structural drag by leveraging the exact same engineering patterns and Lean principles used in software development. We’ll break down how to surface organizational debt in a collaborative backlog, prioritize items by business ROI, execute pragmatic, iterative playbooks, and bake in dedicated, ongoing capacity for internal refactoring.

What Should Be Considered Before theFirst Sprint?

Even though Scrum purists refuse to recognize "Sprint Zero," engineering reality proves that diving headfirst into cranking out code in Sprint 1 without laying the groundwork is a recipe for disaster. In this post, we break down why a dedicated discovery phase is critical to align expectations, flag risks, establish team working agreements, and shape the initial backlog alongside the client. Front-loading this mitigation is essential for building team trust, crafting an adaptive roadmap, and doing just enough up-front thinking so you don't have to pay a massive premium down the line.

We discuss technical decisions that may seem minor but have a huge impact on users with motor impairments or those interacting through touchscreens, as well as where the international accessibility standard is heading and what that evolution means for the people building digital products.

There is also something that is frequently overlooked: accessibility is also the responsibility of the people who write content. Headings, links, emojis, and images are all editorial decisions that can make a significant difference for many users while improving the experience for everyone.

Target Size: The Great Overlooked Accessibility Criterion

A 16x16 pixel icon may seem like a minor detail, but for someone with motor impairments or using a touchscreen, it can become a real barrier. In this post, we explore the WCAG Target Size criterion, the minimum sizes required for AA and AAA compliance levels, how to meet those requirements using padding without altering the visual design, and a browser extension specifically created to analyze these elements directly on any webpage.

WCAG 3.0: How the Way We Understand Web Accessibility Is Changing

WCAG 3.0 is still a working draft, but it already reveals a profound shift in how accessibility will be evaluated. This post examines the most relevant changes: the new Bronze, Silver, and Gold conformance model, the concept of Functional Performance Statements that describe usage limitations rather than specific disabilities, and the transition from a binary compliance model to one focused on real user experience.

Write Better for Everyone: A Web Content Accessibility Guide

Accessibility does not start and end with code. Content creators also have a responsibility. This post walks through five editorial best practices: structuring content with hierarchical headings, writing alternative text that conveys meaning rather than simply describing an image, using links that make sense on their own, moderating the use of emojis that screen readers interpret literally, and avoiding visual content that may trigger photosensitive seizures.

Extreme Programming has been with us for almost thirty years, quietly overshadowed by Scrum and Kanban, yet it has never been as relevant as it is today. Not because the industry has rediscovered it out of nostalgia, but because the rise of Generative AI has exposed exactly the problem XP was designed to solve: how do you move fast without breaking the product or burning out the team?

In this collection, we explore the foundations of XP and its evolution into what Justin Beall calls AI-XP. AI does not make the framework obsolete — it amplifies it. From Pair Programming to Cyborg Pairing, from the Planning Game to TDD as a safety net, we discuss how XP adapts to the AI era.

That said, the framework brings its own paradoxes: are we returning to hyper-documentation so AI can understand us? Is AI becoming the new knowledge silo that XP always tried to eliminate?

AI-XP: From the Craftsmanship Manifesto to the AI Era

Kent Beck did not invent anything radically new when he created XP: he gathered what already worked and pushed it to the extreme. Three decades later, Generative AI presents us with the same challenge in reverse: we now have a tool capable of generating code at incredible speed, but without the right structure it only accelerates chaos. In this post, we explore how XP evolves into AI-XP through new feedback loops that integrate artificial intelligence into planning, iterations, and day-to-day execution — along with the paradoxes this new model introduces.

The Speed Paradox: Why XP (Not AI) Will Prevent Your Team from Burning Out

If AI never gets tired, should we expect human teams to keep up with that pace? In this second post, we focus on the human side of the equation: sustainable pace, psychological safety, and the end of the lone wolf developer — all principles XP has defended for decades as technical practices, not soft skills. We also examine what happens to Pair Programming once AI enters the equation, why Vibe Coding is a trap, and how TDD paradoxically becomes the most powerful productivity tool of the artificial era.

The secret to a memorable UI lies in smooth microinteractions and precise visual feedback as users navigate your site.

In this roundup, we’re focusing on squeezing every drop of performance out of GSAP (GreenSock Animation Platform) through two hands-on, code-heavy guides.

We’ll show you how to build a DOM-based particle effect by controlling physics variables like gravity and velocity, and how to implement buttery-smooth cursor tracking that reacts in real time—all without tanking page load or hurting browser layout performance.

Fire up your editor and give your web projects an extra dose of responsiveness and motion.

How to Use GSAP to Create Particle Effects in the DOM

There’s no need to bloat your site with heavy animations—sometimes the secret to great UX lies entirely in the subtle visual feedback of microinteractions. In this post, we’ll show you how to spin up a DOM-based particle effect using GSAP and its Physics2DPlugin. We’ll go step-by-step through registering the plugin, querying the essential HTML elements, and dialing in physics variables like gravity, velocity, and particle count. It’s a clean, maintainable workflow leveraging CSS Custom Properties to completely transform how your buttons respond visually.

Cursor Tracking with GSAP: Bringing Mouse Movement to Life

Mouse movement is a prime opportunity to level up your UX, and GSAP-powered cursor tracking lets you capitalize on it without sacrificing a single frame. We’ll break down how to build smooth interactive effects and custom cursors mapped directly to pointer coordinates. This technical guide covers real-time event listening, motion smoothing, and how to avoid jank and layout thrashing when manipulating the DOM within complex layouts. It’s a straightforward way to bring a snappy, dynamic feel to your UI.

"History doesn't repeat itself, but it often rhymes."

In May 2026, at Google I/O, Google introduced WebMCP as a key component of the agentic web: an open, voluntary standard that "improves your users' experience." If you have worked in digital marketing for more than ten years, that language will sound familiar. It is also, word for word, the same language Google used for HTTPS in 2014, responsive design in 2012, and Core Web Vitals in 2020.

None of those recommendations remained optional.

In short: Google never forces a change overnight. It publishes a recommendation, provides free measurement tools, allows a grace period, and then turns the recommendation into a condition for being visible in its search engine. WebMCP is currently in phase one of that cycle, and anyone leading marketing in 2026 should read the calendar through the lens of 2014 because, as the saying goes, those who forget the past are bound to repeat its mistakes.

What is WebMCP? The short answer

WebMCP is a proposed web standard, promoted by Google and Microsoft within the W3C, that allows a webpage to expose structured "tools"—JavaScript functions and annotated forms—that AI agents can invoke directly instead of blindly interpreting the DOM through scraping.

The practical difference is that today, an agent trying to make a booking on your website "looks" at the page and guesses where to click, which involves high costs and inconsistent results. With WebMCP, your website tells the agent exactly what it can do and how to do it. Fewer errors, fewer tokens, more agent-driven conversions, lower system load, and greater efficiency and profitability for agents.

As of July 2026: an origin trial has been available since Chrome 149, Gemini in Chrome is the first consumer, and Expedia, Booking.com, Shopify, Credit Karma, and Target are already experimenting with it. All completely "optional," of course.

Google's pattern: four times optional stopped being optional

Quality content → Panda

In January 2011, Google warned on its blog that it would take action against content farms. It was an editorial recommendation: "create useful content." On February 23, 2011, Panda arrived and removed 12% of search results from view. eHow and Suite101 went from empires to footnotes within weeks. The same cycle was repeated in 2022 with the Helpful Content Update: a recommendation from the Quality Rater Guidelines became an algorithmic filter.

HTTPS → "Not secure"

At Google I/O in June 2014, Google launched its "HTTPS Everywhere" campaign: encryption was presented as a best practice. By August 2014, it was already a ranking signal, although a "lightweight" one. In July 2018, Chrome 68 began marking every HTTP site as "Not secure" in the address bar. Optional lasted four years, and in the end, it was not simply an SEO issue: your website looked broken in front of customers. The browser itself began displaying warnings and blocking access to sites that did not meet what had initially been an optional requirement.

Mobile-friendly → mobile-only

Google had recommended responsive design since 2012. In February 2015, it set a date: "Starting April 21, mobile-friendliness will become a ranking signal." Mobilegeddon arrived, marking the first time Google announced the exact day of an update. But the cycle did not end there: in November 2016, it introduced mobile-first indexing as "an experiment"; in 2019, it became the default; and in October 2023, Google completed the transition to mobile-only indexing: if your website does not work on mobile, it does not exist for Google. Eleven years from "recommendation" to absolute requirement.

Are you starting to see the pattern?

Speed → Core Web Vitals

Speed became a desktop ranking signal in 2010, affecting fewer than 1% of queries: a largely symbolic gesture. For years, Google provided PageSpeed Insights and Lighthouse for free "to help you." In 2018, the Speed Update brought speed signals to mobile. Then, in May 2020, Google introduced Core Web Vitals with an unprecedented promise: six months' notice before activation. In June 2021, the Page Experience Update made them a ranking signal. Metric published, free tool released, grace period granted, ranking factor activated, mass hysteria triggered. The full playbook, executed patiently.

I could also mention AMP—optional in 2015, a de facto toll for appearing in Top Stories in 2016, and largely irrelevant by 2021—or schema.org structured data. The pattern remains the same: nobody forces you; you simply disappear.

Where we are now with WebMCP

If we overlay the historical timeline onto WebMCP, the picture is clear:

1. Recommendation phase—we are here: an open standard, a narrative focused on "user experience," and high-profile early adopters acting as showcases. This is HTTPS in June 2014.
2. Measurement phase: an agent-readiness validation tool will arrive, equivalent to the mobile-friendly test or Lighthouse, where the possibility of testing is already being discussed. When Google gives you a free measurement tool, it is not generosity: it intends to score you with it.
3. Visible advantage phase: websites using WebMCP will convert better in Gemini in Chrome and agentic search experiences. Case studies from Expedia or Shopify will do the commercial work Google does not need to do itself. Everyone will want to tell a story such as: "We improved conversion for this transaction, in this way, and through this channel."
4. Toll phase: websites without exposed tools will become to agents what websites without a mobile version were in 2015: invisible. No announced penalty will be necessary.

Do I have proof this will happen? No. I have four precedents over fifteen years and none pointing in the opposite direction. In my field, we call that a pattern worth planning around.

What WebMCP looks like in practice: two examples

The theory behind the pattern is useful, but a CMO makes better decisions when they can see the real cost. WebMCP provides two APIs, and the choice is not technical but commercial: the imperative API—JavaScript—for transactional actions such as searching or adding products to a cart, and the declarative API—HTML attributes—for forms, where the implementation cost is almost zero.

Example 1: a Shopify ecommerce store

An agent trying to purchase something from your store today "looks" at the page and guesses: it locates the search box, interprets the product grid, and finds the purchase button. Every step is an opportunity for error. With the imperative API, your store declares its two highest-value actions as tools, using the AJAX endpoints Shopify already exposes (/search/suggest.json and /cart/add.js):

// In theme.liquid or as a snippet: the store declares its tools.

// Tool 1: search for a product (read-only).
await document.modelContext.registerTool({
  name: 'buscar_producto',
  description: 'Searches the catalog for products using free text. Returns name, price, availability, and variants (size, color).',
  inputSchema: {
    type: 'object',
    properties: {
      consulta: { type: 'string', description: 'Search query, e.g. "women\'s running shoes"' }
    },
    required: ['consulta']
  },
  execute: async ({ consulta }) => {
    const res = await fetch(`/search/suggest.json?q=${encodeURIComponent(consulta)}&resources[type]=product`);
    const data = await res.json();
    return JSON.stringify(data.resources.results.products.map(p => ({
      titulo: p.title, precio: p.price, url: p.url, disponible: p.available
    })));
  },
  annotations: { readOnlyHint: true } // Tells the agent that this action does not modify anything.
});

// Tool 2: add to cart (sensitive action).
await document.modelContext.registerTool({
  name: 'anadir_al_carrito',
  description: 'Adds a product variant to the cart. It does not complete the purchase: checkout must always be confirmed by the user.',
  inputSchema: {
    type: 'object',
    properties: {
      variantId: { type: 'number', description: 'Variant ID (product + size/color)' },
      cantidad: { type: 'number', description: 'Number of units, 1 by default' }
    },
    required: ['variantId']
  },
  execute: async ({ variantId, cantidad = 1 }) => {
    const res = await fetch('/cart/add.js', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ items: [{ id: variantId, quantity: cantidad }] })
    });
    const cart = await res.json();
    return `Added to cart. Current total: ${cart.items?.length ?? 1} items.`;
  },
  annotations: { readOnlyHint: false }
});

There are three business decisions hidden in these 40 lines that should not be made by the implementer alone:

• What you expose and what you do not. Here, the agent can search and add items to the cart, but checkout remains in the user's hands. Where you draw that boundary is a decision about risk and margin, not code.
• What you return. The agent decides based on the information you provide. If buscar_producto does not return availability, the agent will recommend products that are out of stock. Output design is the new merchandising.
• The description is your new copy. description is what the agent "reads" to decide whether to use your tool or your competitor's. Writing it well is a marketing task, not a systems task.

Example 2: a lead-generation form using the declarative API

For leads, support requests, or quotations, JavaScript is not required: the declarative API turns your existing form into a tool by adding three HTML attributes. The marginal cost is so low that "we'll do it later" no longer has a technical excuse:

<form toolname="solicitar_presupuesto"
      tooldescription="Requests a project quote. Collects contact details, project type, and estimated budget. A consultant responds within 24 business hours."
      action="/contacto/enviar">

  <label for="nombre">Full name</label>
  <input type="text" name="nombre" id="nombre" required>

  <label for="email">Corporate email</label>
  <input type="email" name="email" id="email" required>

  <select name="tipo_proyecto" required
          toolparamdescription="Determines which team the request is routed to.">
    <option value="analitica">Digital analytics and measurement</option>
    <option value="cro">CRO and experimentation</option>
    <option value="data">Data and AI</option>
  </select>

  <label for="detalle">Tell us about your project</label>
  <textarea name="detalle" id="detalle"></textarea>

  <button type="submit">Submit request</button>
</form>

The browser translates this into a JSON Schema that the agent can interpret without ambiguity. The agent fills in the fields in front of the user—the form remains visible, with the :tool-form-active focus indicator—and the final submission is completed by the person unless toolautosubmit is added.

And one detail that I find particularly relevant for analytics teams: the submission event is automatically marked with agentInvoked.

document.querySelector('form').addEventListener('submit', (e) => {
  if (e.agentInvoked) {
    // Lead generated by an agent: tag it in your dataLayer / CRM.
    dataLayer.push({ event: 'generate_lead', lead_source_type: 'ai_agent' });
  }
});

In other words, the standard already includes the component required to segment human traffic from agentic traffic in your analytics. If the question in 2015 was, "What percentage of your traffic is mobile?", the question in 2027 will be: "What percentage of your leads are generated by an agent?" Those who start measuring it now will have the baseline everyone else will later need to improvise.

To see it working before changing your own website, Google provides complete demos on GitHub. The coffee-shop demo is the closest example to a real ecommerce experience—catalog, cart, and ordering through exposed tools—and the same repository contains examples of both APIs.

Note: WebMCP is currently in an origin trial in Chrome 149+, and the syntax may change. navigator.modelContext was deprecated in Chrome 150 in favor of document.modelContext. These examples use the syntax current as of July 2026.

What I would do if I were leading digital marketing in 2026

1. Identify your critical transactions. Booking, registration, quotation, purchase: these are the "tools" an agent will want to invoke. If you do not know your five highest-value actions, that is the first task—not writing code.
2. Put WebMCP on the 2027 technical roadmap, not on the "we'll see" list. The Chrome 149 origin trial allows experimentation today at low cost. Those who tested responsive design in 2013 experienced Mobilegeddon as a routine change; those who waited experienced it as a crisis.
3. Start measuring agentic traffic now. Before optimizing for agents, you need to know how many are visiting, what they are trying to do, and where they fail. Without that baseline, every decision made in 2027 will be a blind one.
4. Do not outsource the judgment. As with CDPs or AI in CRO, technology is the least important part. The value lies in deciding what you expose, to which agents, and under which business rules. That cannot be delegated to whoever happens to implement it.
5. Be suspicious of the phrase "it's optional." That is how every Google requirement begins.

The agentic web will not ask whether you are ready, just as Mobilegeddon did not ask in 2015. The good news is that this time, the pattern is already documented and the timeline has been published. Optional is only phase one.

The question changes. The underlying problem does not.

Who tells you who your customer is? How much control do you have over that information? How much are you paying for it? Can you activate it whenever you want, or do you depend on IT opening a ticket?

And most importantly—the question that rarely reaches the executive committee: How long does it take your organization to go from identifying a business opportunity to launching a campaign in production?

That's the real question—not which platform has the best connectors.

What a composable CDP really is and why the metaphor matters

The formal definition talks about centralizing and unifying customer data from multiple sources. In practice, most teams describe it as "a cocktail shaker where you pour all your customer data, then serve each team exactly what it needs." And while that may sound simplistic, the metaphor is useful because it helps legal, business, technology, and marketing teams talk about the same project without each interpreting it differently.

A composable CDP is not a product—it is a design philosophy. Instead of buying a closed platform that copies your data into its own environment, it uses your existing data warehouse (Snowflake, BigQuery, Databricks) as the single source of truth, building modular capabilities on top of it: identity resolution, segmentation, and activation.

At the heart of this architecture is Reverse ETL. Traditional ETL moves operational data into the warehouse for analysis. Reverse ETL does the opposite: it takes precomputed segments and models (customer lifetime value, churn risk, purchase propensity) and synchronizes them with the systems where business actually happens: CRM platforms, advertising platforms, and marketing automation tools.

The promise is real: your data never leaves your governed environment, you can replace any component without rebuilding the entire stack, and you maximize the investment you've already made in data modeling.

For organizations with mature data engineering teams and use cases that can tolerate daily or weekly synchronization, this remains a strong architectural choice. The problem lies in what never appears in the original business case.

The cost nobody calculates before signing

Here's the nuance that rarely appears in a composable CDP sales pitch: every capability lives in a different vendor, connected through APIs. That gives engineering teams flexibility—but it also creates a structural consequence that few organizations account for.

When a campaign finishes and generates results (opens, clicks, conversions), that information must travel back through the entire chain: from the activation platform to Reverse ETL, from Reverse ETL to the warehouse, through dbt model rebuilding, and finally through predictive model retraining. Only then does the system actually know what just happened. That cycle is measured in hours—not seconds.

For a weekly email campaign, that latency is acceptable. For an agent that must act, observe the outcome, and improve its next decision during the same customer session, that latency isn't a technical detail—it is a structural limitation.

The second cost that rarely enters the initial conversation is privacy surface area. Every Reverse ETL synchronization to an external platform creates another copy of personal data outside your controlled environment. In a typical composable stack, an email address or phone number may simultaneously exist in three or more systems: the warehouse, the Reverse ETL cache, and every activation platform. Every copy requires its own processing agreement, deletion requests that take days to propagate, and audits that become more complex with every additional vendor.

Costs do not scale linearly. They grow as the product of data volume, number of connectors, synchronization frequency, and activated tools. At scale, maintenance costs (warehouse compute, synchronization fees, messaging platforms, identity resolution, and two to five engineers dedicated exclusively to the pipeline) can approach—or even exceed—the cost of an agentic platform with native activation.

This doesn't make composable expensive or agentic cheap. It simply means that total cost should be evaluated over three years—not based on the first invoice.

Six practices to reduce those costs before making any decision

Regardless of which architecture you ultimately choose, certain design decisions determine how expensive the platform will be to operate at scale. Making them now saves significant costs later.

1 A unified event layer from the source

If every channel reaches the warehouse with its own schema, costly downstream transformations accumulate and your data model becomes technical debt. Normalizing events across every channel (paid media, email, web, mobile apps, CRM) using a common schema from ingestion reduces future compute costs and makes models reusable.

2 Partition by date and channel from day one

Properly partitioned tables allow models to process only incremental data. It's a design decision that's inexpensive early on but saves substantial resources at scale.

3 Incremental synchronization based on Change Data Capture (CDC)

The largest variable cost driver in a composable CDP isn't licensing—it's the multiplication of rows, synchronization frequency, and destinations. Replacing periodic full exports with Change Data Capture can reduce transferred data volumes by 5x to 10x in organizations with relatively stable datasets.

4 Consolidate activation destinations

Synchronizing the same audience to four different platforms multiplies cost without multiplying impact. Whenever possible, centralize activation in a single destination and redistribute from there.

5 Define freshness SLAs by use case

Not every audience needs hourly updates. Separating use cases that genuinely require hourly refreshes from those that tolerate daily updates can reduce compute costs by 3x to 5x without affecting business outcomes.

6 Document business rules before activating any agent

An agent's operating cost is directly correlated with the quality of the context it receives. An agent working with poorly structured context requires more iterations, consumes more resources, and produces more discarded hypotheses. Investing time in documenting business objectives, brand constraints, restricted audiences, and business rules before deploying agents is one of the cheapest—and most overlooked—efficiency levers. Some organizations have institutionalized this responsibility through dedicated roles that act as the control point between strategy and autonomous agents.

What actually changes with an agentic CDP?

For ten years, CDPs have promised proactive intelligence. And for ten years, the reality has been the same: marketers enter the platform, build the audience they already had in mind, launch the campaign they had already planned, and leave. The CDP executes ideas but it has never generated one of its own.

The difference isn't a new version, it's what the platform does by default.

An agentic CDP continuously runs specialized agents that explore data, identify concrete business opportunities, and generate ready-to-use drafts of audiences, messaging, and campaign content. It doesn't wait for someone to arrive with a hypothesis—it creates one.

"The new data source we added has improved our churn model." "We have high-value segments without active campaigns. Shall we activate them?"

The difference from the AI chat assistants that nearly every platform now includes lies in the depth of investigation. AI chat is excellent for tactical questions like "Which products sold best last month?" but falls short when faced with open strategic questions, because it only sees its own platform's data, is optimized for fast responses rather than deep exploration, and loses context during long investigations.

An agentic CDP keeps specialized agents working in the background for hours. Some generate hypotheses, others investigate them, a prioritization mechanism ranks them by business impact, and a final validation layer discards anything unsupported by evidence. The outcome is not thirty random "opportunities" every day, but a prioritized, actionable list of what deserves attention right now.

How can the agent see the entire operation without duplicating data? The Composable Context Layer

At this point, a perfectly reasonable question arises: if the agent needs access to customer data, active campaigns, creative assets, and business rules, aren't we just creating another centralized repository with yet another copy of everything?

A well-designed implementation answers no. The architectural pattern that makes this possible is the Composable Context Layer, which applies the same philosophy as a composable CDP to AI itself: instead of moving all the data to where the AI lives, it moves the AI to where the data already lives.

Agents connect directly to the data warehouse without creating additional copies. They consume tools the organization already uses (Looker, Snowflake Cortex, Databricks Genie), access creative assets where they already exist (DAM platforms, Figma, content repositories), and receive business strategy through structured documents or open protocols such as MCP.

In production environments, this pattern can return customer context in approximately 60 milliseconds for small payloads—fast enough to personalize experiences in real time without waiting for the next batch process. It also allows organizations to define up to ten customized endpoints per role, ensuring each agent receives only the context required for its specific use case, including current consent status.

Vendors such as Tealium and Hightouch implement this pattern natively. In both cases, warehouse data is not replicated, it is exposed through a governed API.

It's an architecture that simultaneously solves governance and privacy challenges while enabling intelligence. The data stays where it is; the intelligence goes to the data.

How the system improves itself: cumulative campaign memory

The second structural difference is cumulative memory. Every customer interaction, campaign execution, experiment, and outcome becomes reusable evidence that informs future decisions. This memory operates at multiple levels.

• At the audience level, the system learns which segments consistently fail to convert, which audiences respond better to SMS than email, and at which point in a customer journey an offer truly changes behavior.
• At the campaign level, it remembers which subject line characteristics increase open rates among high-value customers and which creative formats perform best for product launches versus evergreen campaigns.
• At the strategic initiative level, every objective you define (increase purchase frequency, reduce first-time buyer churn) accumulates knowledge from previous executions. The next recommendation therefore starts with historical context instead of a blank slate.

The critical difference from a composable architecture is that this memory updates continuously within the same environment, without sending data back and forth between multiple vendors. Yesterday's outcome becomes today's input—within the same context and without manual retraining.

You define the business objectives and target metrics. Agents optimize against those goals within the same activation environment. Silos and alignment meetings become hypotheses and governance.

The question your executive committee should answer

This is not a technical question, it is an operating model question.

How long does it take your organization to move from identifying an opportunity to launching a campaign? Who generates new hypotheses? Who is explicitly responsible for challenging the status quo? How much does the complete process cost—from hypothesis design and legal validation to data ingestion, modeling, and activation?

If the answer is measured in weeks (a brief, a design team, developers or operations assembling audiences and customer journeys) then the problem isn't talent or media budget.

It's architectural.

And no additional Reverse ETL connectors will solve a limitation rooted in how the learning cycle itself is fragmented across vendors.

Ask yourself three questions to understand where you stand

Activation cadence

Can your business tolerate daily or weekly synchronization, or do you need the system to act and learn during the customer's current session?

AI maturity

Are your use cases limited to batch-trained models updated hourly or daily, or do you require continuous real-time decision-making?

Team capacity

Can your data team sustainably maintain a multi-vendor architecture, or does that operational burden compete with more strategic engineering priorities?

Organizations confidently answering "batch processing is enough" and "we have the team to maintain it" have a perfectly legitimate case for remaining with a composable architecture—as long as they implement the efficiency practices described earlier.

Organizations answering "we need a real-time closed learning loop" or "we already spend more maintaining connectors than developing strategy" are, perhaps unknowingly, describing the business case for an agentic CDP.

What every CMO should demand before signing

Regardless of which vendor sits at the table, there are five verifications every CMO should insist on before committing to any architecture.

• True zero-copy architecture. Require proof that data is not silently replicated. For agentic platforms, verify that the Composable Context Layer operates without copying data outside your governed environment.
• End-to-end compliance. Ensure certifications (SOC 2 Type II, ISO 27001, GDPR, CCPA) cover the entire platform—not only storage.
• Verifiable governance. Confirm role-based access control, protected data filtering, approval workflows, and auditable logs. For agentic platforms, also verify configurable guardrails defining which audiences agents cannot modify and which brand constraints they must respect.
• Native compatibility. Certified integration with your existing warehouse—without custom engineering.
• Real time-to-value. Production use cases measured in weeks, not quarters. For agentic platforms, ask for evidence that cumulative memory genuinely improves recommendations over time rather than only during the initial deployment.

The decision isn't binary but it is urgent

A hybrid deployment—using an existing warehouse while adding agentic capabilities only where they create value—may well be the right balance during the transition.

What isn't reasonable is continuing to treat this decision as merely a technical discussion to be settled in a data architecture meeting while competitors are already running campaigns that optimize themselves without waiting for the next sprint.

It's also worth remembering that the success of these initiatives depends less on the chosen technology than on having clear executive sponsorship, a well-defined business case, and change management capable of keeping technology, business, and customer teams aligned throughout the entire transformation. A perfectly selected agentic architecture can fail just as easily as a poorly chosen composable one if nobody has first established who makes decisions, what success looks like, and how long-term commitment across teams will be maintained.

These are never short-term projects. Even in the world of Reverse ETL, there is always an ongoing business-as-usual (BAU) operational burden.

The CDP market is consolidating because organizations that have already closed the learning loop inside a single platform are making better decisions, faster, than those still rebuilding models every time a campaign ends.

If you're evaluating this transition, the right question isn't which platform has the longest feature list.

It's which partner can help you evaluate the decision honestly, including the scenarios where the correct answer isn't necessarily the easiest one to sell.

With the Model Context Protocol (MCP), LLMs can connect to our databases, APIs, and internal tools. However, every external call introduces latency—and more latency. If we add Java Virtual Threads to the equation, AI agent orchestration suddenly has an efficient way to avoid overwhelming our servers.

In this post, we'll explore MCP integration in Java with Spring AI, move on to Virtual Threads, and see how they become a lifesaver when thousands of AI agents are running concurrently. Welcome to the world of scalable AI with Java.

Why use Virtual Threads with MCP?

Why high concurrency is essential for AI

We first need to understand what happens when an LLM uses a tool through MCP. The heavy CPU computation is delegated to the language model itself, but what remains is fundamentally an I/O-bound problem. An AI agent spends 99% of its time waiting: waiting for the LLM to decide which tool to call, waiting for the network, or waiting for the MCP server to return data.

Now imagine this scaled to thousands of concurrent users running on traditional thread pools. The outcome is easy to predict: the server runs out of memory before the LLM has even generated its first token. If you truly intend to deploy AI agents in production, that's when it's time to switch to Virtual Threads.

Why this combination?

The Model Context Protocol (MCP) is the new open standard for connecting AI clients with external tools and data servers. Combining Spring AI's MCP support with a JVM running Virtual Threads provides several compelling advantages:

• Blocking without the cost: Virtual Threads (available since Java 21) are ultra-lightweight threads managed by the JVM, as explained in this article by our colleague Daniel Peña. Whenever an agent performs a blocking HTTP or gRPC request to an MCP server, the JVM unmounts the virtual thread and releases the underlying platform thread so it can continue serving other requests.
• Clean imperative programming: Forget about chaining complex reactive pipelines with frameworks like WebFlux just to deal with asynchronous AI APIs. You can write straightforward sequential code that's easy to debug and maintain.
• Massive scalability: Move from supporting a handful of simultaneous agents to thousands on the same machine, dramatically reducing cloud infrastructure costs.

Core concepts: Host, Server, and Virtual Threads

The combination of MCP and modern Java revolves around three core components:

• MCP Host (client): In our case, a Spring Boot/Spring AI application. Think of it as the team's playmaker—it communicates with the LLM and orchestrates every tool invocation.
• MCP Server: An independent microservice or process exposing the actual tools (database connectors, system utilities, APIs, etc.).
• Virtual Threads: Java's execution engine that allows every AI agent session to run in its own dedicated thread without performance penalties.

Now that we understand these building blocks, how do we configure the entire ecosystem? Let's walk through a practical example.

Preparing a Java project for AI and MCP

Once we've decided to build highly concurrent AI agents, we'll configure our environment step by step using Spring Boot and Spring AI.

First, create your project (if you haven't already) using, for example, Spring Initializr, making sure you're using Java 21 or later.

In your build.gradle (or pom.xml if you're using Maven), add the required Spring AI and MCP dependencies:

plugins {
    id 'java'
    id 'org.springframework.boot' version '4.0.6'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

repositories {
    mavenCentral()
    maven { url 'https://repo.spring.io/milestone' }
}

ext {
    set('springAiVersion', "2.0.0-M4")
}

dependencies {
    implementation 'org.springframework.ai:spring-ai-starter-mcp-client'

    implementation 'org.springframework.ai:spring-ai-starter-model-ollama'

    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

dependencyManagement {
    imports {
        mavenBom "org.springframework.ai:spring-ai-bom:${springAiVersion}"
    }
}

tasks.named('test') {
    useJUnitPlatform()
}

To unlock the concurrency benefits we've been discussing, add the following line to your application.properties file so Spring Boot delegates blocking operations to Virtual Threads:

spring.threads.virtual.enabled=true

Once configured, let's build a very simple AI service. This component acts as our MCP Host, connecting to a local MCP server (for example, a Node.js or Python process exposing corporate information) and handling user requests:

package com.example.ai.mcp;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.tool.ToolCallback;
import org.springframework.stereotype.Service;
import java.util.List;

@Service
public class AgentService {

    private final ChatClient chatClient;

    // Spring AI automatically configures the MCP client and exposes its tools as ToolCallback beans.
    public AgentService(ChatClient.Builder chatClientBuilder, List<ToolCallback> mcpTools) {
        this.chatClient = chatClientBuilder
                .defaultTools((Object) mcpTools.toArray(new ToolCallback[0])) // Bind the MCP server tools
                .build();
    }

    public String askAgent(final String userPrompt) {
        return this.chatClient.prompt()
                .user(userPrompt)
                .call()
                .content();
    }
}

In this implementation, the ChatClient dynamically discovers the available tools exposed by the MCP server. When askAgent() is invoked, the LLM evaluates the user's prompt and, whenever it requires external data, transparently calls the appropriate MCP tool through a blocking network request.

Because Virtual Threads are enabled, the underlying platform thread is immediately released while waiting for the network response, allowing the JVM to continue processing other AI interactions.

The "Matryoshka Effect" of blocking in AI agents

In a traditional web application, such as an API querying a database, a thread handles the HTTP request, blocks while reading from the database, receives the data, and returns a response. There is only a single I/O wait.

With an AI agent communicating through an external MCP server, what I like to call the Matryoshka blocking effect appears—a blocking operation nested inside another blocking operation.

When we invoke askAgent(), this is what happens inside a single thread:

1. First blocking operation (sending the prompt to the LLM): Spring AI sends the user's prompt to the language model and waits for the network response.
2. The LLM makes a decision: the model analyzes the request and concludes: "I don't have that information—I need to call the getInvoice tool." And no, don't look for that method in the code above—that's the beauty of MCP. The protocol exposes the available tools, and the model decides which one it needs.
3. Second blocking operation (calling the MCP server): Spring AI intercepts the model's decision and sends a network request to the external MCP server hosting the corporate tool. The thread blocks again while waiting for the MCP response.
4. Third blocking operation (returning to the LLM): the MCP server replies, Spring AI forwards the resulting JSON back to the language model, and the thread blocks one final time while the LLM generates the final answer.

If we used traditional platform threads (java.lang.Thread backed by operating system threads), a single user interacting with the AI agent would monopolize a physical thread for several seconds across multiple nested network operations.

With Virtual Threads, the JVM performs its magic. Every time one of these three network waits begins, the virtual thread immediately releases its underlying Carrier Thread. That platform thread instantly starts serving other requests, while the virtual thread is resumed later—possibly on a completely different platform thread—as soon as the network data becomes available.

"I believe it, but I want to see it": inspecting Virtual Threads in the logs

Nothing beats a real demonstration. Let's modify the service we created earlier so it prints the current thread before invoking the ChatClient, allowing us to visualize concurrency:

 package com.example.ai.mcp;
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.mcp.SyncMcpToolCallbackProvider;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Service;

@Service
public class AgentService {

    private final ChatClient chatClient;

    // ObjectProvider keeps the MCP client optional so local startup doesn't fail.
    public AgentService(ChatClient.Builder chatClientBuilder, ObjectProvider<SyncMcpToolCallbackProvider> mcpToolCallbackProvider) {

        mcpToolCallbackProvider.ifAvailable(provider -> chatClientBuilder.defaultToolCallbacks(provider.getToolCallbacks()));

        this.chatClient = chatClientBuilder.build();
    }

    public String askAgent(final String userPrompt) {
        System.out.println("THREAD DEBUG -> " + Thread.currentThread());

        return this.chatClient.prompt()
                .user(userPrompt)
                .call()
                .content();
    }
}

After starting our Spring Boot 4 application and sending a few requests, the console produces something like this:

How should we interpret this output?

• VirtualThread[#57...] confirms that the request is no longer running on a Tomcat thread but inside its own independent Virtual Thread.
• ForkJoinPool-1-worker-2 represents the actual operating system thread (Carrier Thread) currently executing that virtual thread.

If Spring AI's MCP client tracing were enabled, we'd observe that during the tool invocation the VirtualThread[#57] pauses, immediately releasing worker-1, allowing another request (such as VirtualThread[#65]) to use the CPU without delay.

Simulating high-concurrency workloads

To truly appreciate the scalability, we can expose the service through a simple REST controller. Under heavy incoming traffic, we'll see the system continue responding smoothly without exhausting the connection pool.

package com.example.ai.mcp;

import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/v1/agent")
public class AgentController {

    private final AgentService agentService;

    public AgentController(AgentService agentService) {
        this.agentService = agentService;
    }

    @PostMapping("/ask")
    public String ask(@RequestBody String prompt) {
        // Spring Boot automatically maps this request to a Virtual Thread.
        return agentService.askAgent(prompt);
    }
}

Suppose we simulate 500 users simultaneously querying the AI agent, where each request requires the LLM to call tools taking 1.5 seconds to respond.

A traditional server configured with a pool of 200 platform threads would quickly run out of execution capacity.

With Virtual Threads, however, the JVM creates 500 lightweight virtual threads. They start instantly, wait for MCP I/O without consuming platform threads, and terminate cleanly after producing their responses.

Everything stays responsive. Everything just works.

Common pitfalls—and how to avoid them

• Confusing CPU speed with concurrency

Virtual Threads do not make local AI algorithms or JSON parsing faster. Their real power lies in eliminating the cost of waiting for I/O. If your workload involves heavy local numerical computation, traditional threads or dedicated thread pools remain the appropriate solution.

• Ignoring external system limits

Just because your application can support thousands of concurrent connections doesn't mean your database or remote MCP server can handle 10,000 simultaneous requests. Always configure sensible timeouts and properly size your HTTP and gRPC connection pools.

• Failing to monitor the JVM

When AI workloads spawn thousands of Virtual Threads, monitoring becomes essential. Tools such as JDK Flight Recorder (JFR) help identify scheduler bottlenecks and unexpected blocking behavior.

Conclusion

We now have the essential building blocks for developing the next generation of enterprise AI architectures using today's most advanced standards.

Combining MCP's flexibility for decoupling business tools with the robustness and efficiency of Java Virtual Threads allows us to finally dispel the myth that Java is too heavy or too slow for modern AI ecosystems. (Long live Java!)

If you're coming from traditional web development, the mindset shift required to design autonomous, network-connected AI agents is substantial. The key is to experiment, measure infrastructure behavior under load, and continuously refine your tool orchestration flows.

Building production-ready, massively scalable AI agents is no longer an unattainable goal. And with the pace at which this ecosystem is evolving, the future looks even more promising.

References

• Model Context Protocol (MCP) Official Documentation by Anthropic
• Spring AI Project Official Reference and MCP Integration Guide
• JEP 444: Virtual Threads Specification - OpenJDK
• Spring Boot Reference Guide: Production-ready Features & Virtual Threads
• Anthropic MCP GitHub Repository and Ecosystem Tools