Enterprise AI Adoption Patterns and Production Agent Deployment at Scale

mongodb · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise agent deployment at scale

MongoDB's CEO describes how frontier labs, AI-native companies, and large enterprises use data infrastructure differently for agents, and why regulated customer-facing deployments require real-time context, human takeover, auditability, model optionality, and mature harness/observability layers.

Constraints:

Customer-facing agents in regulated industries need auditability, replay, governance, and human takeover.
Large enterprises face uncertainty about agent stacks, frontier models, sub-agent models, and hyperscaler lock-in.
Agents need real-time context and memory that may not fit warehouse-style lag.
More agents increase token spend and cost.
Production readiness depends on harness, observability, data layer, and evaluation maturity, not only the LLM.

Architecture

The transcript frames production agents as a 'system of intelligence' built from a real-time data/context layer, memory, harness/orchestration layer, model or sub-agent choices, observability, audit/replay, and human handoff. MongoDB positions the data layer and agent harness as critical infrastructure for customer-facing agents that must process claims, add dependents, or make fast decisions.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  enterprise-data-layer["Enterprise data layer"] --> context-and-memory-layer["Context and memory layer"]
  context-and-memory-layer --> agent-harness["Agent harness"]
  agent-harness --> llm-and-sub-agent-layer["LLM and sub-agent layer"]
  llm-and-sub-agent-layer --> business-workflow-actions["Business workflow actions"]
  agent-harness --> observability-and-replay["Observability and replay"]
  business-workflow-actions --> human-handoff["Human handoff"]
  observability-and-replay --> human-handoff["Human handoff"]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Enterprise data layer`	Stores policies, claims, customer data, training data, inference conversations, and long-term memory.	`Context and memory layer`
`Context and memory layer`	Feeds customer-facing agents real-time context for decisions.	`Agent harness`
`Agent harness`	Coordinates agents, sub-agents, models, tools, and production workflow logic.	`LLM and sub-agent layer`, `Observability and replay`
`LLM and sub-agent layer`	Uses frontier models, multiple models, or small language models for different agent tasks.	`Business workflow actions`
`Business workflow actions`	Customer-facing operations such as processing claims, adding dependents, or changing policies.	`Human handoff`
`Observability and replay`	Supports auditing, replaying agent behavior, and diagnosing failures.	`Human handoff`
`Human handoff`	Allows humans to take over regulated or failed agent workflows.	—

Data flow

Enterprise customer data and policies feed a real-time context/memory layer; an agent harness orchestrates LLMs, sub-agents, and business actions; observability and replay capture what happened; human-in-the-loop paths handle regulated decisions or failures.

“With agents, agents are a system of intelligence. Now, anytime you want to create a true agent that is customer-facing, your data layer and harness become super critical”transcript, stated

“It needs to have the right context and memory so that the agent can make real-time decisions. And it needs to be fed in real time.”transcript, stated

Why this architecture

MongoDB argues that customer-facing agents require real-time context, memory, audit, and harness infrastructure because large enterprises cannot rely on LLM capability alone for regulated, high-scale workflows.

“Can you replay what happened if the agent gave an insurance rate? Did the agent discriminate? Did the agent not discriminate?”transcript, stated

“I absolutely do not believe these are the kinds of things you can build on top of a data warehouse.”transcript, stated

Models used: LLMs · SLMs · Frontier models · LangChain · LangGraph

Scale

The speaker says he talks to at least 10 customers each week.
“I'm obsessed with speaking to at least 10 customers a week.”transcript, stated
ElevenLabs is described as having 40 million production agents on MongoDB.
“And once they moved to MongoDB, they now have 40 million production agents built on MongoDB.”transcript, stated
ElevenLabs is described as having reached $500 million ARR.
“An AI-native company — and they hit $500 million ARR.”transcript, stated
The regulated customer-facing example involves 50 million plus customers.
“If it's truly customer-facing, we're talking 50 million plus customers.”transcript, stated
MongoDB is described as being in more than 75% of the Fortune 100.
“MongoDB is in 75-plus percent of the Fortune 100.”transcript, stated
The speaker contrasts real-time agent context with data warehouses designed around 15- or 30-minute lag.
“Because data warehouses were always designed with a 15-minute or 30-minute lag, for asking business questions.”transcript, stated

Alternatives considered (roads not taken)

Use a hyperscaler's first-party database for AI-native agent scale.

Rejected because: The speaker says ElevenLabs moved after the first-party database did not scale.

“they made the mistake of using the first-party database from that hyperscaler. It didn't scale.”transcript, stated

Commit early to a single frontier model or hyperscaler stack.

Rejected because: Enterprises are still experimenting and want optionality while the stack changes rapidly.

“Should we commit to a particular frontier model? Or for sub-agents, should I use different models?”transcript, stated

Deploy customer-facing regulated agents without human takeover.

Rejected because: Insurance and banking workflows need escalation when the agent crashes or makes sensitive decisions.

“if the agent crashed, what does that mean? How does a human take over from there?”transcript, stated

Build real-time agents directly on a data warehouse.

Rejected because: Warehouse latency is designed for business questions, not fast customer-facing decisions.

“data warehouses were always designed with a 15-minute or 30-minute lag, for asking business questions.”transcript, stated

Patterns

`agent-memory` (memory)

The architecture depends on a context-plus-memory layer that gives agents real-time information for decisions.

“It needs to have the right context and memory so that the agent can make real-time decisions. And it needs to be fed in real time.”transcript, stated

`human-in-the-loop-gate` (governance)

Regulated customer-facing agents retain human handoff for claims and failures.

“if we are going to approve somebody's insurance claim or process a claim, we do want a human in the loop.”transcript, stated

`observability-tracing` (operations)

The enterprise architecture needs replay and auditability for regulated agent decisions.

“Can you replay what happened if the agent gave an insurance rate? Did the agent discriminate? Did the agent not discriminate?”transcript, stated

`model-routing` (model-ops)

Enterprises consider frontier models for some tasks and different models for sub-agents.

“Should we commit to a particular frontier model? Or for sub-agents, should I use different models?”transcript, stated

Tradeoffs

Use a real-time context and memory layer.

Chose Agent-specific context/memory infrastructure. over Warehouse-backed delayed analytics data..

Rationale: Customer-facing agents need fast decisions, while warehouses are designed for delayed business questions.

“if your agent is customer-facing at airlines, banks — you need to make decisions fast.”transcript, stated

Keep humans in regulated loops.

Chose Human takeover and review for claims and failures. over Fully autonomous claim processing..

Rationale: The customer example requires confidence before approving or processing insurance claims.

“we want to make sure our evaluation before we even do that is rock solid.”transcript, stated

Maintain model and stack optionality.

Chose Experimentation across orchestration stacks, frontier models, and sub-agent models. over Early lock-in to one hyperscaler or frontier model..

Rationale: The enterprise stack is still changing, and customers do not know what to pick.

“They're experimenting, but things are moving so fast they don't know what to pick.”transcript, stated

Gotchas (what bit them)

Agent-stack choice is unstable for large enterprises.

Root cause: The ecosystem changes quickly across hyperscalers, orchestration frameworks, and frontier models.

Resolution: Preserve optionality while harness and observability technologies mature.

“The first thing I'd tell you — and I'm sure all of you face this every day — is what agentic stack to build on.”transcript, stated

Regulated agents need replayable decisions.

Root cause: Insurance or banking agents can produce decisions that must be audited for discrimination, crashes, and handoff.

Resolution: Build observability, replay, governance, and human handoff into the harness.

“Can you replay what happened if the agent gave an insurance rate? Did the agent discriminate? Did the agent not discriminate?”transcript, stated

More agents increase cost pressure.

Root cause: Agentic workflows can multiply token spend as agent usage grows.

Resolution: Treat cost as part of the agent platform and model-selection design.

“One of the things I think comes with more agents is more token spend and more cost.”transcript, stated

Warehouse-lagged data is not enough for real-time agents.

Root cause: Customer-facing agents need fresh context for decisions, unlike analytics queries.

Resolution: Use a context and memory layer fed in real time.

“It needs to have the right context and memory so that the agent can make real-time decisions. And it needs to be fed in real time.”transcript, stated

Evaluation

The transcript emphasizes pre-production evaluation, audit/replay, observability maturity, and human handoff as the readiness checks for regulated customer-facing agents.

Metrics: Evaluation readiness before production · Replayability of agent decisions · Human takeover handling · Token spend and cost · Real-time context latency

“we want to make sure our evaluation before we even do that is rock solid.”transcript, stated

“Now in 2026, they're feeling that some technologies around observability are maturing. Some technologies around the harness are maturing.”transcript, stated

Outcomes

The transcript reports AI-native scale with ElevenLabs using MongoDB for 40 million production agents.
Large enterprises are still stabilizing agent stacks after 2025 agent-scale plans did not pan out.
MongoDB positions real-time data and memory as central infrastructure for customer-facing agents.

The case cites 40 million production agents, $500 million ARR, 50 million plus customers, and MongoDB presence in 75-plus percent of the Fortune 100.

“they thought 2025 was the year to create agents at scale for their customers — and that agents at scale didn't pan out to be true for these large enterprises.”transcript, stated

“And once they moved to MongoDB, they now have 40 million production agents built on MongoDB.”transcript, stated

Enterprise AI Adoption Patterns and Production Agent Deployment at Scale

Problem

Architecture

Components

Data flow

Why this architecture

Scale

Alternatives considered (roads not taken)

Use a hyperscaler's first-party database for AI-native agent scale.

Commit early to a single frontier model or hyperscaler stack.

Deploy customer-facing regulated agents without human takeover.

Build real-time agents directly on a data warehouse.

Patterns

agent-memory (memory)

human-in-the-loop-gate (governance)

observability-tracing (operations)

model-routing (model-ops)

Tradeoffs

Use a real-time context and memory layer.

Keep humans in regulated loops.

Maintain model and stack optionality.

Gotchas (what bit them)

Agent-stack choice is unstable for large enterprises.

Regulated agents need replayable decisions.

More agents increase cost pressure.

Warehouse-lagged data is not enough for real-time agents.

Evaluation

Outcomes

`agent-memory` (memory)

`human-in-the-loop-gate` (governance)

`observability-tracing` (operations)

`model-routing` (model-ops)