My team has spent the better part of a year building AgentQL: a capability that doubles down on our decision. 

So let me explain what we actually built, why it doesn't just honor that architectural decision but depends on it, and the engineering choices underneath.

The Problem We Were Handed: The Expressibility Gap

Spotter answers most questions through search tokens: a structured, readable representation of intent that a business user can inspect and correct without knowing any query language. Tokens are the right default, and they remain the primary path.

But we kept hitting a wall we came to call the expressibility gap. We saw queries like “Show me customers whose spend this fiscal year declined versus last, ranked by the size of the drop." and "Compare each region's contribution margin against the company average.” Multi-step comparisons, level-of-detail calculations, cohort logic. 

Our query engine could answer every one of these and has been able to for years. The token grammar just couldn't state them. And every time we extended the grammar and retrained Spotter to emit it, new analytical features would land, and the gap would reopen.

We needed a richer language for expressing intent, which is how we came to build AgentQL. We did not need–and refused to build–a second execution path.

The Design Decision: SQL-Shaped Intent

We chose SQL syntax for the intent language for two practical engineering reasons:

• It’s the most precise, most widely understood notation for analytical questions ever created. 

• It’s the language LLMs are most heavily trained on. Any bespoke DSL we invented would have been worse on both counts.

But we took SQL's syntax and rejected SQL's execution model. That is the entire design. It's also the first principle behind AgentQL: intent and execution are separate layers. 

An AgentQL statement is written against the ThoughtSpot Model: the business names your analysts curated. Not physical tables or warehouse columns. 

And it is never, under any circumstance, executed against your database. There is no code path by which it could be. We know, because we built the code paths.

The distinction from text-to-SQL is not subtle:

A concrete example. "Total sales and total returns by product category" might be expressed as:

SELECT "t1"."Product Category",
       SUM("t1"."Sales Amount") AS "Total Sales",
       SUM("t1"."Return Amount") AS "Total Returns"
FROM "Retail Sales" AS "t1"
GROUP BY "t1"."Product Category"

That statement never runs, and it hides a trap. Behind the Model, sales and returns live in two separate fact tables that share the product dimension: a classic chasm trap.

Hand-written SQL that joins them directly fans out the rows and silently inflates both totals. The compiler knows better, because the Model does: it aggregates each fact at its own grain before combining them, resolves the declared join paths, and injects the querying user's row-level security filters. You can inspect the compiled SQL. The intent took seconds to express; the semantics it inherited took us a decade to engineer.

One consequence worth stating plainly: AgentQL is deliberately not all of SQL. It's a restricted dialect, and the restrictions are the contract. A statement must be fully resolvable against the Model, so the compiler rejects anything it can't deterministically govern, from SELECT * to constructs that would bypass the Model's semantics. 

We didn't restrict the dialect because parsing full SQL is hard. We restricted it because every accepted statement is a promise that the compiled query is governed, and we only accept statements we can keep that promise for.

Why We Refused to Make the LLM Do More

It's a fair question: LLMs are getting better fast, so why not just let a frontier LLM write the warehouse SQL and validate it after?

Because we've spent years engineering for what enterprise data actually looks like, and none of it is LLM-friendly. Real data models aren't flat tables. They're multi-star schemas with chasm traps and fan traps, like the sales-and-returns example above: join patterns where the wrong numbers look perfectly plausible.

Competent engineers get these wrong; we've watched it happen. They carry PII that must stay secured for every user on every query. They run different financial calendars per business unit. They define semi-additive measures like inventory and account balances, where a naive SUM across time is simply the wrong answer.

Ask an LLM to re-derive all of that, probabilistically, on every question, and you get exactly two things: uncertainty and a token bill.

Our engine already encodes those semantics. So the engineering answer was obvious, and it became the second principle: keep the LLM's job thin. Understand the question, express it compactly, and stop there. Everything that determines whether the number is right is inherited from the Model by construction.

The LLM cannot forget your row-level security, because it never writes the query that runs. It cannot pick a wrong join path, because the Model's joins are applied by the compiler. It cannot drift from your revenue definition, because there is exactly one, and every query compiles through it.

The failure mode matters just as much, and it's the third principle: a bad query is a compile error, not an incident. When the LLM expresses intent wrong, you get a wrong-but-governed answer or a clear validation error: the statement is rejected at compile time with a reason. 

These principles buy one more thing, and it's the one our customers care about most: trust. A deterministic compiler means the same question produces the same query specification, the same compiled SQL, and the same numbers, no matter which LLM expressed the intent or how it phrased it. Plenty of text-to-SQL tools will also show you the SQL that ran.

The difference is what reading it buys you. There, you're auditing an LLM's improvisation, query by query: did it pick the right joins, apply the right security, and use the right definition of revenue? 

Here, the SQL was compiled from the Model's governed definitions, so those questions are already answered. Verifying an answer means confirming the intent was understood, not re-deriving correctness by hand.

The Consequence: No Charging by Tokens

There's a byproduct of this architecture that shows up on the invoice rather than in the demo. Because the LLM's role is deliberately small, the heavy lifting runs on our deterministic engine, not on metered inference. A question doesn't spin up an agent that burns tokens re-reasoning about your schema.

Nobody wants an experience where every question comes with a meter running in the background. With this architecture, it doesn't have to.

The Same Bet, Doubled Down

Much of the industry is betting that with enough prompting, guardrails, and retries, LLMs will write trustworthy warehouse SQL. We made the opposite bet years before LLMs existed. AgentQL doubles down on it: the LLM should never write the query that executes. LLMs understand intent. A governed engine produces deterministic answers.

For Spotter users, the payoff is immediate: a far wider range of analytical questions answered today, without waiting for the token grammar to grow or for Spotter to be retrained on a new capability. If the engine can answer it, AgentQL can now ask it.

AgentQL gives intent a much richer language. The trust architecture didn't move an inch: it's in the engine, in the Model, and in your hands to verify. This is engineering by design, not by compromise - so you never have to choose between speed and trust.

Start your personalized demo to see how.

At our recent Agentic Analytics Playbook EMEA event in London, I had the pleasure of welcoming Craig Haughan, VP of Data Engineering—who led the data and analytics charge for CWT—on stage alongside Jimmy Hall, who leads Snowflake here in the UK and Ireland.

For those who don’t know CWT, they are an absolute powerhouse in corporate travel. If you’ve booked business flights, hotels, or itineraries, chances are CWT’s engines are running in the background. 

That means managing millions upon millions of complex, fast-moving data points.

Historically, legacy BI kept this data locked away in rigid, pre-defined PDFs. Today, CWT puts live, conversational insights directly into the hands of over 100,000 users. 

In fact, their analytics setup is so advanced that when they were acquired, the parent company explicitly called out CWT’s analytics capabilities as a primary driver of the acquisition.

Here is how Craig and his team leveraged ThoughtSpot and Snowflake to turn raw data into a premier business asset.

How Did CWT Go From Static PDFs Into Sub-Second Self-Service?

Before partnering with us, CWT’s data landscape was traditional, centralized, and slow. Business users relied on batch processing, legacy tools like Cognos, and static PDFs.

Craig walked our London audience through CWT’s analytics evolution, and it’s a masterclass in modernizing a data stack:

Why ThoughtSpot? The Power of Natural Language

CWT first crossed paths with ThoughtSpot nearly a decade ago, and over the years, our partnership has scaled into a deep integration of AI-driven conversational analytics.

From my conversations with Craig, the key differentiator has always been our relentless pace of innovation:

"You always worry about whether someone is going to come along with a better, more innovative product. But ThoughtSpot has always managed to stay a few years ahead of competitors. Where others focused on basic visualizations, ThoughtSpot focused on AI, search, and making self-service a reality." - Craig Haughan, VP of Data Engineering, CWT

The "Strawberries and Cream" Synergy: ThoughtSpot + Snowflake

After CWT implemented ThoughtSpot, it was quickly clear that there was a critical scalability issue as a result of their outdated data warehouse platform. 

Since we were in London during the height of the Wimbledon season, I couldn't help but use a very British analogy on stage: ThoughtSpot and Snowflake are the "strawberries and cream" of the modern data stack. You simply can't have world-class analytics without a world-class data platform.

By connecting ThoughtSpot’s intuitive semantic search layer to Snowflake’s highly scalable cloud data platform, CWT immediately put any scalability concerns in the past and achieved high-concurrency, real-time analytics.

• Horizontal Scaling: CWT serves over 100,000 regular users, including corporate travel clients and call center agents. Snowflake dynamically spins warehouses up and down to handle this massive concurrency without a single performance hiccup.

• Direct Live Query: Instead of extracting massive datasets into slow BI cubes, ThoughtSpot queries Snowflake directly.

• Unstructured Data Integration: CWT can pull together structured travel data with unstructured policy information (like complex corporate travel rules), allowing agents to easily verify travel compliance on the fly.

How Did CWT's Analytics Platform Influence Its Acquisition?

When CWT was acquired, Craig’s team faced the ultimate test. They spent three months showcasing their ThoughtSpot-powered self-service platform to their new parent company.

The verdict? CWT’s self-service capabilities were recognized as a generation ahead of what was currently in the market. Instead of replacing CWT’s stack, their platform with ThoughtSpot and Snowflake was chosen to roll out to their entire combined customer base.

As a sales leader, this is the ultimate validation of ROI: building an analytics system so robust that it actively increases the valuation of your entire enterprise.

Craig’s Playbook for Analytics Success

Craig shared two core pieces of advice that I think every data leader needs to hear:

1. The "Give a Sh*t" (GAS) Adoption Model

To get value out of data, you have to find the people who actually care about the outcome.

"There is no point in sending someone a PDF they aren't going to open. You have to find the people in your organization who really care and want to be successful with data. They will be infectious to everyone else. If your team doesn't understand why they should care about the data, you won't get adoption." - Craig Haughan, VP of Data Engineering, CWT

2. Be Brave

Entering the world of AI and modern BI can feel daunting, but inaction is the biggest risk.

"Be brave. When you're jumping into the AI/BI world, it is scary. But you've got to try it. I always tell my team: you're not trying hard enough if you don't break things once in a while (just don't break them in a bad way!). If you don't adopt AI, you're going to get left behind." - Craig Haughan, VP of Data Engineering, CWT

How You Can Experience the Future of Analytics

CWT’s journey proves that when you pair a powerful data cloud with intuitive, search-driven AI analytics, you don't just change how decisions are made—you fundamentally change the value of your business.

If you're based in the UK, Europe, or anywhere across our international markets, my team and I would love to show you how we can replicate this success for your business.

Ready to bring search-driven, agentic AI analytics to your data? Explore ThoughtSpot today.

As a data-driven CMO, I've lived this every day. I can know the instant something changes in the data, but there's still a large gap between insight and action. 

Today, we're closing that gap. 

I’m excited to share that we’ve launched AgentSpot, the agentic workforce platform to build workflows that decide, act, and deliver across every system your business runs on, grounded in your data. Anyone on your team can now build a team of agents that turns the insights they uncover into action.

A new operating model for work

AgentSpot turns repeatable tasks into agentic workflows that run on live data across your systems. It has context about your business, so the people who know that business best can build agents and workflows quickly, just by describing what needs to happen in plain language. AgentSpot builds the agents, steps, logic, and handoffs to run the task. Whether you are in Marketing, Finance, HR, Legal, Sales, or IT, everyone in your org can build agentic workflows. Here are just a few real-world examples:

• Marketing: AgentSpot can alert you if an email campaign starts to dip, show you where performance fell, and trigger the writers to fix it. When a campaign brief is finished, it can route the work in Slack, create the Asana tasks, and get the team started.

• Finance: AgentSpot can send budget exceptions to the right approvers, or pull together an RPO report from multiple revenue files, check SKU and arrangement matches, and export the reconciliation workbook.

• HR: AgentSpot can recommend learning paths using your company's content first, then outside resources where needed.

These are real agents, built by non-technical teams inside ThoughtSpot. No coding is required.

Grounded in trusted foundations

AgentSpot runs on the same live, governed, structured data our customers already trust.

Unlike general-purpose agents that start from scratch every session and guess at your business logic, AgentSpot is already grounded in your business’s semantic layer and works inside your enterprise guardrails from the first prompt.

With AgentSpot, ThoughtSpot doesn’t just help you see your business better: it helps you run it. 

Agents for action, workflows for execution, apps for artifacts

Agents do the thinking. Workflows repeat it. Apps show the results. AgentSpot brings all three together in one governed experience.

Agents reason, plan, and act on your live business data. They can monitor signals, ask clarifying questions, use tools, and bring back results.

Workflows turn your best playbooks into repeatable execution. They connect steps together, route handoffs, trigger actions, and keep running without someone having to restart the process every time.

Apps turn plain-language intent into live, connected artifacts that any team member can create. Describe what you need (e.g., a dashboard, report, or prototype) and get an app built on your real-time, governed data in a single session, with no front-end code or BI tickets.

Together, they uncover what needs attention, take action, and put the results in everyone's hands.

Built for where your business runs

AgentSpot connects to the systems your teams already use, including CRM, HCM, ERP, Slack, Gong, and more, so every agent can act using the same data and context your teams rely on. Here are just a few examples of how different departments can get more done with AgentSpot.

• RevOps: a "Deal Risk Monitor" agent that flags stalled opportunities and drafts recovery briefs.

• Finance: a "Budget Anomaly Checker" agent that routes approvals with context the moment a threshold is crossed.

• HR: an "Onboarding Milestone Agent" that keeps new hires on track without another manual check-in.

All built from a single prompt.

Now every team gets a force multiplier.

Governed by design

You can describe what needs to happen in natural language, and AgentSpot assembles the agent with the right workflows, tools, and context to do the work.

Anyone can build and share agents across the organization, so teams reuse what works instead of starting from scratch. Because AgentSpot connects to the tools your teams already use, those agents can bring together the data and context needed to get the job done.

The workflows are grounded in how your business operates. AgentSpot creates the steps, adapts as new data comes in, and executes tasks across systems.

Over time, it learns from organizational and user-level context, so the work becomes more relevant and better aligned to the way your teams actually operate.

This is the opposite of shadow AI: IT has visibility and control from the start. Every request, tool call, and model interaction is logged, with single sign-on, strict data isolation, and role-based access controlling what each person and agent can see and do.

Scale output, not headcount

In the age of AI, the advantage won't go to companies with the most people. It'll go to companies that can act faster on what their data is telling them.

AgentSpot gives every team a digital workforce that runs on live data, acts across systems, and keeps work moving. It's your workforce, multiplied, with predictable pricing built in. 

AgentSpot picks the right model for each job, balancing cost, speed, and capability, and routes work across models automatically. Your teams never have to think about token budgets; they focus on outcomes while AgentSpot optimizes the path.

We're confident you'll love it. Create your first three custom agents for free; you will not be charged for them.

You can learn more here.

When we first launched SpotGPT, our internal genAI application (similar to ChatGPT, but trained on internal resources) we saw immediate and massive adoption. However, the phase of simple queries quickly evolved into a sophisticated problem: our teams didn’t want just a chatbot, and instead started asking more and more for specialized digital colleagues.

As usage surged, our engineering and product teams were flooded with requests from across the business. Our Marketing, Finance, and HR teams weren't looking for generic AI advice but asking for agents with vertical-specific knowledge and the ability to autonomously move their unique workflows forward. They needed tools that understood the deep context of our business data and could act as a specialized teammate rather than a general-purpose bot.

We realized that for AI to truly transform an enterprise, it couldn’t remain a one-size-fits-all tool. We had to bridge the gap between "generic output" and "specialized action." The constant demand from our own subject matter experts to solve their most manual hurdles is what drove us to create a full custom agent platform, AgentSpot.

The Internal Challenge: "10 Agents for Every Team"

Instead of a standard closed beta, we issued a radical internal challenge: every department, regardless of their technical background, was tasked with building 10 agents to automate their most manual hurdles. We wanted to see if the people closest to the problems (our subject matter experts) could build their own solutions.

The response was a surge of cross-functional creativity that codified our "tribal knowledge" into functional tools:

• HR: Developed agents to streamline specialized workflows like an HR onboarding agent that guides new hires through documentation and provisions tool access automatically, and a Performance Review Assistant that aggregates peer feedback, OKR progress and activity data into structured review drafts.

• Finance: Created "Budget Guardians" that monitor departmental spend and alerts budget owners when thresholds are breached. 

• Sales: Built a Quote Generator Assistant that drafts customized pricing proposals from deal context, pricing tiers and rep notes. 

• Engineering: Has a Documentation Writer that auto-generates API docs, changelogs and runbooks from code diffs and PR descriptions.

• Marketing: Focused on campaign performance and content creation, with a campaign analyzer that pulls campaign metrics from ad platforms and surfaces what is working or wasting spend. 

By the end of the sprint, we had 80+ unique agents running internally. It was a collaborative build where every department helped shape the product they were excited to use.

Standing on the Data Plane: Our Competitive Edge

While generic AI tools promise revolution, business users often struggle with how to trust them or prompt them effectively. This is where AgentSpot differentiates itself from general-purpose bots through the data plane. Unlike managed agent platforms that often struggle with the "last mile" of data accuracy, AgentSpot enables fact-based actions by standing directly on ThoughtSpot’s rich semantic layer. By leveraging Spotter’s unmatched data analysis skills, our agents don't just guess based on unstructured context; they perform deep, accurate analysis on your structured business data. 

Unlike "black box" AI, our agents are deterministic and transparent. We provide a process you can visually check and trust, ensuring that every insight is grounded in your company’s governed data models. 

Furthermore, we’ve prioritized true self-service. AgentSpot is built so that any business user - not just engineers - can turn a simple problem statement into a directive, accurate prompt. This ease of use allows those closest to the business pain to create their own specialized agents without ever needing to become a "prompt engineer".

From Data to Outcome: Purpose-Built Agents, Apps and Workflows

AgentSpot moves beyond data and insights to true execution by turning your best playbooks into autonomous systems.

• Purpose-Built Teammates: These are named agents with specific roles and the judgment to know when to ask before acting. They reason, plan, and act on live data while remembering your specific role and history to ensure every answer is relevant.

• Data Apps: live, beautifully designed applications to present your work into a shareable artifact rather than a static file. Apps pull information from all connected sources: ThoughtSpot models, Salesforce, Jira, and more. It fetches fresh data on every load and enforces each viewer's permissions, so the right people always see the right data. But it is not constrained by the classic dashboard structure: newspaper-style briefs, card views, interactive boards, themed reports… Describe it, and AgentSpot will build and host it for you.

• Autonomous Workflows: You describe the desired outcome, and AgentSpot builds the logic and handoffs with no coding required. These adaptive flows can be scheduled to run on any cadence (daily,  weekly, etc.) ensuring repetitive tasks get done behind the scenes for you.

• The Model Context Protocol (MCP): Every agent acts on what is true because AgentSpot plugs directly into the tools your business runs on (CRM, HCM, ERP, Slack, and more) via the MCP standard.

Enterprise Grade: Governed from Day One

We built AgentSpot to give teams freedom from shadow AI: easy enough that anyone can use it, powerful enough that they'll want to, and governed closely enough that you can let them.

• Connector Governance: Admins maintain total authority over the ecosystem. They decide exactly which connectors are available to users, choosing which internal systems (like your CRM, HCM, or ERP) agents are permitted to access. 

• Sandboxed Execution: All code generated by agents runs in a secure, private container that cannot touch production systems.

• Auditability: Every request, tool call, and model interaction is logged, providing a traceable execution history for compliance and audit logging.

A Force Multiplier for R&D 

Building AgentSpot has fundamentally changed the roles within our R&D team. With AI accelerating research, requirements creation, and documentation by 5x to 10x, the lines between traditional functions have blurred. Our product design team has started building functional prototypes that engineers could bring into code immediately. PMs began contributing directly to internal tool codebases to increase iteration speed, skipping the "wait for a slot in the roadmap" phase of development. When everyone can dabble in the "other side", the conversation moves away from "is this possible?" to "is this the best solution?"

A Human-Centric Agent Launch

AgentSpot enables fact-based actions by standing on a rich data product with unparalleled skills in extracting insights from structured data. Our agents are grounded in data and transparent, providing a process you can visually check and trust. Unlike general-purpose bots, our platform is an expert at turning a business user’s problem statement into a directive, accurate prompt without requiring them to become a "prompt engineer".

We are launching AgentSpot with over 50 templates -each one born from an internal need, refined by a subject matter expert, and ready to help you drive your business autonomously. Get three custom agents for free. Learn more today.

Every data leader knows the BI waiting room. Someone in operations needs an answer, files a request, and waits a day, sometimes three. By the time the dashboard arrives, the moment that mattered has moved on.

That waiting room was the quiet subject of one of the sharpest sessions at the Agentic Analytics Playbook event in London. 

Brian Reynolds, VP of Embedded at ThoughtSpot, sat down with Sam Greenhalgh, Chief Revenue Officer at Zencargo, for a fireside chat titled "The Competitive Edge: Driving Business Outcomes Through Embedded Intelligence." 

The theme? A company that decided answers should reach its customers before anyone thinks to ask the question.

Here’s how Sam's story maps to the shift you’re probably chasing right now.

Why Is Real-Time Supply Chain Visibility So Difficult?

Start with the freight itself. Zencargo is a digital freight forwarder, moving goods around the world by sea, air, road, and rail. 

"Moving goods is still quite archaic," Sam told the room, describing a global system split across time zones, carriers, ports, and customs authorities, with no single party holding the full picture.

For Zencargo, the edge comes from data pulled out of hundreds of APIs across all those parties, then stitched into something a customer can actually question. 

Sam called data and insight early in the supply chain "the number one lever for how businesses can outperform their competitors," and that belief sat underneath everything else the session covered.

How Do You Move From Reactive Dashboards to Proactive Analytics?

Picture the old way of working. A customer needs to know whether a shipment will miss a retail launch date, so they route the question to a person, dig through a spreadsheet, or wait for BI. Every step adds delay, and delay in a supply chain is expensive.

Ask Luca, Zencargo's embedded assistant, was built to close that gap. Its name has an unglamorous origin - ask longtime customers what they did before Luca, and they name a person: "I'd ask Jack," or "I'd ask Bob." 

So the assistant became the colleague you can always reach, or in Sam's words, "an analyst in your pocket."

Here is the line that framed the whole conversation: Sam described the goal as turning "what ifs into what next," and that phrase captures the reactive-to-proactive shift every data leader is weighing in 2026.

Zencargo had analytics in its product for years, but moving to ThoughtSpot a couple of years ago let the team ship faster and customize far more of what customers saw. 

The payoff is proactive. Instead of waiting for a person to ask, the system can say: this is what's happening, these are your opportunities, these are your risks, and these are the decisions you need to make.

What Happens to Customer Retention When You Embed AI Analytics?

Adoption is the real test. Did it land? 

Ask Luca launched in October. By the time Sam took the stage, more than 100 Zencargo customers had adopted it, and the beta program now has a waiting list for additional models.

"We're the victim of our own success; customers are addicted to Luca," Sam said. 

That stickiness matters more here than at a typical software vendor. Different business model, different stakes. 

There is a second-order effect worth noting. Customer Success conversations moved away from tactical KPI readouts toward strategic, root-cause discussions, which makes Zencargo far harder to replace.

How Do You Know If Your Embedded Analytics Is Actually Working?

The proof point Sam kept returning to was dual use: two audiences, one assistant. Ask Luca faces customers, and it runs inside Zencargo's own operation too, with roughly 150 people in ThoughtSpot every day as part of their normal workflows.

A polished customer demo proves little on its own; the real tell is different. 

Your own teams reaching for the platform without being told to, day after day. At Zencargo, merchandising, supply planning, and trading all pulled up a chair once the answers came easily.

Should You Build or Buy Your Analytics Layer?

Every data leader in the room knows the build-versus-buy question, and Sam was blunt about getting it wrong at first. 

What was the mistake? Zencargo assumed the moat was data plus visualization, when anyone can build a visualization.

"The real moat was the data," he said. A simple line, a hard-won one. So Zencargo went deep where it could differentiate: execution, global supply chain knowledge, and context.

For the analytics layer, it chose ThoughtSpot Embedded over rebuilding one. Note the division of labor: Zencargo builds and owns its core live data platform, and ThoughtSpot owns the analytics layer on top.

Why Does AI Analytics Fail Non-Technical Users?

Not everything is solved yet, and Sam said so plainly. The request he hears most is cross-functional. 

It’s typically items like purchase order SKUs and marketing launch dates, read alongside shipping, supply chain analytics, and customs data. Joining those sets cleanly is the work ahead.

That kind of honesty about the boundary is what makes the rest of the story credible.

What Does the Future of Agentic Analytics Look Like? Sam’s Advice

Sam's vision for Ask Luca 2.0 moves past asking altogether. Imagine Luca looking across a customer's past decisions, their supply chain, and outside signals like geopolitical events, news, and port disruptions, then surfacing a recommended action: move it by air, or split the shipment. 

But get the data structure right before you fall in love with the interface—the analytics layer is only ever as good as what sits beneath it. The companies turning "what ifs" into "what next" are the ones that treated their data model as the product. 

Want to see what that looks like on your own data? Start your free ThoughtSpot trial today.

Vita Mojo powers the digital infrastructure for quick-service restaurants (QSRs) across Europe. Operating in a high-transaction, low-margin industry, their restaurant clients are flooded with transactional data—from click-and-collect orders and self-service kiosks to point-of-sale systems and kitchen fulfillment. However, most QSR operators are severely constrained by small head-office teams and lack dedicated in-house data analysts.

Here is how Vita Mojo shifted its strategy to empower non-analysts across the long tail and drive C-suite adoption using ThoughtSpot Embedded and Spotter.

1. Empowering the "80% Long Tail" of Non-Analysts

Before adopting ThoughtSpot, Vita Mojo faced a common challenge in embedded analytics:

• The 5-Tool Cycle: Over several years, Vita Mojo cycled through five different embedded BI tools—including Domo, Power BI, Metabase, Looker, and Redash—spending over a year evaluating each without finding the right fit.

• The "15% Trap": Traditional dashboards required power-user knowledge. Vita Mojo discovered that only 15% to 20% of their customer base (usually a data-savvy enthusiast in accounting or operations) were actively extracting value from advanced analytics.

• Decisions in a Vacuum: The remaining 80%—the long tail of operators—didn’t have the bandwidth or expertise to navigate complex dashboards. As a result, they were making daily operational decisions without data.

To solve this, Vita Mojo partnered with ThoughtSpot to flip its strategy. Rather than building solely for power users, their new North Star became reducing time-to-insight from days down to minutes for non-analysts.

By integrating ThoughtSpot Embedded and Spotter (ThoughtSpot's natural language and AI search engine), Vita Mojo replaced complex drill-downs with simple, plain-English search. Operators can now ask questions directly, instantly obtaining analyst-grade insights without needing a technical background.

"We had a North Star of reducing time to insight so that this long tail can get there... from days or initial investment to minutes."

— Stefan Cotoiu, Co-Founder at Vita Mojo

2. Driving C-Suite Adoption and Executive Visibility

Putting conversational AI directly into the Vita Mojo platform produced an unexpected shift in adoption: it brought top-level restaurant executives to engage directly with data.

• Direct Executive Engagement: Vita Mojo originally anticipated that restaurant general managers would be the primary users of natural language search. Instead, they saw a significant surge in engagement from C-suite leaders—including Managing Directors, CEOs, Heads of Marketing, and VPs of Commercial. These leaders understood the business deeply but previously lacked dedicated analyst bandwidth to answer strategic questions quickly.

• Automated ROI Messaging: Vita Mojo leverages ThoughtSpot's auditability and usage data to build a highly targeted go-to-market loop. They proactively send personalized ROI reports to executive buyers during trials, showing concrete metrics: "You saved X hours of analyst time and evaluated £Y million in operational decisions using our analytics engine."

Key Takeaways for Product and Analytics Leaders

• Focus on the Non-Analyst: Designing analytics solely for power users leaves the majority of your customer base behind. Conversational AI bridges the gap between raw data and business intuition.

• Prioritize Trust and Governance: High-quality, traceable data is essential. Bypassing the "BI waiting room" only works when users can trust that the numbers behind natural language answers are grounded in trusted data.

• Treat Analytics as a Core Product: Embedded analytics requires dedicated product management and clear go-to-market messaging to ensure customers recognize the operational and financial value being delivered.

By prioritizing customer empowerment for non-analysts and driving executive adoption, Vita Mojo turned data from an overwhelming byproduct into a primary competitive advantage.

Ready to empower every user with AI-powered embedded analytics? Request a demo to see ThoughtSpot Embedded in action.

That initiative has just taken its most consequential step yet. OSI has entered the Apache Software Foundation’s (ASF) incubator and, as part of that transition, has been renamed Apache Ossie (Incubating).

The specification and the community behind it haven't changed. What has changed is the governance model: Ossie now operates under ASF norms, with public mailing lists, GitHub-based development, and committership earned through contribution rather than employer affiliation.

ThoughtSpot was a founding member of OSI, and we're continuing that commitment under its new name and its new home at the ASF. This move strengthens the standard itself and benefits anyone building a data and AI stack who doesn't want to be locked into one vendor's definition of "revenue."

Where ThoughtSpot Has Contributed

Since OSI's founding, our team has been an active contributor across all of its working groups— Metric Language, Catalog, and Ontology—that governs how semantic objects relate to each other.

That's meant sitting in the same room—literally and in GitHub threads—as engineers from Snowflake, Databricks, dbt Labs, Atlan, and other partners, and finding shared ground on how a metric, a dimension, or a join should be described, so that any tool can read it correctly.

An open standard only works if it stays vendor-neutral. Ossie's move to Apache Software Foundation governance formalizes that neutrality, making the standard more durable and more trustworthy for the organizations that will eventually depend on it.

What's Next: A Translation Layer for TML

Looking ahead, we're building a translation layer between ThoughtSpot Modeling Language (TML)—the format ThoughtSpot uses to define and version semantic models—and the Ossie specification.

The goal is to let semantic definitions built in ThoughtSpot move into the broader Ossie ecosystem, and vice versa, without anyone having to hand-translate metric logic between formats. This is an active workstream and we'll share specifics as the translation layer takes shape.

This work connects directly to the ThoughtSpot’s context layer for agents, in which Spotter Semantics already uses deterministic query generation grounded in governed business definitions rather than probabilistic guessing. A shared, open format like Ossie extends that governance beyond ThoughtSpot itself—so the same trusted definitions travel with a query no matter which AI agent, LLM, or platform is running it.

Why This Matters

For a data leader, the pitch for an open semantic standard isn't abstract. It's fewer reconciliation meetings between finance and sales over whose "churn rate" is correct. It's the ability to swap or add a BI tool, a catalog, or an AI agent without re-writing your metric logic from scratch. And as more of the actual querying in your organization gets delegated to AI agents, it's the difference between an agent that guesses at what "net margin" means and one that inherits a definition your team already approved.

We're genuinely energized about where this goes next. Apache Ossie starting incubation with a coalition that has grown from its original founding group to more than 50 participating organizations is a strong signal that the industry wants this problem solved collectively. We plan to keep showing up to that work.

Get involved

Ossie is transitioning to ASF infrastructure as part of incubation. Watch for updates on the new project website, join the development mailing list, collaborate on GitHub and join the Ossie Slack workspace.

If you want to see how a governed semantic layer already works in practice, get a demo of ThoughtSpot.

A Head of Product at a major sportswear retailer has a brilliant idea: let’s build an app that sales staff on the shop floor can have on their tablets, and ask their questions there and then, where they serve customers. 

They set about building. In order for the app to answer questions, it needs to have the information from the 2026 Spring/Summer Catalogue, a mammoth manual, let’s say 300k tokens. 

Then the developer loads the huge PDF into the system instructions of the LLM and builds a chat interface over it. 

When the sales assistant in the store asks about Adidas Gazelles, the LLM reads the entire 300k-token book, finds the answer on page 89 and page 607, and delivers a response. The staff loves the POC, and it’s pushed for production.

The app gets rolled out to all stores - the 5000 sales assistants ask it 10 questions a day each. The app is processing 15bn input tokens a day, creating something that never happened when it was a POC: a $75k daily run rate. 

Production environments are where AI budgets expand horribly. A working prototype can become a 75k/day liability overnight. And that’s where the CFO shuts it right down. 

Not only is the hero app dead, but the CFO issues strict guidelines and a new era of token-rationing in the company begins. 

This is not a drill - average enterprise AI budgets expanded from roughly $1.2 million annually in 2024 to about $7 million in 2026. Uber recently became a cautionary tale when its AI spending spiral made headlines for the wrong reasons. And it won't be the last.

Welcome to 2026 and the token cost crisis. 

Why Token Costs Are Suddenly Huge Financial Exposure

What we just saw was classic context stuffing. Brute-forcing that bypasses complex data engineering and is essentially the quickest way to get to a working prototype.

Context stuffing is just one of the symptoms of the bigger problem of token over-consumption due to lazy architecture and bad management practices. This is something organisations need to pay attention to as they transition from having agents in PoC to production environments. 

This is where poor architecture can become wildly expensive and opens up a new era of tech debt (and potentially financial debt!).

In addition to context-stuffing, other token-bonfires include:

Cache Blindness

The same questions/instructions are sent again and again without leveraging middleware or native caching layers. 

Token Amplification

Where agents talk to each other in multi-agent workflows, e.g. agent A sends a 5k token history to agent B who sends 5k back. The context grows quadratically unless there is summarisation or state-pruning. 

Poor state management forces the LLM to re-process large conversation histories with each query in the conversation, while wasting output tokens on heavy JSON schemas. 

‘Token-Maxxing’ 

This is the dubious trend where companies and individuals measure AI productivity by the sheer volume of tokens consumed; it's essentially the ‘lines of code’ KPI for the agentic era. 

It’s the ‘tyranny of metrics’ - something that the developer community is becoming increasingly vocal about, with stories of code-slop and usage becoming a proxy for value.

Sonny Rivera, principal data and AI strategist and former Chief Product Officer of TIFIN, advocates for ‘inference opps’ where good practices keep token burn manageable, and token-maxxing is discouraged. 

The Three Pillars for ‘Inference Finops’

At ThoughtSpot, we believe that ‘inference finops’ is a mandatory engineering discipline to transition from prototype to sustainable production. 

Here are our pillars of ‘inference finops’ in distinct architectural layers:

1. Data Architecture and RAG Standard

Transitioning from massive context windows to clean retrieval-augmented generation (RAG) and using ‘chunking’ to lower the LLM processing burden and get the same answers for a fraction of the costs.

Let’s go back to the earlier example of the sports store. If, instead of rushing to production, the engineering team architect a RAG pipeline. They take the Spring/Summer Catalogue and chop it up into bits - a process called ‘chunking’. 

So the Adidas Gazelles become a chunk. The Nike Airs become a chunk, and the return policy becomes a chunk. These chunks are converted into vector embeddings and indexed in a specialized vector store, such as the enterprise PostgreSQL using the vector extension. 

Now, when the sales assistant asks the question, the system acts like a librarian and sends the LLM to the right paragraphs and has it answer based only on those two using maybe 80 tokens. 

The 50k daily queries from all the stores come to a cost of $200 a day (down from $75k!) and the assistant gets the exact same answer. 

2. Model Routing to Move From Data Shortcuts to Compute Efficiency

You don't need the power and glory of Mythos to help you understand why there’s excess inventory of those fuzzy pink jackets in the warehouse. 

Rather than hardwiring an application to a single LLM, an agent harness framework like LangChain or LlamaIndex can intercept the prompt, classify its complexity, and dispatch it to an open-source model like Mistral that’s free to run, or internally hosted small models running on your own cloud instances.

For example, ThoughtSpot acts as an optimised, built-in harness—defaulting to a combination of Opus 4.5 and GPT-5.1 for complex analytical questions and dropping down to Haiku for summarizing an insight, ensuring you use the most cost-efficient LLM for the task at hand. And yes, customers can also bring their own LLM. 

So if we take the retail example again, if the router saw a prompt that asked it to do something simple like run a search, it would route to a more affordable model. 

If the prompt was more complex and required reasoning, e.g., ‘which of these shoes are better for a customer with plantar fasciitis, it would route it to something like Opus 4.5.

A piece of insight for CDAIOS: We tend to focus on the price per 1k tokens to decide what the most cost-effective model is. Databricks proved this completely wrong in their recent article here - they found that models with a cheaper list price, when run over end-to-end tasks, actually ended up being more expensive due to the way they work and consume.

3. Semantic Caching 

Semantic caching, unlike traditional caching, caches based on meaning rather than exact character matches. So it not only remembers the exact question, it remembers similar questions too. 

So, ‘what is Q2 revenue?’ and “what is this quarter's revenue?’ are treated as the same question. And you pay only once. 

Again, there is a mode of action that relies on interception from specialist tools; instead of sending the raw string to the database, it’s converted and scored, and a pre-stored LLM response from the database is sent back. 

Implemented at the enterprise API gateway level, specialist middleware intercepts the prompt, converts it to a vector to score against historical queries, and can match to a previous, pre-stored response (if there is one) without incurring token spend.

There is a misconception that native query caching (in, for example, Anthropic and OpenAI models) negates the need for semantic caching. This is not correct. Semantic caching and native prompt caching are different tools doing different jobs. 

Native caching stores the static prefix (for example, in the sports store example, the 300k token catalogue) so you get a ‘discount’ on input tokens when you call the model. The user's questions are not cached. You need semantic caching for this.

It’s worth remembering that semantic caching handles unstructured text data well but struggles with numbers. Spotter Semantics uses a tokenised search hard-linked to the database schema, which is highly optimised for query caching, resulting in up to 90% lower token spend. 

The Metadata Moat and Predictable Search Architectures

Good practices around metadata can turn a 100k token query into a 1k token query. Good metadata (data about data) attached to your documents means that an LLM has to scan fewer documents to get to an answer - it can hone in on relevant documents rather than have to scan many docs trying to find a ‘needle in a haystack.’ 

As an example in the sporting goods store, let’s consider the question ‘what’s our returns policy on Nike Air if the customer lost the receipt?’ 

Without good metadata, the LLM has to scan everything that mentions returns, receipts, Nike, etc. With metadata pre-filtering (e.g., Region: UK, channel = in-store, doc type = returns policy, etc.) lets the LLM zone in on the right docs using far fewer tokens.

ThoughtSpot’s architecture shows us a way to do this: Spotter’s NLQ analytics does not use an LLM for text-SQL generation; instead, it uses a tokenised search. 

Because ThoughtSpot’s tokens are linked to a physical database schema, this mode of action is highly deterministic; it produces a very efficient SQL that yields a much lower and more predictable token cost.

A Procurement Blindspot the CDAIO Must Shed Light On

At ThoughtSpot, we know from many frank conversations with our customer CDAIOS, that in many organizations, procurement functions are negotiating contracts with cost bases that are rapidly changing. 

It will be the job of the CDAIO to be clear about these potential risks to the board and the wider organisation. We expect that tokens will eventually just come under the cost control of the CFO, the same way other things do, like travel spend. 

The CDAIO will need to help establish this and ideally, get a handle on the framework before the CFO comes looking for it!

In fact, EY’s recent white paper advocates for hiring a Head of Agent Economics. You may not need to take quite such a big step, but certainly CDAIOs need to be fully on top of this space. 

The Inference Finops Playbook: A Checklist for CDAIOs

• Audit the sandbox - understand where dev teams are context-stuffing in pilots and get a clear view of where this could potentially turn into production liabilities.

• Set architectural standards that are requirements for production. Mandate chunking architectures and production deployment standards.

• Implement a routing framework to ensure the right model is used for the right task.

• Establish a partnership between the CDAIO, CFO, and procurement to ensure contracts are vetted for token liabilities before they are signed off.

Token-Maxxing: Frequently Asked Questions

1. What Is Token-Maxxing, and Is It Actually a Good Thing?

No. Despite the name, token-maxxing isn't a strategy; it's a symptom. It's what happens when teams (or leadership) start treating raw AI token consumption as a proxy for productivity or value, the same trap "lines of code" was for developers a decade ago. High token usage can just as easily mean bloated context, redundant calls, and lazy architecture as it can mean real output.

2. How Do I Know If My Company Is Token-Maxxing Without Realizing It?

Pull your production invoices and compare them against sandbox costs. If your engineering team can't explain the gap, you already know. Then ask how they plan to fix it: "use it less" is not the right call, because this isn't a volume problem. Start with a sandbox audit. Most token-maxxing traces back to a pilot that went to production before the architecture got a second look.

3. What's the Difference Between Token-Maxxing and Inference FinOps?

Token-maxxing measures success by volume consumed. Inference FinOps measures success by outcome per token spent, and treats token burn as an engineering discipline, not a productivity metric. One rewards the behavior that inflates your bill; the other is the fix for it.

4. Who Should Own Inference Cost Governance: Engineering, Finance, or the CDAIO?

Right now, usually nobody. Token spend has grown fast enough that it needs the same kind of ownership travel or cloud spend already has, and the CDAIO is best positioned to bridge the technical architecture side with the CFO and procurement before contracts get signed, not after the bill arrives.

5. Can I Fix Token-Maxxing Without Ripping Out My Existing AI Stack?

Yes. This is architectural discipline, not a rebuild. Moving from context-stuffing to RAG and chunking, adding model routing so simple queries don't hit your most expensive model, and layering in semantic caching can all be retrofitted onto an existing stack without starting over.

That stat set the stage for a candid, wide-ranging conversation between Ivan Seow from ThoughtSpot and Jeff Rubinson, VP of Product at Endpoint Clinical, during the June 25 webinar "Bridging the Embedded Analytics Revenue Gap." 

What followed was part research briefing, part real-world case study, and part honest advice for anyone building analytics into a product. Here’s what stood out.

The Revenue Gap Is Real, and It’s Not About Adoption

If embedded analytics was struggling because nobody used it, the fix would be straightforward: improve the product, drive adoption, measure results. But the Product Led Alliance Embedded Analytics Opportunity 2026 Report featured in the webinar tells a different story. 

71% of product leaders are already building or using embedded analytics. 50% report increased engagement and stickiness. People are using the dashboards, clicking around, spending time.

So why does more than half the market still see no measurable ROI?

Most product teams haven't calculated the real cost of their embedded analytics approach. 

As Parul Jain, Principal PM at Walmart, put it: "The gap exists because many teams measure usage, not business impact." 

Ivan echoed this during the webinar: "ROI doesn't come from just usage, but it comes from impact." 

The distinction matters. Tracking page views, session times, and click rates tells you whether someone opened a dashboard; it tells you nothing about whether that dashboard changed a decision, a behavior, or a business outcome.

Three Problems Hiding Behind One Gap

Ivan walked through the research and identified three root causes that explain why teams with healthy usage numbers still can't prove ROI.

1. A Problem of Focus

Too many teams treat analytics as a feature checkbox rather than a product strategy. When analytics is positioned as "nice to have" rather than a competitive differentiator, it gets the attention (and the engineering investment) of a nice-to-have.

2. A Problem of Tools

Static dashboards can show you what happened, but they can't tell you whether anyone acted on what they saw. If your analytics experience ends at a chart, you have no way to measure whether the insight influenced a downstream decision.

3. A Problem of Instrumentation

Teams are measuring the wrong things. When your success metrics are clicks, views, and time on page, you are optimizing for engagement theater rather than business outcomes. 

Did the analytics change a decision? Did it alter a behavior? Did it produce a measurable result? 

Those are harder questions to answer, and most instrumentation isn't set up to answer them.

Endpoint Clinical's Story: 15 Years of Building, Three Months of Shipping

This is where the conversation shifted from research to lived experience. Jeff Rubinson has spent 15 years at Endpoint Clinical, which has operated roughly 2,500 clinical trials across 90+ countries. 

Clinical trial supply typically accounts for 10-30% or more of the total trial budget, so getting the analytics right has real financial consequences.

Jeff didn't sugarcoat the history. "As a product leader, I always say there's a couple of things you don't want to do internally," he said. "One is analytics."

Over those 15 years, Endpoint tried building analytics in-house multiple times. Each attempt ran into the same compounding problem: building analytics is not a one-time investment. 

Every data model evolution, every new customer expectation, every AI capability that your users start asking about adds another layer of maintenance. And every month your team spends maintaining that infrastructure is a month they are not spending on the product that makes your company unique.

Jeff framed the real cost clearly: "It's not just the cost that you save for the implementation and the maintenance and the continuous support. But it's also the value that is lost by not being able to focus on your core competency."

The Decision to Buy, and The Speed That Followed

Endpoint signed with ThoughtSpot in December 2025 and launched Elo AI, their new analytics experience, in March 2026. Three months. With approximately 1.5 full-time resources dedicated to the implementation.

What does Elo AI include? Conversational AI that lets clinical trial managers ask questions of their supply chain data in plain language, deep analysis mode for more complex investigations, and actionable recommendations that connect insights directly to decisions. 

Jeff described the customer reaction: "When we demo this solution, it's almost like magic to some of our customers."

That three-month timeline reframes what's possible for any product leader who has been told, or has assumed, that embedded analytics is a two-year build cycle. 

It also underscores a pattern the research confirms: teams on the right side of the ROI gap have done four things differently:

• They replaced static dashboards with interactive, user-driven analytics

• They delivered intelligent analytics experiences in months rather than years

• They focused engineering resources on their core product

• And they closed the loop from insight to action inside the product itself

The AI Dimension: Planning Versus Production

The webinar surfaced a tension that many product leaders will recognize. 79% of product leaders say AI has fundamentally changed how they think about building, buying, and deploying analytics. 91% plan to invest in AI in the next 12-18 months. But only 14% have actually shipped AI-powered analytics to customers.

Why is the gap between planning and production so wide? Ivan pointed to what he called the "two impulses" AI creates. The first impulse is to build everything yourself because AI tools make it seem possible. 

The second, less obvious realization is that AI actually raises the complexity bar. Building a reliable natural language interface, an embedded agentic experience, proper security and governance, performance at scale: these are not weekend projects, and they compound fast.

Jeff's advice to other product leaders was direct: "Do what you do best. Focus on your data, focus on your core competencies, and then leverage the experts to do what they do best. Because it's not a one-time implementation. It's a lifestyle."

What Users Actually Want

The research gave a clear signal on what end users are asking for. 74% want real-time data access. 71% want to intuitively find answers for themselves rather than waiting for a report. And 29% want to take action directly from analytics into the other tools they use.

That last number is worth sitting with. Nearly a third of users are already asking for analytics that connects to action, not just information. If your analytics experience ends at a chart with no path to a decision or a workflow, you are building for a shrinking portion of user expectations.

Three Takeaways Worth Carrying Forward

If you are evaluating your embedded analytics strategy or deciding whether to build or buy, this webinar surfaced three ideas worth remembering.

1.Measure What Matters

Usage metrics are not ROI metrics. If you cannot trace a line from your analytics to a decision, a behavior change, or a business outcome, you are measuring the wrong things.

2. Speed Is a Strategic Advantage

Endpoint went from contract to launch in three months. That timeline didn't just get their product to market faster; it freed their engineering team to focus on the clinical trial supply chain problems that only Endpoint can solve.

3. The Build-versus-buy Math Has Changed

AI capabilities have raised the bar for what users expect from embedded analytics. Building and maintaining a conversational AI layer, an agentic experience, and a governed data pipeline on your own is a compounding commitment. 

For most teams, the smarter path is to focus your engineering on what differentiates your product and let a purpose-built platform handle the analytics layer.

As Jeff put it: "It's a lifestyle." The question is whether you want that lifestyle to be maintaining analytics infrastructure, or building the product that sets your company apart.

Read the Endpoint Clinical case study here or watch the webinar on-demand. 

At a recent fireside chat on the Agentic Analytics Stage, I sat down with Joachim Höffner, Verivox’s Lead Data & BI Engineer, to explore a provocative question: Is traditional BI dying, or is agentic analytics the progress we’ve been waiting for?

For Verivox, the answer isn’t about choosing one over the other—it’s about a fundamental shift in the "operating model" of data.

The "Dashboard-Driven" Trap

The debate began with a blunt assessment of the status quo: Most companies are not data-driven; they are dashboard-driven. At Verivox, the team recognized this pattern early on. While dashboards are great for monitoring, they often fail at the explanation phase. 

When a KPI turns red, the dashboard rarely tells you why. This usually triggers a manual cycle:

1. Management sees a dip in the dashboard.

2. A request is sent to the data team.

3. Days later, an answer arrives.

4. By then, the decision has often already been made based on intuition.

The willingness to be data-driven exists, but the information isn't available fast enough. To bridge this gap, Verivox has spent the last 18 months moving beyond static reporting toward a more conversational, agentic approach.

Agentic Analytics: A New Operating Model

Verivox has been testing AI-driven chat systems that allow business users to skip the ticket queue and ask questions directly. This "search-based" approach, which Joachim first explored with ThoughtSpot years ago, has now evolved into a world where AI agents don't just find data—they analyze relationships and explain variances.

"It is about fundamentally changing how questions are asked and answered. Business users can increasingly obtain answers independently without always relying on specialists." - Joachim Höffner, Lead Data & BI Engineer, Verivox

However, that independence doesn't come automatically. 

The Reality Check: Trust and Human Responsibility

Despite the excitement, Verivox’s journey has been grounded in pragmatism. AI isn't a magic wand, and hallucinations were a real technical hurdle.

• The 1+1 Test: Some companies lose trust in AI when it fails simple logic tests.

• Consistency is King: "Creative" answers are a liability in enterprise settings—Verivox requires deterministic results, with the AI giving the same accurate answer every time.

• The Human Guardrail: At Verivox, the responsibility still lies with the human. Employees are being trained not just to use AI, but to critically evaluate its output.

This human-in-the-loop approach is also what keeps traditional BI relevant—not as a fallback, but as the foundation AI works on top of.

Will Dashboards Disappear?

Dashboards will return to their original purpose: providing a high-level view of core company health. When an anomaly appears, that’s when the agent steps in. 

Instead of building a new dashboard to investigate a trend, a user will engage an AI agent to perform the deep dive, potentially saving days of manual labor.

The Best Time to Start your Agentic Analytics Journey is Now

The speed of development is exponential, especially with the next generation of talent already using AI as a primary tool for problem-solving. For Verivox, staying ahead means:

1. Defining Business Value: Not doing AI for the sake of AI, but identifying where it speeds up decision-making.

2. Focusing on Governance: Ensuring that as data becomes more accessible, it remains secure and compliant.

3. Experimentation: Accepting that while we don't know exactly where the journey ends, the cost of standing still is too high.

The verdict? Traditional BI isn't investing in the past: it’s the baseline. But if you want to move at the speed of the modern market, you need to start building your agentic future today.

Check out how ThoughtSpot is supporting Verivox’s agentic journey and can do the same for your team – click here for a demo.