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

It is also easy to fall into the mistake of believing that using AI automatically makes us cheaper, more efficient, and faster.

In this environment of technological saturation, our methodology does not dissolve in the face of AI; it becomes stronger. We build systems where AI enhances execution, while operational sovereignty and strategic vision remain fundamentally human.

Eight years ago, Paradigma already argued that your company does not need tribes and squads. That thesis remains valid today: confusing form with substance is the fastest path to irrelevance. Frameworks should evolve from real business needs, not from methodological trends. This is the framework we use today, one that is working as of June 2026—and one we should never become emotionally attached to.

Our Starting Point

At Paradigma, technological maturity is built upon three value pillars: people, processes, and technology, ensuring that every AI investment translates into a tangible competitive advantage.

1. The people pillar encompasses all the hands-on training programs we deliver to our teams, helping them solve real business problems. These "Breaking AI" initiatives serve as repositories for materials, videos, and documented use cases.
2. The process pillar is based on a solution, framework, project, or transformation in the way of working.
3. The technology pillar relies on the developments we build on top of existing technologies that allow us to access information in a tangible and practical way.

The main lesson we have learned is that consolidating processes, systems, or technologies requires building on established processes rather than relying on external frameworks or end-to-end predefined workflows.

And where does the real differentiating value lie? In integration. If the CRO team speaks and builds according to the same efficiency standards as Development or Agile teams, we eliminate silos and accelerate time-to-market.

Applying It to CRO Teams

Our CRO framework has matured into a precision tool. Far from broad generalizations, our approach is grounded in three pillars that ensure scalability: structure, modularity, and persistence.

What do we mean by structure, modularity, and persistence?

• Structure guarantees interoperability with both internal and external teams.
• Modularity allows every solution to deliver immediate value independently or as part of a connected ecosystem.
• Persistence ensures stable inputs and outputs, eliminating uncertainty and guaranteeing that decisions are made on a solid foundation of trust.

In short: a Lego-like approach where each component is autonomous, delivers value on its own, remains compatible with the others, and is standardized to ensure consistency.

An Example: Analytics

At Paradigma, we do not rely on generic gems, skills, or off-the-shelf solutions. These "skills" or gems may appear efficient, but they are often black boxes prone to hallucinations, anti-bot restrictions, and inconsistent results.

How can a company base its strategy on outputs that vary depending on prompt wording or the day's token load? Lack of technical control is the enemy of profitability.

Our solution is to replace randomness with technical control. We use custom-built plugins that operate directly on the DOM, components, and loading times.

This approach guarantees speed, structural consistency, and complete traceability of the resources consumed. We do not stop at analysis; we move into high-level technical auditing. You avoid carrying forward hidden biases simply by pressing a button.

Why Work with the DOM Instead of a Chat Interface?

Marshall McLuhan, one of the leading thinkers in communication theory, famously said that the medium is the message. Recent studies suggest that, beyond the message itself, the medium is the bias. In value-driven processes, information loss between initiatives and solutions is something that deserves special attention.

It is not the same to write a prompt in plain text as it is to submit a JSON query, interact directly with the DOM, or upload an image. Each medium introduces a different context—and therefore a different bias.

An Example: Insights and Research

Experiments conducted by MeasureIQ confirm that synthetic users are excellent for breadth but weak when it comes to depth. Blindly relying on them without human judgment means diluting the customer's voice.

I do not believe they should ever replace real users. However, when direct access to users is not possible, they can provide an additional perspective.

At the same time, I believe we often distort the concept in remarkable ways. I cannot perfectly describe a synthetic user to an AI model. I cannot provide the nuance, context, market penetration, customer base composition, purchasing volume representation, or wording with complete accuracy.

What I can do is design an information ingestion process that enables AI to build synthetic users from context—and then describe them back to me.

Generating Synthetic Users

Determining which users, in what volumes, with what interests, transactions, and friction points is a context that is difficult to explain but easy to automate.

Our synthetic user process begins with the ingestion of multiple internal and external data sources:

• Natural Language Processing (NLP) applied to anonymized verbatims.
• Enrichment with customer sociodemographic data.
• Integration of transactional data.
• Expansion with NPS data and review content from Google Business Profile, Trustpilot, Glassdoor, and other sources when appropriate.

The result is that AI uncovers behavioral patterns that manual observation often misses, generating a robust knowledge base upon which we can apply our objectives while preserving volumetric context.

AI often identifies profiles that we ourselves are not fully aware of.

Understanding Synthetic Users

The next step is to translate the synthetic user models into proto-persona templates. This enables us to understand, communicate, and share the perspective applied to each analysis.

These templates act as anchors that help us ground our findings, create alignment, and, most importantly, review whether assumptions, biases, contexts, and expectations are actually being met.

Shaping the Response

The modularity of our templates ensures that insights remain cross-functional. We do not work for a single department; we work for the consistency of the entire digital ecosystem, ensuring that every optimization reinforces brand value.

Other AI Solutions for CRO Teams

Every stage of our methodology—from scenario design and DOM-based performance analysis to prototype validation and snippet generation—is designed around a technical excellence pattern:

1. Every solution must be designed to connect with other teams, whether they belong to Growth or not.
2. Every solution must deliver value independently while also being capable of integrating into broader processes.
3. Every solution must minimize error and uncertainty.

This ensures that, as we continue evolving our CRO processes in future iterations, everything develops in a consistent and coherent manner.

The development of conversational systems represents one of the most transformative scientific and technological trajectories within the fields of AI and NLP. For decades, computer science has pursued the ambition of giving machines the ability to understand, interpret, process, and generate human language with all its inherent structural richness.

This historical evolution has progressed through several radically different approaches. It began with rigid systems based on structural heuristics, moved through the adoption of statistical and probabilistic models, and ultimately arrived at the deep learning neural architectures that dominate today’s scientific landscape.

Analyzing this progression reveals a profound transformation in how language is represented. In its early stages, language was treated as a sequence of symbols governed by syntactic rules. Over time, this deterministic view gave way to a stochastic understanding, where words became probability distributions. Today, language is mathematically conceived as a multidimensional semantic space that can be encoded into vectors.

This transition has enabled machines to capture subtle nuances, long-range dependencies, and contextual information in ways that mimic—and in some classification and generation tasks even surpass—the processing capabilities of the human brain.

In this series of posts, we will examine the foundational milestones that have shaped the evolution of conversational systems.

ELIZA, the First Conversational Assistant

During the early stages of artificial intelligence, throughout the 1950s and 1960s, it was widely assumed that machine understanding of human language could be achieved through the encoding of grammatical rules, syntactic dictionaries, and algorithmic decision trees. Within this context emerged ELIZA (1966), the first truly disruptive milestone in the simulation of conversational interactions.

ELIZA was designed as a research platform for studying natural language communication between humans and machines. It possessed no ontological understanding of the meaning of the words it processed. Instead, it implemented a system based on lexical pattern recognition and textual sequence matching.

The architectural core of ELIZA relied on a set of rules triggered by the detection of keywords within the user's input text. Once the system identified a keyword within the input string, it activated the rules associated with that keyword to generate a response that appeared superficially coherent and connected to the original statement.

To create this illusion of interactive understanding, its creator had to structure the system around five technical challenges that, in retrospect, laid the operational foundations of all early conversational systems:

1. Algorithmic identification and prioritization of keywords within a sentence.
2. Discovery and isolation of the minimum context required to generate an appropriate response.
3. Selection of syntactic transformations to reverse pronouns (for example, transforming "my" into "your").
4. Generation of generic predefined responses when no recognizable keywords were found in the user's input.
5. Modular editing capabilities that allowed programmers to update and expand the program's scripts dynamically without rewriting the core engine.

ELIZA’s most famous and extensively studied script, known as DOCTOR, simulated interactions with a Rogerian psychotherapist. Its role focused on reflecting the patient's statements through open-ended questions and reformulations. In doing so, it almost completely eliminated the need for the system to introduce new real-world knowledge or generate invented judgments.

Despite its complete dependence on pattern matching and its lack of long-term contextual memory, ELIZA conveyed a psychological illusion of empathy, intelligence, and deep understanding to its users. Many people, including members of the research laboratory itself, developed emotional attachments to the program and shared personal confidences with it.

This phenomenon of anthropomorphizing computer systems was later coined in scientific literature as the "ELIZA Effect."

Despite ELIZA’s success, the limitations of purely rule-based approaches quickly became apparent to the research community. Everyday linguistic phenomena such as polysemous ambiguity, irony, sarcasm, dependence on pragmatic context, anaphora, and the infinite structural richness of human syntax made it impossible to compile a manual rule set comprehensive enough to handle every possible conversation.

The scalability of these systems was effectively nonexistent. Adding new rules often generated logical conflicts with existing ones, causing systems to fail. A transition toward systems capable of learning from data rather than relying on manually encoded knowledge became urgently necessary.

The Stochastic Transition: Statistical Models and Early Machine Learning Approaches

To overcome the rigidity of rule-based systems, the field of NLP underwent a major transformation during the 1980s and 1990s. The scientific community progressively adopted statistical models and pioneering machine learning approaches. These techniques, based on n-gram models and other probabilistic methods (such as HMMs, Hidden Markov Models), enabled researchers to overcome some of the limitations of purely rule-based systems.

This new paradigm abandoned the manual formulation of grammatical rules in favor of the automatic extraction of co-occurrence patterns from large structured text corpora. The underlying idea was that grammar and meaning did not need to be explicitly encoded if they could be statistically inferred by observing how people actually use language in practice.

An n-gram model seeks to predict the statistical probability of a specific word appearing given the sequence of words that immediately precedes it. This approach is based on the Markov assumption, which simplistically states that the probability of a future state (the next word) depends solely on a limited number of immediately preceding states, completely ignoring the broader historical context beyond that window.

Although these probabilistic models enabled machines to generate text autonomously and significantly improved accuracy in critical tasks of the era such as automatic speech recognition, spell checking, and machine translation, they still suffered from important mathematical limitations.

The most notable was the data sparsity problem. As the context window increased in size to capture longer and more complex grammatical dependencies, the probability of encountering that exact sequence of words within the training data decreased exponentially.

While stochastic and probabilistic techniques represented a monumental leap beyond rule-based systems, they still suffered from a representational limitation. The computational representations commonly used during this period were sparse vectors based on one-hot encoding, where each word in the vocabulary corresponded to a vector whose length matched the size of the entire known vocabulary (often tens of thousands of dimensions), with a single value of "1" at the index corresponding to the word and "0" everywhere else.

For the machine, this binary representation conveyed no semantic similarity. The statistical model had no structural way of recognizing that the words "dog" and "cat" belong to a similar semantic category as domestic animals, treating them with the same conceptual distance as it would between "dog" and completely unrelated words such as "car" or "water treatment plant."

As a result, for the system to learn the properties of each word independently, it required extremely large volumes of data.

Conclusions

The evolution of the earliest conversational systems demonstrates that brute force never surpasses technical adaptability. The transition from architectures based on manually crafted rules to probabilistic engines laid the foundations for modern automation.

In the next post, we will continue our chronological journey through the evolution of conversational systems and Natural Language Processing.

References and Resources

• ELIZA
• http://deixilabs.com/eliza.html
• N-gram Models and Statistical Evaluation
• Hidden Markov Models (HMM)

Beyond the individual announcements, the developments of recent weeks reflect four underlying trends:

• The emergence of a new generation of models with advanced agentic capabilities.
• The integration of AI into mass-market consumer platforms.
• The convergence of infrastructure and AI-assisted software development.
• The growing importance of digital identity and regulatory compliance.

Claude Fable 5: when an AI model becomes a matter of national security

Anthropic launched Claude Fable 5 as a commercially accessible version of Mythos 5 — the model many analysts regard as the most advanced AI system built to date.

According to the company, Fable 5 shares the same core architecture and capabilities as Mythos, with additional safeguards to restrict certain use cases and support public deployment.

Early benchmarks and independent testing point to significant improvements in coding, complex reasoning, and — most notably — agentic capabilities.

The step forward from previous generations doesn't appear to lie solely in output quality. What stands out is the model's ability to plan, execute, and monitor tasks autonomously over extended periods.

The launch, however, was immediately overshadowed by an unexpected development. Just days after release, the US Government issued an export control directive requiring Anthropic to suspend access to both Fable 5 and Mythos 5 for non-US users.

Unable to implement the restriction quickly and selectively, the company chose to temporarily disable both models for all users while it worked on compliance mechanisms.

The official justification centred on concerns about jailbreak techniques capable of circumventing some of the model's protections.

Anthropic has publicly disputed the severity of these vulnerabilities, arguing that the scenarios presented by the government are not unique to Fable 5 — they reflect behaviours that can be observed across other advanced models already on the market.

Apple reimagines Siri with a little help from Google

Two years after announcing its AI ambitions, Apple has unveiled the next generation of Siri. What makes the move particularly interesting is that it confirms a hybrid strategy: Google's models running on Apple's privacy infrastructure.

According to published reports, Apple is paying approximately one billion dollars a year to licence a customised version of Gemini. But the company isn't simply integrating an external chatbot and calling it done.

Instead, it uses distillation to produce optimised versions capable of running locally on iPhone and Mac, while maintaining compatibility with its Private Cloud Compute architecture.

From a technical standpoint, the approach is significant because it shows that differentiation no longer rests solely on training the most powerful model. Apple has chosen to leverage Google's research capability while retaining control over user experience, hardware, and privacy.

The new Siri capabilities reflect this evolution. The assistant can interpret on-screen context, coordinate information across apps, execute multiple actions in parallel, and draw on personal data to handle complex tasks without requiring detailed instructions.

In practice, Siri is moving away from being a glorified search interface and towards something closer to a contextual digital assistant.

Apple's approach also highlights a broader market reality: foundation model development is concentrating in a shrinking pool of players, while other tech giants compete on integration, distribution, and user experience.

SpaceX acquires Cursor and accelerates vertical integration

Another significant move has been SpaceX's acquisition of Cursor.

Cursor had become one of the most widely adopted coding agents on the market, competing directly with tools like Claude Code, Codex, and Antigravity. Like many companies working in applied AI, however, it depended on third-party infrastructure to run and train its models.

The deal gives SpaceX three strategic assets under one roof: compute infrastructure, model development, and developer productivity tooling.

This kind of vertical integration is becoming an increasingly visible pattern. Companies that simultaneously control compute capacity, models, and distribution hold real advantages in cost, iteration speed, and end-product optimisation.

For Cursor, direct access to compute removes one of the main constraints on its growth. For SpaceX, it means absorbing a product with strong traction among engineering teams and a well-established position within the software agent ecosystem.

Digital identity comes to AI models

Anthropic has also announced a meaningful change to how users access Claude: certain advanced features will now require verification via a government-issued ID and a selfie.

Although the company states that this data will not be used to train models, the decision marks an inflection point for the industry as a whole. For years, access to the most capable models has been effectively anonymous.

The introduction of verification mechanisms suggests that AI labs are beginning to treat digital identity as a necessary component of risk management — particularly as the systems themselves grow more powerful.

This approach is likely to spread over the coming years, especially for capabilities tied to advanced automation, acting on a user's behalf, or accessing high-impact tooling.

The shift echoes patterns already seen in digital banking and financial services: as platforms gain operational power, the demand for robust identification mechanisms grows with them.

Switzerland backs an open-source alternative built for European regulation

While the United States continues to lead large-scale commercial model development, Europe is still working out how to combine technological innovation with regulatory compliance.

The Swiss AI Initiative — led by EPFL and ETH Zurich — has stepped into that gap with Apertus Mini, a family of sixteen open models developed specifically to align with the requirements of the EU AI Act.

What makes the initiative particularly noteworthy is that it publishes not just the model weights, but also the training datasets and associated documentation. That level of transparency is a direct response to the regulatory requirements now taking shape across Europe.

While Apertus Mini's current capabilities appear primarily suited to RAG systems and lower-risk enterprise applications, the project offers a clear picture of how the European AI ecosystem might evolve: smaller models, fully auditable, and designed from the ground up to operate within strict regulatory frameworks.

Conclusion

The developments of June 2026 show an industry entering a new phase of maturity.

Models are no longer competing solely on benchmark performance — they're competing to become agents capable of executing complex tasks autonomously.

At the same time, AI is embedding itself ever more deeply into mass-market products, while infrastructure, digital identity, and regulatory compliance are moving from background concerns to front-and-centre priorities.

If 2024 and 2025 were the years of racing to build ever more powerful models, 2026 is shaping up to be the year the industry figures out how to turn that power into systems that are useful, governable, and scalable for millions of users.

Imagine replacing the delivery of a dashboard with twenty charts with a conversational interface connected to your data. This is not about eliminating dashboards, but about breaking that endless cycle of manual modifications. However, there is a catch: without a solid semantic layer and well-defined metrics, we will simply be accelerating the speed at which we obtain the wrong answers.

What If the Next Report Wasn't a Report? Conversational Analytics

This scenario will probably sound familiar: a business stakeholder needs to understand why sales have dropped over the last week. They open a Data Studio dashboard, start combining dimensions, apply several filters, and eventually end up calling an analyst—either because they do not trust the number they see or because an unexpected question arises, such as a sudden change in campaign performance, causing the entire workflow to break down.

The dashboard has evolved from a democratization tool into a technical barrier that requires constant interpretation.

Conversational analytics completely changes this paradigm. It is not about deploying a ChatGPT clone and giving it unrestricted access to your databases. Instead, it is about building natural language interfaces capable of understanding business context. We move from exploration based on clicking visual filters to a model where the data source is governed, an agent processes the question, returns a structured answer, and suggests the next steps. Visual dashboards will continue to be useful for monitoring recurring KPIs, but they will no longer be the only gateway for querying data.

Why You Need a Semantic Layer Before Talking to Your Data

Placing a language model directly in front of a database without any intermediary is a recipe for operational disaster. AI models do not inherently understand your business logic. If a query asks for the number of users from the last month, the system may execute a technically perfect query against a table while still producing a result that is conceptually wrong from a business perspective.

AI is not a mind reader; it is a context processor. If we ask about last month's revenue, the agent must know whether we mean placed orders, paid orders, or revenue net of returns. Without a semantic layer acting as the official business dictionary, the system will mix incompatible dimensions and drag us into an operational nightmare of decisions based on inaccurate data. The challenge is not the chat interface itself, but the governance behind it. A semantic layer acts as a universal translator that standardizes business definitions before they reach the model.

Tools such as Looker build their value proposition around this principle. Looker Conversational Analytics does not query storage directly; instead, it interacts with its shared semantic layer. When you ask how the conversion funnel performed, the technology translates that request using rules, dimensions, and metrics already centralized and audited by the data team. If your organization lacks a unified definition of what constitutes an active customer or a net sale, the analytics agent will not magically solve the problem—it will simply propagate the error faster.

Whats Under the Hood of an Analytics Agent?

What truly differentiates a FAQ bot from a genuine analytics agent? A traditional chatbot simply predicts the next word based on static training data. An analytics agent has execution capabilities that allow it to connect to APIs, analyze data schemas, generate real-time visualizations, and strictly enforce user access permissions.

Today's ecosystem already shows clear movements in this direction:

• The MCP Server for Google Analytics 4

The Model Context Protocol enables external LLM systems to connect directly to the GA4 API. At present, this integration is limited to read-only operations, allowing access to behavioral data and dimensions without any risk of altering property configurations.

• Looker Conversational Analytics and Dashboard Agents

This Google Cloud infrastructure combines foundation models with BigQuery to enable multi-turn exploration. Users can ask why revenue has declined and then continue the conversation by drilling deeper into the returned data, all while preserving row-level and column-level security restrictions associated with their role.

When the Chatbot Hallucinates Your Conversion Funnel

The biggest enemy of conversational analytics is not processing cost—it is the loss of trust among business teams. If a stakeholder identifies even a single inconsistent figure in a report generated by an agent, they are likely to abandon the system entirely and return to the traditional Data Studio dashboard—or worse, to spreadsheets.

The risks in this environment are both technical and operational:

• The Ambiguous Terminology Trap

The term "user" could refer to a GA4 cookie, a unique CRM record, or a customer with active backend transactions. Without strict mapping, the agent will combine incompatible sources and produce inaccurate figures.

• The Illusion of a Coherent Answer

A language model will always present its responses in a convincing and professional manner, even when it has misinterpreted a time range or a geographic filter.

• The Permissions Nightmare

If the agent does not inherit corporate security policies, a marketing user could end up querying salary data or restricted profit margins simply by asking a well-crafted question.

How Is the Role of the Digital Analyst Being Redefined?

Now for something important: with the rise of analytics agents, the role of digital and data analysts is being fundamentally transformed. Analysts are no longer spending their days rearranging charts on dashboards; they are becoming functional architects of the information ecosystem. Their value is no longer measured by the number of dashboards they build, but by the quality and robustness of the context they provide to machines.

The priority tasks of this new analytical profile shift toward designing detailed data dictionaries, continuously auditing agent-generated responses, and turning frequently asked business questions into reusable analytical assets.

Analysts become the final validation layer, ensuring that attribution rules and conversion goals are properly documented so that models do not operate blindly inside an algorithmic black box.

Where Do We Start Building This New Ecosystem?

Before connecting any AI model to your information repositories, you must establish a solid foundation. If you try to automate access to a disorganized data ecosystem, you will simply automate chaos at scale. Use the following checklist to assess your organization's maturity:

1. Build a unified metrics catalog. Document every KPI in writing, including its exact calculation formula and source systems.
2. Ensure naming consistency. Establish strict naming conventions for events, URL parameters, and data warehouse columns.
3. Implement a semantic layer. Deploy tools that act as intermediaries between model queries and production databases.
4. Define a validation question set. Create a collection of critical queries with known answers to regularly audit agent behavior.
5. Set consumption and action limits. Restrict agents to read-only environments and limit consecutive requests to avoid excessive costs.

Conversational analytics is not here to replace human judgment; it is here to free teams from the repetitive work of extracting reports. The success of these agentic AI systems will depend directly on the quality of the architecture and governance that support them.

Is your organization ready to build a reliable semantic layer, or will you keep sending emails every time a KPI deviates from expectations?

References and Links

• Anthropic Model Context Protocol
• Official Looker Semantic Layer Documentation
• Google Analytics 4 API

One of the areas where its impact is most immediate is document validation. Many organizations review files, contracts, payslips, identity documents, supporting evidence, bank statements, or forms on a daily basis. These processes are necessary, but often repetitive, time-consuming, and difficult to scale as volumes increase.

The idea for this article emerged from a conversation with a friend who faces exactly this kind of work: reviewing documentation, checking that everything is correct, identifying missing information or inconsistencies, and repeating the same process file after file. From that real-world need came a practical question: could we build a solution capable of performing an initial automated validation and simplifying part of this tedious work without removing professional oversight?

Starting from that question, this article presents a specific use case: applying document intelligence, generative AI, and asynchronous processing within a cloud architecture to automate part of the document validation process in administrative workflows. It is not conceived as a chatbot, but rather as a business solution designed to transform scattered documents into structured, verifiable, and actionable information for decision-making.

The problem: the hidden cost of administrative work

In many organizations, a significant portion of the workload is not about making major decisions or solving complex problems, but about checking that everything is in order.

A case file arrives with multiple documents. Someone must open them, verify that they are complete, check dates, amounts, and data, identify inconsistencies, and determine whether the case can move forward. Viewed in isolation, this may seem simple, but the problem emerges when the process is repeated dozens, hundreds, or thousands of times.

In rental or real estate transactions, mortgage assessments, invoice accounting, or internal operations, this review may include ID cards, residence permits, payslips, employment contracts, tax returns, bank statements, supporting documents, and other complementary paperwork. Every document requires attention, every case requires context, and every exception forces someone to stop and investigate.

This is where operational friction appears: lost administrative time, missing documents detected too late, unnoticed errors, duplicated reviews, poor traceability, and difficulty understanding the real status of each case.

The challenge is not only deciding whether a file can proceed. Often, the real bottleneck lies in getting to that decision: organizing documents, classifying them, searching for relevant information, identifying missing elements, detecting inconsistencies, and reconstructing the actual state of the file.

The goal is not to introduce AI for the sake of it. The goal is to identify the points in the process where repetitive work, risk of error, and time loss are highest. Those are precisely the areas where AI can create the most value: classifying documents, extracting information, identifying warnings, and preparing an initial structured review.

Improvement percentages should always be measured in real-world scenarios, but as a working hypothesis, one could expect a significant reduction in mechanical review tasks and late-stage error detection. Not because AI is infallible, but because it helps review documents earlier, more effectively, and with greater context.

Paperwork rarely seems urgent until it becomes a bottleneck

And this is where artificial intelligence can add value. Not by replacing professional judgment, but by changing the starting point. Instead of facing a folder full of unprocessed documents, people can receive an initial structured assessment: which documents are present, which are missing, what information has been extracted, what inconsistencies have been detected, and which cases require immediate attention.

AI does not eliminate review, it organizes it

It is no longer necessary to review everything from scratch. The person responsible can focus on exceptions, questionable cases, and decisions that genuinely require human judgment.

What does generative AI contribute in this context?

Generative AI is particularly useful when information does not arrive as clean, structured data, but rather as heterogeneous documents, free text, PDFs, images, or forms with different formats and structures.

Many organizations do not suffer from a lack of information. They have too much information, but it is scattered.

In a document-processing application, the value of generative AI lies in its ability to interpret content, classify documents, extract relevant fields, generate standardized outputs, and highlight warnings that can later be reviewed by a person.

The key, in my view, is not to treat AI as an infallible source of truth, but as an assistance layer. A tool capable of preparing the ground: reading, organizing, flagging, and prioritizing.

The objective is not to remove people from the equation, but to prevent them from having to start from scratch every time.

From idea to solution

Up to this point, the idea is simple: use artificial intelligence to reduce part of the manual effort associated with document validation.

However, for that idea to deliver real value, it is not enough to connect a generative model and wait for a response. A useful solution must integrate into a complete workflow: receiving documents, storing them, processing them securely, extracting information, interpreting it, storing results, displaying issues, and allowing a person to review the file's status.

And this is critical. In a project like this, AI is only one part of the solution. We also need components capable of fitting into the process: a document upload interface, a backend orchestration layer, secure storage, asynchronous processing, extraction services, models capable of interpreting content, and a clear way to present results.

The objective is not for AI to make the final decision, but to handle the heaviest preparatory work. The idea is for the person responsible to stop dealing with a disorganized collection of files and instead work from a clear, traceable, and prioritized summary.

From there, the solution can be understood from two complementary perspectives: the functional architecture, which explains what the system does and how the process flows, and the cloud architecture, which shows how it is technically implemented on AWS to ensure security, scalability, and maintainability.

Functional architecture: from scattered documents to a reviewable case file

The system's functional workflow can be summarized in a single idea: transform scattered documents into a structured and reviewable case file.

To achieve this, the solution is designed as a chain of responsibilities. Each component fulfills a specific role within the process.

The user interacts with a simple interface to create case files, upload documents, and monitor validation status. Underneath, the backend acts as an orchestrator: registering each document, linking it to the corresponding file, creating processing jobs, and coordinating the rest of the workflow.

From that point onward, the system avoids one of the most common mistakes in these types of solutions: processing everything during upload. Instead of blocking the user, it delegates analysis to an asynchronous processing layer. This allows text extraction, content interpretation, and result generation without turning the user experience into a waiting game.

AI enters the workflow only once the document is ready to be analyzed. First, text and structure are extracted; then generative intelligence helps classify the document, extract relevant fields, detect inconsistencies, and produce a normalized output.

The final result is not an isolated model response, but a traceable view of the case file: received documents, processing statuses, extracted data, warnings, incidents, and elements requiring professional review.

The key is that AI does not replace the workflow; it integrates into it.

Cloud architecture: bringing the functional workflow to AWS

Once the functional architecture has been defined, the next step is to ask how to bring that workflow into a real-world environment that is secure, scalable, and maintainable.

A solution like this requires a solid technical foundation. Documents must be stored correctly, resource-intensive processes must not block users, results need to persist, components must communicate in a controlled way, and permissions must be managed without exposing unnecessary credentials.

This is where the cloud architecture comes into play.

In this solution, the functional workflow is implemented on AWS through a combination of containers, managed services, serverless processing, asynchronous messaging, a relational database, and generative AI services.

I will not go into the internal cloud networking configuration, Terraform, Kubernetes, or every AWS service involved. The goal here is different: to understand the workflow, the role of each component, and how the architecture enables AI to transform scattered documents into useful information for professional review.

From there, the architecture can be understood as a technical chain of responsibilities serving the validation process.

The user interacts with a web application to create files, upload documents, and review results. React and Nginx power the frontend, while FastAPI running on EKS orchestrates the backend workflow.

When a document is uploaded, the backend stores it in Amazon S3, registers the job in PostgreSQL on Amazon RDS, and publishes an event to Amazon SQS. AWS Lambda consumes the event and performs the analysis in the background, ensuring the user is not blocked.

Once Lambda retrieves the document from S3, the most distinctive part of the system begins: transforming a file into useful information. To achieve this, the solution separates two responsibilities. The first is content extraction; the second is content interpretation.

Amazon Textract handles extraction. Its role is to obtain text and structure from documents that may arrive in different formats: PDFs, images, forms, or scanned documents. In other words, it transforms visual or semi-structured files into processable content.

But reading the document is not enough. In a validation process, it is not only important to know what the document says, but also what it means within the context of the case file.

This is where Amazon Bedrock comes in as the generative intelligence layer. Based on the extracted content, it helps classify document types, locate relevant fields, normalize information, detect potential inconsistencies, and generate reviewable warnings.

The concept can be summarized as follows:

• Textract transforms documents into content. Bedrock transforms content into context.
• Textract answers a technical question: What text and structure exist in this document?
• Bedrock helps answer business questions: What type of document is this? What relevant information does it contain? Is anything missing? Are there inconsistencies? What should a person review?

In this way, AI does not act as an absolute truth or a final judgment. It acts as an assistance layer that prepares the case file so the responsible professional can review it more effectively, more quickly, and with greater context.

What does this solution really deliver?

Beyond the technologies involved, the value of the project lies in changing the way people work with documentation:

• Reduces repetitive manual review.
• Enables earlier detection of missing documents and inconsistencies.
• Improves case-file traceability.
• Separates document upload from resource-intensive processing.
• Allows professionals to review issues instead of navigating disorganized folders.
• Turns AI into an assistance layer rather than a black-box decision engine.

The benefit is not only saving time. It is improving the starting point from which people work.

Project source code

The source code is available on GitHub. The repository contains the complete implementation of the solution: frontend, backend, asynchronous processing, AI integration, and cloud architecture.

Conclusion: less paperwork, more judgment

The implemented solution demonstrates a simple idea: AI creates the most value when it stops being an isolated demonstration and becomes part of a real process.

In this case, artificial intelligence is not used to replace professionals, but to prepare the work: extracting information, classifying documents, identifying warnings, and transforming scattered files into a structured case file.

The cloud architecture supports the workflow. Textract extracts the content. Bedrock interprets the information. But the final decision remains where it belongs: with the person who understands the context, and that is the interesting balance.

This is not about automating for the sake of automation or delegating sensitive decisions to a model. It is about reducing noise, eliminating repetitive work, and allowing professionals to spend more time reviewing what truly matters.

AI is not coming to take your job away just yet. However, if it is properly designed, it can certainly take a lot of paperwork off your hands. And perhaps that is the real short-term impact of AI in many organizations: not the sudden replacement of entire professions, but the elimination of repetitive work that prevents professionals from delivering greater value.

This article starts from an important premise. AI brings us tremendous benefits and has become an indispensable tool, not only for software developers but also for other technical roles, including QA professionals like myself.

By now, there are countless articles discussing the advantages of using AI. However, I find it much harder to come across content that addresses some of the issues that are increasingly emerging due to a “less-than-conscious” use of this technology.

Apparent Productivity vs. Real Quality

AI has multiplied our ability to generate code and deliver features at a speed that would have seemed impossible just a few years ago. In most cases, that is undeniably a positive development.

The problem arises when we start measuring productivity based on the number of closed tickets, commits, automated tests, or even AI prompts executed without considering the quality of the output.

Speed has increased, but that does not necessarily mean quality has improved as well, or even remained at the same level.

Sometimes we rush, even when nobody is explicitly asking us to. If Real Betis could wait six months for Isco Alarcón to recover from injury, surely a software feature can be delivered two days later.

Just as a football player can relapse if they return before fully recovering, code that is delivered prematurely will likely require rework if it has not received the necessary attention throughout all development phases.

In fact, many projects are beginning to experience something concerning. More issues are being detected in later stages, regressions are increasing, and maintenance is becoming more complex, even though it appears that teams are "moving faster."

The Problem and Its Possible Causes

Although this article reflects my personal opinion, naturally shaped by my own experiences, I must admit that my motivation for writing it comes from conversations with several colleagues in the industry.

After speaking with them, we all identified a common issue that, to a greater or lesser extent, was affecting our projects:

The number of bugs has increased significantly since AI entered our lives.

I do not want anyone to misunderstand me. This is by no means a criticism of AI. We are simply capable of producing much more code in much less time, and not only the positive aspects get amplified.

That is why, as I mentioned earlier, I want to make one thing clear:

The problem is not AI. The problem is how we are using it in some cases.

Requirements Definition

Requirements are the foundation of every software project. They were important before, and they are even more important now.

Having well-defined requirements has always been necessary, although it is something that still does not happen as often as we would like. This is not a new problem. Naturally, neither humans nor AI can perform miracles and deliver software without a clear understanding of what is actually needed.

AI has one major characteristic: it dramatically amplifies the quality of the information it receives. When requirements are clear and well defined, AI can become an incredible asset:

• It accelerates development.
• It generates useful and maintainable structures.
• It proposes valid solutions.
• It significantly reduces repetitive work.

However, when requirements are ambiguous, incomplete, or constantly changing, the effect can be the exact opposite.

That opposite effect is becoming increasingly noticeable. Generally speaking, we have not improved the quality of our requirements, yet we are delivering a greater volume of AI-generated code. The result is predictable: a considerable increase in the number of bugs over recent months and years.

The Deprofessionalization of Software Quality

More and more frequently, test automation is being delegated to people whose primary expertise is not quality engineering. This often happens under the assumption that "anyone can automate tests."

Personally, I believe there is an important confusion here between knowing how to use a tool such as Cypress or Playwright and truly understanding how to ensure software quality.

Automation is not simply about generating and executing automated tests. The truly difficult part lies in making decisions such as:

• What is actually worth testing.
• What risks exist.
• What impact each change may have.
• Which scenarios are critical.

This is where the expertise of quality specialists remains essential.

AI can help tremendously when generating tests or even entire test suites much faster than a human could. However, that does not guarantee that those tests are useful, meaningful, or strategically valuable. Just like application code, tests must be analyzed and understood.

In fact, a new risk is already emerging. Many teams are developing a false sense of coverage and security. They see plenty of tests, extensive automation, and green pipelines, but in reality there is little meaningful validation of critical business behavior.

Ultimately, this leads back to the same issue that should already sound familiar:

Bugs are increasing because many automated tests are failing to fulfill their purpose when validating new developments and preventing regressions.

Conscious Development

Earlier, I said that requirements are the foundation of every software project, but I must admit that is not entirely true.

For me, people are and always will be the true foundation.

One of the biggest risks we are starting to see is how some people’s relationship with the code they produce is changing.

A conscious developer (fortunately, most are) is not simply someone who manages to make a feature "work." It is someone who takes the time to understand the requirement, challenge it when necessary, analyze impacts, think about alternative scenarios, and care deeply about the final quality of the software being delivered.

AI dramatically accelerates code generation, but developers remain responsible for the code produced. That means it is equally important that they analyze it, understand it, and test it before delivery.

Unfortunately, we are increasingly seeing situations where AI-generated code is delivered without being properly analyzed, understood, or tested, and even cases where an AI-generated pull request is approved without sufficient review.

In the long term, this can create several problems:

• Poorly maintainable code.
• Developers who become technically stagnant.
• Developers who no longer fully understand their own applications, either functionally or technically.

My experience tells me that developers who were engaged before AI remain engaged today, while those who were not engaged before simply have their shortcomings exposed more clearly because they are now producing significantly more code.

AI can help us become dramatically more productive, but it should never replace something fundamental: technical responsibility for what we deliver.

What Can We Do?

AI is here to stay, and who knows how far it will go. It would be absurd to reject all the value it brings.

The goal should not be to use it less, but to use it better. Generating code has never been easier, and we should embrace that opportunity.

Regardless of our role, I believe many of the solutions are common to everyone, and they all share one thing: the passion and professionalism with which we approach our work.

We must continue insisting on high-quality requirements, and if they are not provided, we should help define them, because no one understands an application better than the people who build it.

We must also continue emphasizing the importance of assigning each task to the appropriate specialist, while clearly explaining the real consequences of failing to do so.

Finally and perhaps most importantly we must maintain genuine involvement and enthusiasm throughout every phase of the product lifecycle, without forgetting that AI should be a support tool, not a replacement for our commitment and engagement.

“The real problem is not whether machines think, but whether men do.” — B. F. Skinner.