Helping enterprises leverage AI for a data-driven edge

The organizations getting the most from AI are not the ones with better models. They are the ones with better data foundations.

It is worth being honest about how far the model has slid down the list of things that matter. The latest language and embedding models are available to everyone at roughly the same quality, and standing up an impressive demo takes days. The demo is easy. The system behind it is not. What separates a proof of concept from something an enterprise can trust is almost never the model. It is whether the data underneath it can be used again and again, safely and consistently.

Across more than 500 projects with over 100 enterprise clients since 2016, the same warning signs come up again and again. They fall into three groups: whether the data itself can be trusted, whether the architecture can serve it, and whether AI can work safely on your knowledge. Here are the ten that matter most, and what to actually do about each.

Trust in the numbers comes first

Before architecture, before models, a simpler question. Do people in your organization trust the numbers they already have? Often the answer is no, and AI makes that gap obvious fast.

‍

1. The same KPI means different things to different teams

Ask three departments for last month’s revenue and you may get three figures. Finance counts invoiced sales net of VAT, sales counts booked orders, a dashboard reports a third number. For years this was survivable, because a person in the room knew which version to trust. An AI assistant has no such instinct. It quotes whichever definition it was pointed at. The first time a leader sees two contradictory answers, trust in the whole system is gone.

The fix is less technical than it sounds. Agree, once, on a single definition for each critical metric. Give it an owner. Treat any change as a deliberate, communicated decision, not a private edit. A shared language for your top KPIs lets AI settle an argument instead of starting one.

What we see in practice
Organizations often believe they have a data quality problem.
In reality, they have a consistency problem.
The data exists. The business simply disagrees on what it means.

‍

2. Data is produced as reports, not as products

In many companies, data still arrives the old way. Someone asks a question, an analyst pulls an export, cleans it by hand, sends it on. The next question starts over. No single report is wrong, but none is reusable, and two analysts can answer the same question with two different numbers and no one accountable for the gap.

Treating data as a product changes how the organization relates to it. A critical dataset stops being prepared on demand and becomes a service: a named owner, defined quality and freshness, a clear definition, a plan to improve it. That is not process for its own sake. It is how an AI system relies on the same data tomorrow that it used today.

‍

3. When data breaks, nobody finds out in time

Most data does not fail loudly. A feed lands late, a load runs half-empty, a field changes shape, and the dashboard shows a number as if nothing happened. In a reporting world, someone eventually catches it. In an AI world, the broken data is already inside an answer to a customer. Reporting forgives a late feed. AI does not.

The instinct is to monitor everything. Resist it. Start with the datasets that feed your first AI use cases, and watch the three failures that actually happen: data that arrives late, volumes that swing far from normal, structures that change without warning. Give each alert an owner and a simple response. Monitoring everything creates noise. Monitoring what your AI depends on creates trust. It is the daily reality behind why clean data matters.

‍

Even with trustworthy data, the architecture gets in the way

Plenty of organizations fix their definitions and still stall. AI brings a workload their systems were never built for. BI explains what happened. AI increasingly decides what happens next, and it needs to know what is happening right now. That single shift exposes architectural limits most companies have never had to solve.

What we see in practice
Companies rarely rebuild their architecture because of AI.
More often, AI just exposes bottlenecks that were always there.
The architecture was never wrong. It was built for a different question.

‍

4. Everything still runs through one monolithic warehouse

A warehouse is excellent for yesterday. AI increasingly cares about now. Built for batch processing, historical aggregates, and SQL analytics, a single warehouse strains the moment you ask it for low-latency, operational queries: storage priced for performance even on cold data, an awkward fit for events and unstructured content, and a change process so interconnected that one adjustment ripples through dozens of reports. Everything runs at one speed, and that speed is rarely now.

The answer is not another migration project. Different workloads have different requirements, and historical analytics should not compete with operational AI for the same architecture. Data has a temperature. Cold and hot history, analytics, and model training belong in a lakehouse; warm, current-state data belongs in a faster operational layer built for it. Separate the two and you stop paying to scale one expensive system for workloads that never belonged together.

‍

5. AI has to reach into your core systems to know what is happening now

Enterprise AI earns its keep the moment it answers operational questions. A warehouse manager asks which orders are blocked by missing inventory. A claims adjuster asks which cases need manual review today. Finance asks whether an invoice has already been paid.

That is the moment many organizations discover their architecture was never designed to hand out operational data safely. The only way to answer is to query the ERP, the CRM, or SAP directly, which is slow, costly, and risky enough that most IT teams refuse. Rightly.

This is what an operational data store, an ODS, is for. It sits between the core systems and everything that consumes them, fed through your integration layer, holding only the current state that matters. It answers live questions fast, takes load off the systems the business runs on, and keeps a clean line between warm operational data and colder history in the lakehouse. Do not build it for everything. Pick three to five high-value questions and start there.

What we see in practice
The blocker is rarely technical.
No one has ever had to expose operational data outside the core system, so there is no safe path to do it.
The ODS is an organizational decision as much as an architectural one.

‍

6. Real-time turns out to mean nothing in particular

Almost every enterprise says it has real-time data. Press a little, and the term dissolves. To one team it means a copy of the core systems within minutes; to another, an hourly stream aggregation; to a third, an event feed with a seconds-level guarantee. Often the real-time layer exists on paper, but events flow with no clear path, no validation, and no one watching whether they arrive. For AI the effect is small but expensive. The system reacts late, and a technically correct answer can already be wrong by the time it lands.

Start with a definition, not a technology. Once each use case has an agreed meaning of real-time, the minimum is unglamorous and reliable: a clear flow from source to consumer, basic validation, monitoring that confirms data arrived on time and in full, and an owner who reacts when it does not. You know it works when a delay is caught before it reaches a customer, not after.

‍

7. The API was built for one app, and it shows

An API is often an accident of history, a by-product of the first web or mobile app that needed one. It works until you connect something new: an AI agent, a partner, another team. Then it shows its age. Brittle, unversioned, every change breaks another consumer, and onboarding anything new becomes a project. That friction is the real line between a pilot and scaling.

The shift is simple: stop treating the API as plumbing for one application and start treating it as a product. Stable. Versioned. Governed. Built around business capabilities rather than individual channels. Give AI a stable interface to current, well-defined data, and the workarounds and manual glue that sink so many AI projects stop appearing.

What we see in practice
AI projects rarely fail because an API is missing.
They fail because every API was built around a different application.
The fix is rarely more APIs. It is fewer, better ones.

‍

Once AI touches your documents, discipline matters more than models

Structured data is only half the story. The most valuable enterprise AI increasingly works over documents: policies, contracts, procedures, product knowledge. Here the gap between a demo and a dependable system is almost entirely about discipline.

‍

8. AI answers from your documents, but no one can say which one

An assistant gives a confident, fluent answer about an HR policy or a contract clause. It sounds right. But nobody can tell which document it used, or whether that document is still valid. In our experience the real risk is almost never the model. It is the underlying content: outdated files, no clear source of truth, no owner. An AI system will give a correct answer from the wrong document, and trust drains fast when it does.

Safe AI over company knowledge comes down to a few principles: draw only from approved sources, give each source an owner, respect the reader’s access rights, keep to the current version, and cite the passages behind every answer. Technically, that is retrieval-grounded generation: approved documents live in a document store with a vector index, the system retrieves the most relevant passages, and every answer carries its evidence. It is the same discipline as good enterprise search. It turns a plausible answer into a defensible one.

What we see in practice
The hardest part of document AI is rarely the retrieval.
It is discovering how much of the source of truth is outdated, duplicated, or owned by no one.
AI does not create that problem. It just makes it impossible to ignore.

‍

9. Nobody actually knows if the AI’s answers are any good

Ask most teams how their AI is performing and you get an impression, not a measurement. That is how a system slips: the off-topic answer, the one with no source, the one that leaks something sensitive, unnoticed until a customer or auditor notices first. It seems fine is not a control.

Measuring quality is simpler than it looks. Assemble twenty to fifty real questions from actual use, and score each answer on three things: is it relevant, is it grounded in a source, is it within the user’s permissions. Re-run the set whenever you change the sources or the process. Watch a few production signals too: how often the AI escalates to a human, how often it finds no answer, how many answers carry citations. The goal is not a perfect score. It is a decision you can defend, scale this, adjust this, or stop this, made on evidence rather than instinct.

‍

10. The AI belongs to everyone, and therefore to no one

The last sign decides whether the others get solved. When an AI use case has no owner and every scenario gets the same reflex, you land in one of two failure modes: too cautious to ship, or too casual to be safe. The same assistant can be harmless summarizing an internal FAQ and real trouble drafting something a customer acts on. Most organizations treat both the same.

Governance, done well, is not bureaucracy. It is what lets AI scale without fear. The practical version is modest: give every use case an owner, classify it by risk, match the controls to the risk. Low-risk uses run automatically with a record of what happened. Higher-risk ones earn a human check, restricted sources, and an escalation path. Under that sit five basics: an owner, approved sources, access rules, an audit trail, an incident process. There is now a regulatory reason to have them, with EU AI Act penalties reaching up to 7 percent of global annual turnover. The point is not to slow AI down. It is to make it defensible enough to speed up.

When people discuss security around vibe coding tools today, it often sounds as if this were a completely new problem. In reality, it is not new at all. Over the past few years, we have simply become used to running third-party code, third-party dependencies, and increasingly also third-party shell commands directly on our local machines — the same machines where we keep SSH keys, .env files, logged-in browsers, cloud access, and often even production credentials.

AI tooling did not create this problem. It only amplified it and made it much more visible.

On macOS, I think this is particularly obvious. Many people do not want to develop in Docker because the developer experience quickly deteriorates and containers on Mac still come with overhead. So the real default remains the same: everything runs on the host machine, and we hope nothing happens.

This works exactly until it does not.

LiteLLM only reminded us of an old problem

On March 24, 2026, compromised versions of litellm 1.82.7 and 1.82.8 appeared on PyPI. This was not an exotic exploit. A simple pip install was enough to introduce a malicious .pth file into the environment, which then executed when Python started.

It then reached for the kind of things that are typically easy to find on a developer machine:

• SSH keys
• .env files
• cloud credentials
• other secrets and configuration files

It then sent them to a remote server.

The important thing about this incident is how banal the attack path was. It did not need to break Python, bypass the kernel, or convince someone to run anything unusual. It only needed a developer to do what developers do every day: install a dependency.

Paradoxically, the whole thing may have been discovered faster because the malware was not written very well and triggered a fork bomb on some machines. If it had kept a lower profile and only exfiltrated data silently, it is quite possible that it would have remained unnoticed for longer.

In my view, a large share of regular developers would have been vulnerable to this — not only people experimenting with vibe coding. The reason is simple: very few people have their local Python environment truly isolated.

The JavaScript world was not doing much better either

This is not only a Python story.

On March 30 and 31, 2026, axios — one of the most widely used libraries in the JavaScript world — was also compromised. The attacker took over a maintainer account on npm and published malicious versions axios@1.14.1 and axios@0.30.4.

What is interesting is that the malicious payload was not directly inside axios itself. Those versions only added a new transitive dependency, plain-crypto-js, which executed through a postinstall hook. In other words, even here, an ordinary install was enough to turn the dependency chain into an execution chain.

That is exactly why I find it dangerous to pretend that supply-chain risk only applies to dubious packages at the edge of the ecosystem. It does not. Last week, this became visible in one of the most common HTTP clients for Node.js.

exclude-newer is a reasonable default

One of the few low-cost guardrails that makes sense for almost everyone is not installing completely fresh package releases immediately.

In uv, you can use exclude-newer, which limits dependency resolution to packages published before a selected date:

‍

[tool.uv]
exclude-newer = "2026-03-24"

‍

This is not a magic defense. It only buys you time. If you keep, for example, a 14-day delay, there is a reasonable chance that a compromised release will be discovered during that time and either removed or at least flagged by the community.

The same logic applies to AI coding tools

Just as you do not want to blindly run fresh dependencies on the host machine, you also do not want to run a code generator on the host machine with full access to everything around it.

This is not an argument against Codex, Claude Code, or any other tool. It is an argument against the amount of trust we give these tools by default.

Lightweight sandboxes are a good start. Codex CLI on macOS has historically used sandbox-exec, which can significantly limit where a process is allowed to reach. In Claude Code, sandboxing can be enabled via /sandbox. In both cases, this is significantly better than a mode where the agent can see the whole disk and run shell commands without restrictions.

This has two practical advantages:

• the agent typically sees only the repository or explicitly allowed paths
• you do not need to approve every small action just to maintain at least some control surface

For regular reading, file editing, and part of shell work, this is actually a useful middle ground.

Where this model hits its limits

The problem is that a lightweight sandbox is not the same as real isolation.

As soon as the tool needs to do something slightly more practical, the edges start to show:

• package installation through uv, pip, npm, or similar tools often touches global caches
• browser tooling may not work well inside the sandbox, or may not work at all
• some MCP servers need access outside the repository boundary
• sooner or later, you run into a command that simply has to be executed outside the sandbox

And at that moment, the vibe coder is asked whether the system can leave the sandbox — and most people simply click “Yes”.

That is why I think it is important not to confuse “it has some sandbox mode” with “it is safely isolated”.

What I think makes more sense

If we want to use agents or code generators seriously, we need a real sandbox. Ideally, a separate VM or microVM for each project. On Mac, this could be something like Lima or a similar VM-based solution. Docker sandboxes follow a similar direction in principle, although on macOS they often run into performance and developer-experience issues.

But the point is not the specific product. The point is the trust boundary.

Into such an environment, you move only what the specific project actually needs:

• repository checkout
• project-scoped credentials
• local cache dedicated only to that project
• optionally a browser session or MCP servers, but again only where it makes sense

This reduces the blast radius twice.

First: if the agent runs a destructive command such as rm -rf /, it destroys at most its own sandbox.

Second: if you install a compromised dependency such as an infected litellm, it cannot exfiltrate all credentials from the entire laptop. At worst, it gets access to what you placed into that specific environment. Ideally, that means only development secrets for one project.

That is still not a pleasant incident. But it is an order of magnitude better incident.

A classifier is useful, but it is not a sandbox

Claude Code has now also added an auto mode, where another classifier runs over more sensitive actions. It evaluates the transcript and individual tool calls, especially Bash commands and other actions outside the repository, and tries to block things such as data exfiltration, credential hunting, or destructive actions outside the scope of the task.

That is a reasonable step forward. Approval fatigue is real, and manually confirming everything is not a very sustainable model.

But even here, I think it is important to keep the right expectation: a classifier is a guardrail, not isolation.

It also does not solve the supply-chain problem. If you install a malicious package inside a trusted environment, a classifier watching Bash commands will not help you against what that package does during import or interpreter startup.

What I would take from this as a practical default

My current take is simple:

• do not run completely fresh dependencies without a delay
• do not run AI coding tools directly on the host machine with full access
• when using a lightweight sandbox, do not treat it as the final solution
• for more important work, use a per-project isolated environment with a limited blast radius

All of this was true long before someone came up with the term vibe coding.

There is just much less room to avoid it now. When you give an agent shell access, filesystem access, browser access, and credentials, you are effectively giving it very strong permissions. And as the LiteLLM incident showed, a regular package manager receives similarly strong permissions the moment you allow it to install third-party code directly on your laptop without isolation.

This is not a niche security debate. It is a fairly basic engineering default that we should have had in place a long time ago.

Apple is currently working on a new container engine, which I hope will have a lot of this built in. Until then, I try to pay close attention whenever commands are executed outside the sandbox.

‍

Where are we now

Over the last few months, several important things have happened in AI and e-commerce:

• Google introduced UCP (Universal Commerce Protocol) – an open standard for agentic commerce that unifies how an AI agent talks to a merchant: catalogue, cart, shipping, payment, order.
• OpenAI and Stripe launched ACP (Agentic Commerce Protocol) – a protocol for agentic checkout in the ChatGPT ecosystem.
• At the same time, MCP (Model Context Protocol) has emerged as a general way for agents to call tools and services, and OpenAI Apps SDK as a product/distribution layer for agent apps.

In other words, the internet is starting to define standardised “rails” for how AI agents will shop. And the market is shifting from “AI recommends” to “AI actually executes the transaction”.

‍

In this article, we look at:

• what agentic commerce means in practice,
• how UCP, MCP, Apps SDK and ACP fit together,
• what these standards solve – and what they very intentionally don’t solve,
• and where custom agentic commerce makes sense – the exact type of work we do at BigHub.

‍

What Is Agentic commerce

Agentic commerce is a shopping flow where an AI agent handles part or all of the process on behalf of a person or a business – from discovery and comparison to payment.

A typical scenario:

“Find me marathon running shoes under $150 that can be delivered within two weeks.”

‍

The agent then:

1. understands the request,
2. queries multiple merchants,
3. compares parameters, reviews, prices and delivery options,
4. builds a shortlist,
5. and, once the user approves, completes the purchase – ideally without the user ever touching a traditional web checkout.

This doesn’t only apply to B2C. Similar patterns show up in:

• internal procurement,
• B2B ordering,
• recurring replenishment,
• service and returns flows.

The direction is clear, AI is moving from “help me choose” to “get it done for me”.

‍

MCP, Apps SDK, UCP and  ACP

It’s useful to see today’s stack as layers.

MCP (Model Context Protocol) is:

• a general standard for how an agent calls tools, APIs and services,
• domain-agnostic (“I can talk to CRM, pricing, catalogue, ERP, …”),
• effectively the way the agent “sees” the world – through capabilities it can invoke.

In short: MCP = how the agent reaches into your systems.

‍

OpenAI Apps SDK:

• provides UI, runtime and distribution for agents (ChatGPT Apps, user-facing interface),
• lets you quickly wrap an agent into a usable product:
  • chat, forms, actions,
  • distribution inside the ChatGPT ecosystem,
  • basic management and execution.

In short: Apps SDK = how you turn an agent into a product people actually use.

‍

UCP – Domain standard for commerce workflows

UCP (Universal Commerce Protocol) from Google and partners:

• is a domain-specific standard for commerce,
• unifies how an agent talks to a merchant about:
  • catalogue, variants, prices,
  • cart, shipping, payment, order,
  • discounts, loyalty, refunds, tracking and support,
• is designed to work across Google Search, Gemini and other AI surfaces.

In short: UCP = the concrete language and workflow of buying.

‍

‍

ACP – Agentic checkout in the ChatGPT ecosystem

ACP (Agentic Commerce Protocol) from OpenAI/Stripe:

• targets a similar domain from the ChatGPT side,
• focuses strongly on checkout, payments and orders,
• powers features like Instant Checkout in ChatGPT.

From a merchant’s point of view, UCP and ACP are competing commerce standards (no one wants three different protocols in their stack).

From an architecture point of view, they can coexist as different dialects an agent uses depending on the channel (ChatGPT vs. Google / Gemini).

‍

What these standards do – and what they don’t

The common pattern is important. UCP and ACP do not make agents “smart”. They just give them a consistent language.

These standards typically cover:

• how the agent formally communicates with the merchant and checkout,
• how offers and orders are structured,
• how payment and authorisation are handled securely,
• how a purchase can flow across different AI channels.

‍

They do not (and cannot) solve:

• the quality and structure of your product catalogue, attributes and availability,
• integration into ERP, WMS/OMS, CRM, loyalty, pricing engine, campaign tooling,
• your business logic – margin vs. SLA vs. customer experience vs. revenue,
• governance, risk, approvals – who is allowed to order what, when a human must step in, how decisions are audited.

‍

Practically, this means:

• you can be formally “UCP/ACP-ready”,
• and still deliver a poor agent experience if:
  • data is inconsistent,
  • delivery promises can’t be kept,
  • pricing and promo logic breaks in a multi-channel world,
  • the agent has no access to real-time states and internal rules.

‍

The standard is a necessary technical minimum, not a finished solution.

‍

How we approach Agentic Commerce at BigHub

At BigHub, we see UCP, MCP, ACP and Apps SDK as infrastructure building blocks. On real projects, we focus on what creates actual competitive advantage on top of them.

‍

We build ML-powered commerce agents that can:

• optimise dynamic offers and pricing (bundles, alternatives, smart trade-offs based on margin, SLA and priorities),

• deliver personalised search and shortlists (customer context, preferences, budget, interaction history),

• handle argumentation and objections (why this option, what are the alternatives, explain the trade-offs),

• and only then smoothly push the checkout over the finish line.

‍

On top of that, we add an integration layer via MCP (capabilities + connections to core systems). For UI and distribution, we often use OpenAI Apps SDK when we need to get an agent in front of real users quickly. Where it makes sense, we plug into standards like UCP/ACP instead of writing bespoke integrations for every single channel.

‍

Where custom Agentic Commerce makes the difference

Standards (UCP/ACP/MCP) are extremely valuable where:

• you don’t want to invent your own protocol for connecting to AI channels,
• you need interoperability (ChatGPT, Google/Gemini, others),
• you want to reduce integration overhead for merchants.

A custom approach adds the most value in these areas:

‍

1) Connecting the agent to core systems

• ERP, WMS/OMS, CRM, loyalty, pricing, returns, contact centre…
• the agent must live in your real operational architecture, not a demo sandbox.

Typically you need a dedicated integration and orchestration layer that:

• speaks UCP/ACP/MCP “upwards”,
• speaks your specific systems and APIs “downwards”.

‍

2) Domain logic and business Rules

This is where competitive advantage is created:

• when the agent can execute autonomously vs. when it should only recommend,
• how it balances margin, SLA, availability, customer experience and revenue,
• how it works with promotions, loyalty, cross-sell / up-sell scenarios.

This is not a protocol question. It’s about concrete rules on top of your data and KPIs.

‍

3) Multi-channel and the mix of B2C / B2B / Internal agents

Real-world commerce looks like this:

• B2C webshop,
• B2B ordering portal,
• internal purchasing agent,
• in-store sales assistant,
• customer service agent.

A custom framework lets you:

• share logic across roles and channels,
• respect permissions and limits,
• support flows like “AI starts in chat, finishes in the store”.

‍

4) European context: Regulation, security, Data residency

For European companies, several constraints matter:

• regulation (EU AI Act, GDPR, sector-specific rules),
• internal security posture, audits, risk controls,
• where data and models actually run (US vs. EU),
• how explainable and auditable agent decisions are.

Standards are global, but architecture and governance have to be local and tailored.

‍

What retailers and enterprises should take away from UCP (and other similar protocols)

If you’re thinking about agentic commerce, it’s worth asking a few practical questions:

• Are we “agent-ready” not only at the protocol level, but also in terms of data and processes?
• In which use cases do we actually want the agent to execute the transaction – and where should it stay at the recommendation level?
• How will agentic commerce fit into our existing systems, pricing, campaigns and SLAs?
• Who owns agent initiatives internally (KPI, P&L) and how will we measure success?
• Which parts make sense to solve via standards (UCP/ACP/MCP) and where do we already need a custom agent framework?