Author: Shikha Pilley

  • The 5 AI agent platforms to look out for in 2026

    The 5 AI agent platforms to look out for in 2026

    Enterprise agentic AI moved from pilot budgets to production commitments faster than most other categories of enterprise software. That speed created a side effect worth naming upfront: one industry guide to this exact topic calls out “agent washing,” vendors relabeling existing chatbots, RPA scripts, or linear workflow tools as agents without the underlying system actually doing autonomous, multi-step reasoning. The same guide argues genuine agentic AI requires autonomous decision-making, multi-step reasoning, and dynamic error handling, and that most products marketed this way do not clear that bar.

    With that caveat in mind, five platforms show up consistently across independent comparison sources (not just their own marketing) as the ones enterprise teams are actually deploying in production. This list is organized by the enterprise system each one is built around, since that is the factor most buyer’s guides agree should drive the decision.

    1. Salesforce Agentforce

    Agentforce is Salesforce’s agent platform, built to operate directly on Salesforce’s own data model so agents work against current CRM records without a separate synchronization layer. Governance runs through Salesforce’s Einstein Trust Layer and existing audit logs, and MuleSoft extends its reach into other systems. As of independent 2026 coverage, Salesforce has closed roughly 29,000 Agentforce deals since launch, generating around $800 million in annual recurring revenue, figures reported externally rather than only claimed by Salesforce itself.

    Best for: organizations already running Salesforce as their primary CRM who want agents acting on live customer data without a new integration layer.

    2. Microsoft Copilot Studio

    Copilot Studio is Microsoft’s low-code agent builder, with independent 2026 reporting citing roughly 160,000 organizations running more than 400,000 custom agents on the platform. Its core strength is depth of integration across the Microsoft ecosystem, Microsoft 365, Dynamics, and Azure, making it the practical default for organizations already standardized on Microsoft’s stack. Comparison guides consistently note it alongside Agentforce as one of the two platforms with the fastest time to production for pre-built use cases, typically four to six weeks.

    Best for: Microsoft-centric organizations that want agent building accessible to business users, not only engineering teams.

    3. ServiceNow AI Agents

    ServiceNow’s agent capabilities sit inside its existing IT service management, HR, and customer service management workflows, under the Now Assist feature set. In April 2026, ServiceNow restructured its commercial model to embed an AI Control Tower and Workflow Data Fabric across every pricing tier by default rather than as an add-on, a move independent coverage described as a signal that governance-first architecture is becoming a baseline market expectation, not a premium feature. ServiceNow also acquired Moveworks in late 2025, which now operates under the ServiceNow umbrella and extends its employee-facing agent capabilities across Slack and Microsoft Teams with more than 100 pre-built integrations.

    Best for: large enterprises already running ServiceNow for IT service management that want to extend agent-driven support into HR and broader employee operations.

    4. SAP Joule Studio

    SAP’s agent platform evolved substantially through 2026. Joule Studio, a full agent builder on SAP’s Business Technology Platform, reached general availability in Q1 2026, and Joule Studio 2.0 followed at SAP Sapphire in May 2026 with a fully managed, zero-infrastructure version aimed at citizen developers rather than only professional coders, backed by a 100 million euro partner fund. SAP describes agents built this way as natively grounded in a business’s existing SAP data, processes, and semantics rather than connected to them afterward. Reported agent and skill counts vary by source and by which specific SAP AI product is being described, ranging from roughly 40 specialized agents and 2,400 skills in one 2026 analysis to 200 domain-specific agents announced with Joule Studio 2.0, so treat any single number as a snapshot rather than a fixed figure, and confirm current scope directly with SAP.

    Best for: enterprises running SAP as their core ERP that want agents grounded in existing SAP business processes without a separate integration project.

    5. IBM watsonx Orchestrate

    watsonx Orchestrate positions itself as a governance-first control plane rather than a single-vendor agent builder, with a stated skills catalog of more than 150 pre-built automations and integrations spanning SAP, Salesforce, and ServiceNow. Independent buyer’s guides consistently rate its governance and auditability as the strongest in this category, describing it as built for large, regulated enterprises where explainability is not optional, with the tradeoff that deployment cycles tend to run longer than SaaS-native competitors due to procurement rigor. IBM also released an Agent Management Platform in March 2026, a vendor-agnostic governance layer that can manage agents across other frameworks and vendors, including LangGraph, CrewAI, Google’s Agent Development Kit, AWS AgentCore, Microsoft Foundry, and Salesforce Agentforce, from a single control plane.

    Best for: regulated enterprises running multiple AI agent vendors or frameworks that need one governance layer over all of them, not just IBM’s own agents.

    The pattern worth noticing

    Every platform on this list leads with governance and grounding in existing business systems, not raw agent capability alone. That is not a coincidence. Gartner’s own 2026 Analytics and BI Magic Quadrant made a related point for the adjacent BI category: success increasingly depends on more than a large language model, it requires governed business context and the ability to operationalize decisions inside existing workflows. The same logic applies here. An agent that reasons well but cannot prove what it touched, why, and under whose permission is a harder sell in an enterprise than a system that is somewhat less flashy but fully auditable.

  • QuaerisAI Now Connects to ClickHouse

    QuaerisAI Now Connects to ClickHouse

    Real-time data is becoming central to how modern teams operate. Marketing teams need to understand campaign movement. Finance teams need to review usage and metering data. Risk and operations teams need to investigate unusual activity. Product teams want to bring analytics closer to customers. 

    ClickHouse gives teams a high-performance foundation for querying large volumes of fast-moving data. 

    QuaerisAI adds the governed question layer on top. 

    With the ClickHouse integration, business users can ask questions in plain English and receive answers that stay connected to certified definitions, source data, and governance controls. The goal is to make real-time data easier to access, explain, and trust across the business. 

    For many organizations, the challenge is not that the data does not exist. The challenge is that access to that data often depends on SQL, dashboards, or data team support. 

    A marketer may want to know which campaigns underperformed this week. A finance user may need to review usage data behind billing. A risk team may want to investigate unusual patterns. An executive may need a current answer for a board discussion. 

    These questions should not always require a new dashboard or a manual reporting request. 

    QuaerisAI helps close that gap by translating plain-English questions into governed queries that run against ClickHouse. Answers are mapped through QuaerisAI’s semantic layer, so teams can work from consistent definitions instead of recreating metric logic for every request. 

    That governance layer matters. 

    Natural-language analytics can make data easier to access, but enterprise teams also need control over how answers are produced. Metrics need to be defined consistently. Answers need to remain traceable to source. Business users need confidence that the number they are using has the right context behind it. 

    The QuaerisAI and ClickHouse integration is designed for teams that need both speed and trust. 

    ClickHouse supports the real-time analytics layer for high-volume data. QuaerisAI helps business users ask questions, understand answers, and trace results back to certified definitions and source data. 

    This combination can support use cases across real-time marketing analytics, usage-based pricing and metering, anomaly investigation, embedded customer-facing analytics, and executive reporting. 

    For ClickHouse customers, QuaerisAI expands the way real-time data can be used across the business. More teams can ask questions directly. Data teams can reduce repetitive reporting requests. Business users can move from raw event data to governed answers with less friction. 

    Real-time analytics becomes more useful when it is accessible to the teams making decisions every day. 

    With QuaerisAI on top of ClickHouse, fast-moving data can become trusted business answers. 

  • How to choose new age AI BI (and what to actually evaluate)

    How to choose new age AI BI (and what to actually evaluate)

    Every AI BI vendor’s homepage says roughly the same four things. Ask questions in plain English. Get instant answers. No more waiting on analysts. Works with any data source. Read ten of these homepages back to back and they start to blur into one page with a different logo at the top.

    None of that tells you which one will actually hold up once real business users start asking it real questions. The differences that matter are almost never visible in a demo. They show up three months in, when someone asks a question the demo never covered, or when two people ask the same question and get two different answers, or when someone in compliance asks how a specific number was produced and nobody can say for certain.

    Here is what actually separates these tools, past the homepage.

    Old BI evaluation criteria don’t fully apply anymore

    Traditional BI evaluations focused on things like dashboard build speed, visualization variety, and how many connectors a tool shipped with. Those questions still matter, but they’re no longer sufficient. A tool that answers questions conversationally introduces a new category of risk that dashboard-based BI never had: the tool can now generate a wrong answer that looks exactly as confident as a right one.

    A static dashboard can be misread, but it can’t lie to you in a full sentence. A conversational AI layer can. That changes what “evaluation” needs to cover.

    Does it answer from certified definitions, or improvise them?

    This is the single most important question, and it’s the one most demos are built to avoid. Ask the vendor directly: when someone asks about a metric that has no formal definition yet, what happens? A tool built around a governed semantic layer will say it can’t answer until that metric is defined, or it will show you exactly which definition it used and let you inspect it. A tool built primarily on a language model’s general reasoning will often generate something plausible anyway, calculated on the fly from whatever it can infer, without telling you that’s what happened.

    The second version demos beautifully. It also means two people can ask the identical question a week apart and get two different numbers, because the model quietly re-derived the logic each time.

    Can you see the query behind the answer?

    Ask for the actual SQL, or whatever query the system generated to produce the answer. Not a summary of the logic, the literal query. If a vendor can’t show you that, or treats it as a power-user feature buried three menus deep, that’s worth noting. The ability to inspect the underlying query is what turns “trust the AI” into “verify the AI,” and only one of those scales past the first few months of skepticism from an audit or finance team.

    Does data have to move to get an answer?

    Some AI BI tools require pulling your data into their own environment before they can answer anything, a separate copy, a separate pipeline, a new place for that data to live and go stale. Others query your existing warehouse directly, in place, read-only. The difference matters more than it sounds like in a demo, because every extra copy of your data is a new thing to secure, govern, and eventually reconcile against the original.

    Ask specifically whether the tool executes against your warehouse or requires ingestion into its own store first. The answer changes your total security surface, not just your architecture diagram.

    What happens when it doesn’t know?

    Every AI BI tool will eventually be asked something it can’t answer well, a metric that doesn’t exist, a question outside its scope, ambiguous phrasing. What it does at that moment tells you more than almost anything else in the evaluation. Some tools guess anyway and present the guess with full confidence. Others say plainly that the definition doesn’t exist yet, or that the question needs to be narrowed. Push on this specifically during any trial. Ask something you know the tool cannot answer correctly and watch what it does instead of admitting the gap.

    Who can ask what?

    Self-service only works if access is actually scoped. Ask how permissions are enforced: is access checked at the moment a query runs, or is it enforced by filtering results after the fact, or worse, left to the model to respect on its own. Query-time enforcement means a user literally cannot retrieve data outside their permission, regardless of how the question is phrased. Post-hoc filtering or model-level trust means the boundary is softer than it looks, and softer boundaries tend to fail exactly when someone gets creative with a prompt.

    Can you choose your own model, or are you locked to one?

    The underlying language model powering these tools changes fast, and today’s best option won’t stay the best option indefinitely. A tool tightly coupled to one specific model ties your governance and your model choice together permanently. A tool that separates the semantic layer from the model itself lets you change models as the market moves without rebuilding your certified definitions from scratch.

    The red flags that sound good in a demo

    A few things worth specific suspicion, because they tend to demo well and hold up poorly: a tool that never says “I don’t know,” a tool where every answer looks equally confident regardless of how well-supported it actually is, a tool that can’t show you its own reasoning path when asked directly, and a tool where the sales team can’t clearly explain what happens to a question outside its trained scope.

    None of these are dealbreakers on their own. All of them together usually mean the tool was built to impress in a thirty-minute demo, not to survive daily use by people who will eventually ask it something it wasn’t ready for.

    What actually matters

    The vendors selling AI BI are not lying when they say it’s faster than a dashboard. It usually is. The real evaluation question isn’t speed, every tool in this category is fast now. It’s whether the speed is coming from a governed, certified answer or from a model’s best guess dressed up to look certain. One of those scales safely as more people start relying on it. The other one accumulates risk quietly, one plausible-sounding answer at a time, until someone finally asks where a number came from and nobody can say.

  • The shadow AI tax: what ungoverned AI use is quietly costing your data team

    The shadow AI tax: what ungoverned AI use is quietly costing your data team

    A data analyst at a mid-size logistics company spent forty minutes on a Tuesday afternoon reconstructing a churn number from scratch. Not because the number didn’t exist anywhere. Because someone in sales had already pulled a number from a public chatbot, brought it into a leadership meeting that morning, and now the analyst had to prove it right or wrong before anyone would trust either version.

    The number turned out to be close, but built on a customer segment definition that didn’t match what finance used. Nobody in that meeting knew that. They just knew there were now two churn numbers in the building, and someone had to lose the argument about which one was real.

    This is the actual cost of shadow AI, and it rarely shows up in the way risk conversations describe it.

    The tax isn’t where most people are looking

    Most discussion of ungoverned AI use frames it as a security problem: sensitive data pasted into a public chatbot, sitting somewhere outside the company’s control. That risk is real. It is also not where the recurring cost lives.

    The recurring cost lives downstream, on the data team, every time an ungoverned answer reenters the business as if it were a governed one. Someone asked a chatbot a question, got a plausible number, and used it. The data team didn’t produce that number and usually doesn’t find out it exists until it conflicts with something they did produce. At that point, the work isn’t optional. Someone has to figure out where the number came from, what it means, and why it doesn’t match, before the disagreement can even be resolved, let alone closed.

    That work is a tax. It gets paid every time it happens, and almost nobody is tracking the total.

    What the tax actually looks like

    The verification tax. Every ungoverned number that reaches a meeting eventually needs someone to check it. That checking work rarely gets scheduled. It gets absorbed, usually by whoever is already stretched thin, at the exact moment a decision is waiting on the answer.

    The reconciliation tax. Two numbers in a room means someone has to explain the gap. That explanation almost never has a quick answer, because the gap is usually a definitional mismatch: a different date range, a different customer segment, a different join that nobody wrote down. Resolving it means reverse engineering a query nobody kept a record of.

    The credibility tax. Once a wrong number has been in a meeting, the data team’s numbers get a second look too, even the correct ones. Trust doesn’t erode evenly. One bad number from an ungoverned source can quietly increase scrutiny on everything the data team produces afterward, whether that scrutiny is warranted or not.

    The opportunity tax. All of that verification and reconciliation time comes from somewhere. It comes from the roadmap, the actual analysis work the data team was supposed to be doing instead of playing defense against an answer they didn’t produce.

    None of these show up on a dashboard. They show up as a data team that seems perpetually behind, without anyone being able to point to exactly why.

    Banning the tool doesn’t remove the tax

    The instinctive response to this is to block public AI tools at the network level and call the problem solved. It rarely works, and when it does work, it usually just moves the cost somewhere less visible. The underlying need, a fast answer to a specific business question, does not go away because the tool got blocked. It moves to a personal device, a different account, a colleague who still has access. The tax stays the same. The visibility into it gets worse.

    Blocking access without offering a governed alternative treats the symptom and leaves the actual cause in place: business users have a real question and no fast, trustworthy way to ask it.

    What actually removes the tax

    The only way to remove the verification and reconciliation tax is to remove the reason it exists: a governed answer has to be at least as fast as an ungoverned one, or the ungoverned path stays attractive no matter what the policy says.

    That means conversational access to data that resolves through certified definitions instead of a model’s best guess. When gross margin means the same thing everywhere it’s asked, and the answer comes with a citation back to the source table and the definition version behind it, there is nothing left to reconcile. The number that shows up in the meeting is the number the data team would have produced anyway, because it came from the same governed pipeline.

    It also means every question leaves a prompt-level record: who asked, what was resolved, what ran, what came back. When a number is challenged, the answer to “where did this come from” is a lookup, not an investigation.

    This is not a security control bolted onto an existing BI stack. It is what removes the actual incentive for the shadow path to exist in the first place, because the sanctioned path stops being slower.

    The real question to ask

    The shadow AI tax rarely gets calculated directly, because it is spread across dozens of small interruptions rather than one visible incident. A more useful exercise than trying to measure it after the fact is asking the data team a simpler question: how many hours this month went toward verifying, reconciling, or explaining a number that didn’t originate with them?

    Whatever that number turns out to be, it is not a cost the business decided to pay. It is a cost that accumulated because the sanctioned path was slower than the alternative. Fixing that gap is what actually stops the tax from being collected again next month.

  • How to tell if your organization already has a shadow AI problem

    How to tell if your organization already has a shadow AI problem

    A wrong number rarely gets caught the first time it’s said out loud in a meeting. It gets caught the third time, once it has already shaped a decision or two, when someone finally asks where it came from.

    That delay is the actual challenge with shadow AI. It doesn’t announce itself. There’s no login screen, no request ticket, no line item anywhere that says “business question answered outside governed systems.” The evidence is scattered across normal-looking behavior that only reads as a pattern once someone is looking for it.

    Here’s what to actually look for, and what it usually means when you find it.

    Analysts talk about double-checking more than they used to

    Listen for a specific phrase: “let me just double-check that.” If it’s coming up more often, especially attached to numbers the analyst didn’t personally produce, that’s usually a sign someone upstream got an answer from somewhere other than the governed system and brought it into a conversation as if it were settled.

    The double-checking itself isn’t the problem. It’s a reasonable response to uncertainty. The problem is what created the uncertainty in the first place: a number entered circulation without going through anything the data team controls.

    A number shows up that nobody on the data team recognizes

    This is usually the first hard signal, and it typically arrives sideways. Someone references a figure in a meeting, a data team member hears it, and has a moment of “wait, where did that come from?” If that moment is happening even occasionally, it’s worth treating as a signal rather than a one-off.

    The specific tell is not that the number is wrong. Sometimes it’s approximately right. The tell is that nobody can trace it back to a query, a report, or a person who built it deliberately.

    People describe getting answers “faster” from somewhere else

    If you hear language like “I just asked it directly” or “it was quicker to check myself,” pay attention to what “it” refers to. Often this is completely legitimate, someone found a faster path through an approved tool. Sometimes it isn’t, and the faster path is a public AI assistant that has no connection to certified definitions, no access controls, and no record of what was asked or answered.

    The distinguishing question is simple: can the data team see what was asked and what came back? If the honest answer is no, the speed came from somewhere ungoverned.

    Reconciliation requests are increasing

    A rising number of “why doesn’t this match” questions is one of the more measurable signals available, because it usually leaves a trail in tickets, Slack threads, or email. If reconciliation requests are trending up without a clear cause like a new data source or a metric redefinition, ungoverned answers entering circulation is a reasonable hypothesis to test.

    The pattern to watch for specifically is reconciliation requests where the second number has no clear origin. A mismatch between two known systems is a data quality issue. A mismatch where one side traces to nothing is usually shadow AI.

    Nobody can say with confidence where a specific number came from

    This is the clearest version of the problem, and also the hardest one to notice, because the absence of an answer doesn’t feel like an event. Try it as a direct exercise: pick a number that appeared in a recent leadership deck and ask whoever presented it to trace its exact origin, the source table, the definition used, the person or system that produced it.

    If that trace takes more than a few minutes, or comes back with genuine uncertainty, that’s not a one-time gap. It’s evidence of how numbers are currently entering the organization, and it will keep happening the same way until something changes about the path itself.

    The data team has started asking “did this come from us?” first

    This is a late-stage signal, and it means the organization has already been through enough incidents that the data team has adapted its default posture. When “did this come from us” becomes a routine first question rather than an unusual one, the shadow AI problem has been present long enough to change behavior, not just create occasional friction.

    What to do with this list

    None of these signals alone proves anything. A single moment of double-checking, a single unfamiliar number, a single fast answer, all of those happen in healthy organizations too. What matters is whether several of these are showing up together and trending in the same direction.

    If they are, the next step is not a policy memo banning specific tools. That tends to move the behavior somewhere less visible rather than removing it, since the underlying need for a fast answer to a business question doesn’t disappear because the tool got blocked.

    The more durable fix is making the governed path at least as fast as the ungoverned one: conversational access to data that resolves through certified definitions, with every question and answer logged automatically. When the sanctioned path is no slower than the alternative, there’s no longer a reason for the alternative to exist quietly in the background.

  • Why QuaerisAI’s DuckDB integration changes how fast a question gets answered

    Why QuaerisAI’s DuckDB integration changes how fast a question gets answered

     

    Vertical, columnar databases like DuckDB have quietly become one of the fastest ways to run analytical queries. That speed is real, and it’s exactly why QuaerisAI has built a DuckDB integration into its architecture. But a fast database only matters if something on top of it can actually turn that speed into an answer.

    This is where organizations lose the benefit before they ever get to use it. Plugging a fast engine like DuckDB into an old-generation BI tool such as Tableau or Power BI, or into an older architecture like Sisense, does not make those tools faster in the way that matters to a business user. Those platforms are dashboard-first: reports get modeled and published in advance, so a new question still waits on a build cycle, no matter how fast the database underneath can respond. The bottleneck was never the storage engine. It was everything sitting between the data and the person asking the question.

    That gap is exactly what a consumption layer is supposed to close, and it’s why QuaerisAI is built as one rather than as another dashboard tool. A vertical database like DuckDB is fast at the compute layer. QuaerisAI is fast at the layer where a person actually asks something, turning a plain-English question into a governed query, grounded in certified metrics, with source citations and full lineage, without waiting on a new report to be built. Pairing the two means the speed DuckDB delivers underneath doesn’t get absorbed by a slow interface on top of it.

    The practical result is a shorter distance between asking a question and trusting the answer. QuaerisAI’s DuckDB integration is built to carry that speed all the way through to the business user, with role-based access enforced at the moment of the query and an audit trail on every answer. 

    Talk to us to see how a performant consumption layer changes what a fast database can actually do for your team.