Materialize Cuts AI Agent Reaction Time to One Second Using SQL Diffs

Powering Agents with Search: Creating Interactive Vector Pipelines with SQL With Materialize — Ai4

Ai4

Incremental view maintenance precomputes business logic on write, letting autonomous AI agents observe transactional state changes within one second while avoiding costly vector re-embeddings.

AI-assisted summary of Powering Agents with Search: Creating Interactive Vector Pipelines with SQL With Materialize — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 18, 2026, this presentation features Seth Wiesman, Field CTO at Materialize, exploring how to build interactive vector and search pipelines using SQL. The session description highlights methods for transforming operational data into semantic objects, selectively patching search indexes and embeddings, and keeping agent context fresh enough for reliable real-time action.

## TL;DR AI agents depend on an iterative observe-think-act loop, but production implementations frequently fail when agents make decisions over stale context. While dumping raw CDC streams into search engines causes slow multi-way query joins and batch data warehouses suffer from severe sawtooth staleness gaps, Incremental View Maintenance (IVM) precomputes business-level 'semantic objects' on write. This approach emits fine-grained data diffs that update live operational attributes instantly without triggering expensive vector re-embeddings for static text. By maintaining continuous freshness and deterministic sub-second response times, IVM establishes a live context graph that enables multi-agent workflows to interact with real-world state in real time.

## Atmosphere & style The presentation carries a sharp, pragmatic, and highly accessible engineering tone, demystifying complex data pipelines through vivid everyday analogies like keyless car entry and Chipotle ingredient prep. Wiesman delivers a structured, confident narrative arc that methodically deconstructs common architectural anti-patterns before detailing the incremental SQL solution. The overall feel is that of an engaging, high-signal conference masterclass, concluding with a grounded, practical Q&A session that honestly defines workload trade-offs and performance realities.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=k5tTZwvMPos&t=4s) AI agents operate in an iterative Observe-Think-Act loop, where production failures most often stem from poor observation over stale or untrusted context rather than reasoning flaws. - [01:40](https://www.youtube.com/watch?v=k5tTZwvMPos&t=100s) Full-text search provides lexical matching and vector search enables semantic retrieval, but agents also require live operational attributes to determine whether an item is valid and actionable in the moment. - [03:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=205s) Interactive agents depend on immediate feedback with an architectural 'time to trusted action' reaction budget of roughly one second to verify the consequences of their actions. - [05:36](https://www.youtube.com/watch?v=k5tTZwvMPos&t=336s) Streaming raw CDC records directly into search engines forces agents to perform complex multi-way joins at read time, causing multi-second query latencies and infrastructure bottlenecks. - [07:21](https://www.youtube.com/watch?v=k5tTZwvMPos&t=441s) Precomputing raw data into unified semantic objects ahead of time minimizes token overhead in LLM prompts, improves reasoning accuracy, and ensures deterministic read performance. - [09:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=565s) Scheduled batch warehouse pipelines create a 'sawtooth staleness' pattern where agent actions remain invisible until the next batch run, reducing agents to purely read-only actors. - [11:41](https://www.youtube.com/watch?v=k5tTZwvMPos&t=701s) Incremental View Maintenance (IVM) solves staleness by computing work on write rather than read, maintaining materialized views using minimal mathematical deltas across complex SQL joins and aggregations. - [13:46](https://www.youtube.com/watch?v=k5tTZwvMPos&t=826s) Diff-driven incremental patching updates numerical or status attributes in search indices without triggering expensive vector re-embedding of static text fields. - [16:18](https://www.youtube.com/watch?v=k5tTZwvMPos&t=978s) Continuously updated semantic objects form an enterprise live context graph, allowing multi-agent production workflows to hand off tasks instantaneously without batch delay intervals. - [19:20](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1160s) IVM achieves faster reaction times than querying normalized transactional databases directly by eliminating heavy on-the-fly SQL evaluations in favor of granular delta updates. - [21:10](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1270s) IVM engines sit upstream of data warehouses adjacent to operational OLTP systems for real-time agent context, while data warehouses remain best suited for retrospective, exploratory analytics.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=k5tTZwvMPos&t=4s) The Agent Loop and the Missing Ingredient: Live Trustworthy Context

An artificial intelligence agent fundamentally operates in an iterative loop: it observes the current state of the world, thinks using a large language model (LLM), and executes an action. That loop repeats continually until the agent reaches its designated goal. However, in moving agents from experimental lab environments into production systems, failures most frequently occur at the very first step: observation. If an agent cannot observe what is true in the exact moment it acts, reasoning capability becomes irrelevant—the model is merely hallucinating or calculating over stale and false premises, leading to actions that cannot advance the task.

To illustrate what agents lack, Seth Wiesman uses an everyday automotive analogy: modern keyless entry. When walking up to a locked car with the key fob in pocket, simply pulling the door handle prompts the vehicle to unlock and open immediately. The vehicle succeeds because it maintains live, trustworthy context about physical reality. It knows with certainty that the authorized driver is standing right next to that specific door with that specific key. Most current agent architectures completely lack this level of immediate, situated awareness.

```mermaid flowchart LR accTitle: The Agent Execution Loop subgraph Loop["Interactive Agent Loop"] direction LR O1["1. Observe<br/>(Real-World State)"] --> T["2. Think<br/>(LLM Reasoning)"] T --> A["3. Act<br/>(Execute Tool/Action)"] A --> O2["4. Observe Again<br/>(Inspect Consequence)"] end ```

[01:40](https://www.youtube.com/watch?v=k5tTZwvMPos&t=100s) Combining Full-Text Search, Vector Search, and Live Attributes

Because LLMs reason through natural language, the most intuitive mechanism for an agent to acquire context is by asking questions. Search serves as the bridge that translates natural language inquiries into structured context. When an agent searches for a known entity—such as querying a product catalog for "bananas"—traditional full-text search excels at retrieving direct lexical matches: organic bananas, banana bread, banana chips, or novelty t-shirts featuring dancing bananas.

When an agent grasps a conceptual intent without knowing the exact terminology, vector embeddings provide semantic reasoning by projecting meaning into multi-dimensional space. Under vector search, a query for "bananas" can surface "plantains"—an item whose textual description might never mention the word banana, but which remains, as Wiesman puts it, "scientifically speaking... pretty banana-y." Yet semantic similarity and lexical relevance only solve half the operational problem: - **Search and vectors** determine what items are conceptually *relevant*. - **Live operational attributes** determine what items are relevant *right now* (e.g., whether plantains are physically in stock, shippable to a specific user address, and accurately priced against running promotional discounts).

[03:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=205s) The Interactive Feedback Loop and the FreshMark Challenge

Truly autonomous agents depend on interactivity. Agents almost never "one-shot" complex goals; instead, they generate a plan and execute it incrementally. Just as a human software engineer using a coding agent relies on real-time feedback—checking if code compiles, verifying if unit tests pass, and adjusting course based on errors—an enterprise agent needs immediate verification of its actions. This requirement defines the core architectural North Star: **time to trusted action** (or reaction time), representing the duration between an event occurring in the physical or digital world and an agent being able to observe its consequence. For an interactive agent, this reaction budget must stay around approximately one second.

To ground this operational requirement, consider **FreshMark**, a hypothetical on-demand grocery platform functioning like a DoorDash for pantries. FreshMark coordinates customers, storefronts, couriers, inventory, and orders across a dense constellation of microservices and underlying databases. While FreshMark wants to deploy autonomous systems—such as automated customer support agents handling escalations or fleet dispatchers dynamically rerouting delivery vehicles—the engineering team faces the challenge of keeping the agent loop tightly coupled to transactional state.

[05:36](https://www.youtube.com/watch?v=k5tTZwvMPos&t=336s) The Naive Architecture: Dumping CDC into a Raw Search Index

A common initial pattern relies on standard enterprise plumbing: capturing change data capture (CDC) streams from microservices, relational databases, ERPs, and CRMs, and dumping the raw records straight into a shared search engine like Elasticsearch, OpenSearch, or Turbopuffer. Teams often assume that because the LLM is intelligent, it can stitch together the disparate raw records on the fly.

```mermaid flowchart TD accTitle: Naive CDC Pipeline to Search Index subgraph Sources["Raw Source Systems"] DB1["Orders DB"] DB2["Customers DB"] DB3["Couriers CRM"] end subgraph Pipeline["Ingestion & Search"] CDC["CDC / ETL Pipeline"] SI["Raw Search Index<br/>(Elastic / OpenSearch)"] end subgraph AgentLayer["Agent Execution"] Agent["Agent Context Read<br/>(Multi-second latency, High CPU)"] end

DB1 --> CDC DB2 --> CDC DB3 --> CDC CDC --> SI SI --> Agent ```

In practice, raw search indexes are not engineered to execute complex, multi-way joins across ten disparate source tables during an agent's context read. While data ingestion via CDC occurs rapidly, search queries become cripplingly slow. When FreshMark tested this setup with a single agent running in a loop, query times climbed to multi-second delays while database CPU spiked uncontrollably. Attempting to scale this pattern to production workloads causes the infrastructure to collapse because it forces the agent to reason over raw infrastructure abstractions rather than cohesive business entities.

[07:21](https://www.youtube.com/watch?v=k5tTZwvMPos&t=441s) Semantic Objects and Precomputing Context

When a support agent is onboarded, they do not care about entity-relationship diagrams, foreign keys, or the internal microservice topology; they simply need a unified representation of a "customer." These unified business entities are **semantic objects**—the foundational nouns of an enterprise (such as customers, orders, products, stores, and delivery trucks). Crucially, a semantic object is not merely a denormalized relational table. It integrates operational data directly with applied business logic: - A unified customer object must encapsulate the base customer record, active order history, current payment statuses, instant refund eligibility calculations, and governing policy rules. - Context queries must be **precomputed ahead of time** rather than aggregated on the fly, ensuring that servicing one agent or one million agents carries the same deterministic read cost in terms of infrastructure compute and query response time.

Precomputing semantic objects yields two major architectural advantages: - **Higher reasoning accuracy:** The agent's prompt context is no longer cluttered with low-level schema joins, relational artifacts, or raw policy scripts. The model focuses solely on resolving the user's immediate problem. - **Token efficiency:** Eliminating unneeded intermediate structural data drastically reduces the token footprint inside the LLM context window.

[09:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=565s) The Batch Warehouse Trap and the Chipotle Analogy

To avoid complex manual denormalization pipelines, teams frequently turn to data warehouses, data lakes, or "context lakes" running batch SQL models on cloud object storage. When FreshMark switched to scheduled analytical SQL runs, the context reads appeared solved: query latencies plummeted from multi-second delays down to single-digit milliseconds, remaining stable even when hundreds of agents queried the dataset simultaneously.

```mermaid flowchart TD accTitle: Batch Warehouse Sawtooth Staleness Pattern subgraph Ingest["Batch Warehouse / Lakehouse"] Storage["Cloud Object Storage"] --> BatchSQL["Scheduled SQL Batch<br/>(Hourly / Daily Refresh)"] end subgraph Query["Fast Reads vs Stale Data"] BatchSQL --> Precomputed["Precomputed Tables<br/>(Single-digit ms reads)"] Precomputed --> ReadAgent["Agent Read Loop"] ReadAgent -.->|"Action Taken"| Drift["Sawtooth Staleness Gap<br/>(Action consequences invisible until next batch)"] end ```

The victory is an illusion. While read latency becomes negligible, system reaction time degrades drastically into a "sawtooth pattern." Once an agent acts, the consequence of that action remains invisible until the next hourly or daily batch job completes. In the interim, context continually drifts away from real-world conditions, reducing an agent to a fundamentally "read-only" actor that cannot verify its own modifications.

To overcome this dilemma, Wiesman points to Chipotle's operational philosophy. Chipotle manages to serve meals that are simultaneously fast and fresh through continuous integration: raw ingredients arrive continuously and are proactively prepped and transformed into ready-to-serve components at the counter. Because the preparatory labor occurs proactively rather than at the moment of the order, any customer can walk up and assemble a custom steak bowl or chicken burrito instantly without sacrificing ingredient freshness. Building an interactive vector pipeline for production agents demands that exact same proactive, continuous model.

[11:41](https://www.youtube.com/watch?v=k5tTZwvMPos&t=701s) The Chipotle Metaphor: Incremental View Maintenance for Context Engineering

Context engineering can draw direct inspiration from Chipotle: the kitchen preps all the base ingredients ahead of time so that when a customer arrives, staff can assemble the final meal reactively and customize it on the spot. In data systems, engineers can continually integrate raw operational data and pre-aggregate it into structured semantic objects stored in a search index or vector database, while still granting the AI agent full runtime flexibility to assemble context in whatever shape it requires. Keeping these representations perpetually fresh has a long-established answer in computer science literature known as Incremental View Maintenance (IVM).

In traditional relational databases, a view is merely a syntactical convenience—a named query where the database re-executes all the underlying business logic from scratch whenever a user requests it. By contrast, an IVM engine proactively maintains the materialized output of that view as changes occur in the base tables, performing the computational work on write rather than on read. Crucially, "incremental" means the engine does not recompute entire datasets; it mathematically calculates the minimal delta required to patch the existing result set. This capability holds true even across arbitrarily complex SQL, including multi-way joins, window aggregations, and recursive graph-traversal queries. If a system contains a thousand customers and a single record updates, the database modifies only that specific affected row rather than churning through the remaining 999 records.

```mermaid flowchart LR accTitle: Incremental View Maintenance Pipeline subgraph Ingestion["Write Path"] A["OLTP Writes"] --> B["CDC Stream"] end subgraph Engine["Materialize / IVM"] B --> C["Incremental View Logic"] C --> D["State Diff Engine"] end subgraph Serving["Downstream Storage"] D --> E["Search Index / Vectors"] D --> F["Agent Context Layer"] end ```

[13:46](https://www.youtube.com/watch?v=k5tTZwvMPos&t=826s) Diffs for Free: Selective Index Patching and Cost-Efficient Embeddings

A major structural advantage of an incremental architecture is that it produces fine-grained data diffs essentially for free. When an update occurs, the engine emits precisely which rows and which columns changed. This granular change-tracking allows applications to patch external search indexes continuously without executing expensive, full-table overwrites. It also radically slashes machine learning costs associated with vector embeddings, because teams only pay an embedding model when text fields actually change.

In a typical product catalog, a product's text description may be embedded for semantic retrieval; while that description rarely changes, the available inventory count shifts up and down constantly throughout the business day. With diff-driven patching, the database pushes inventory updates into the search index immediately while leaving the vector embedding untouched, preventing the system from re-embedding the static description thousands of times unnecessarily. Consequently, response times for agent queries drop to the sub-second speed of simple point lookups, while reaction times—the latency between a write in the operational system and its availability in the index—become significantly faster than executing ad-hoc analytic queries directly against the source database.

- **Response Time:** Point-lookup query latencies remain on the same fast order of magnitude as a fully indexed data warehouse because pre-computations are already completed. - **Reaction Time:** Fresh writes become visible in roughly one second via continuous Change Data Capture (CDC) and incremental processing. - **Embedding Cost Optimization:** Vector endpoints are invoked strictly when embedded textual attributes change, rather than on every numerical or status change.

[16:18](https://www.youtube.com/watch?v=k5tTZwvMPos&t=978s) Interactive Multi-Agent Production Workflows and the Live Context Graph

Deploying this architecture to production transforms how operational support and fulfillment agents collaborate. For example, a customer support agent might receive an order request to supply an office party of 50 people with burrito bowl ingredients. Fulfilling that request requires live situational awareness: verifying the product catalog, confirming localized stock levels, validating shipping constraints, and enforcing dynamic budget rules. Because semantic objects are continuously maintained in search, the agent immediately discovers valid items and places the order autonomously.

The second an agent takes action, the updated order status, item pricing, and scheduled delivery times become instantly visible—not just to human operators monitoring administrative dashboards, but to downstream automated agents. A fulfillment agent can immediately pick up the newly generated order and trigger warehouse logistics in real time rather than waiting for an overnight batch pipeline. As more domains are introduced—customers, products, inventory, and fulfillment centers—these interconnected semantic objects coalesce into a real-time "live context graph" of the enterprise, allowing software agents to become fully interactive operational participants.

- **Fast Agent Actions:** Agents validate constraints (stock, budget, fulfillment windows) against freshly updated search indices in real time. - **Inter-Agent Hand-offs:** Upstream agent writes immediately trigger downstream consumer agents without batch-delay intervals. - **Enterprise Context Graph:** Models business relationships (customers place orders, orders comprise products, warehouses fulfill orders) dynamically in SQL. - **Enterprise Adoption:** Materialize powers operational architectures for organizations including Notion, Bilt Rewards, Crane Worldwide Logistics, and General Mills.

[19:20](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1160s) Q&A: Unpacking Reaction Time vs. Source Queries

During the audience question-and-answer period, an attendee asked for clarification regarding the distinction between response time and reaction time, and how an IVM engine can boast a reaction time faster than querying the original data source directly. Seth Wiesman walked through an architectural comparison using a normalized relational database:

> "Let's say that you have a Postgres database. And you have data in there, and it's normalized across five tables. And we know to turn it into the customer object, you got to run a five-way join, and there's a window function, and there's some aggregation... If you query Postgres directly, yes, when a write occurs, it's visible instantaneously. But it has to run through that complicated query for you to see the result."

Because running that complex query over raw data can easily take ten seconds or more, the system's effective reaction time remains sluggish. With an IVM system, raw writes are streamed via CDC in a few milliseconds. The engine recognizes that only a single customer row was touched, applies the minimal delta calculation, and updates the pre-joined semantic record almost instantaneously. Because the incremental approach bypasses full-dataset scans and repeated join computations, changes become observable orders of magnitude faster than evaluating heavy analytical SQL directly against operational transactional tables.

[21:10](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1270s) Q&A: Placement in the Data Stack and When Not to Use IVM

An audience member asked whether an IVM engine like Materialize must sit on top of an existing data lake, or how it functions if an organization lacks a lake entirely. Seth clarified that IVM platforms typically sit upstream of data warehouses and lakes, positioned directly adjacent to operational OLTP databases, CRMs, and ERPs. By the time data lands inside an enterprise data lake, it may already be an hour stale. To guarantee freshness, the IVM engine ingests live changes directly from operational data stores via CDC. Once clean semantic objects and customer views are computed, those enriched records can optionally be streamed back downstream into the data warehouse or lake, preventing the engineering organization from having to compute identical business logic twice.

When asked about anti-patterns, pitfalls, and when *not* to adopt an IVM system, Seth emphasized that no single technology is a universal panacea:

| Workload Dimension | Incremental View Maintenance (IVM) | Data Warehouse / Data Lake | |:--- |:--- |:--- | | **Primary Workload** | Interactive operational applications and live agent actions | Exploratory, retrospective, and ad-hoc analytical queries | | **Data Freshness** | Sub-second, real-time streaming updates via CDC | Batched, hourly, or daily ingest pipelines | | **Query Predictability** | Known semantic objects and structured operational views | Free-form exploratory queries without predefined access paths | | **Typical Use Case** | Powering agents, live inventory checks, real-time context | Quarterly executive sales reporting, broad marketing campaign retrospectives |

While running software agents directly against core OLTP databases is "almost exclusively a bad idea" due to resource contention and performance risks, IVM engines excel where agents require tightly looped, interactive access to shared business entities. Conversely, if an organization is building exploratory, read-only analytics—such as compiling an executive retrospective to determine why a previous quarter's marketing initiative succeeded or failed—traditional data warehouses remain the superior and recommended tool for the job.

## Notable quotes > How do you keep search indexes and vector databases fresh enough for an agent to act on? — Seth Wiesman

> Search has become the predominant way agents see the world. But keeping vectors and attributes up to date is complex, forcing teams to choose between stale documents, expensive batch updates, or complex pipelines. — Seth Wiesman

> patch your search index with only changed attributes and embeddings, and enrich results with fresh context to give agents the full picture. — Seth Wiesman

> [01:40](https://www.youtube.com/watch?v=k5tTZwvMPos&t=100s) scientifically speaking... pretty banana-y. — Seth Wiesman

> [03:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=205s) time to trusted action — Seth Wiesman

> [09:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=565s) sawtooth pattern — Seth Wiesman

> [16:18](https://www.youtube.com/watch?v=k5tTZwvMPos&t=978s) live context graph — Seth Wiesman

> [19:20](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1160s) Let's say that you have a Postgres database. And you have data in there, and it's normalized across five tables. And we know to turn it into the customer object, you got to run a five-way join, and there's a window function, and there's some aggregation... If you query Postgres directly, yes, when a write occurs, it's visible instantaneously. But it has to run through that complicated query for you to see the result. — Seth Wiesman

> [21:10](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1270s) almost exclusively a bad idea — Seth Wiesman

## Mentioned Seth Wiesman, Materialize, Ai4, FreshMark, DoorDash, Elasticsearch, OpenSearch, Turbopuffer, Chipotle, Postgres, Notion, Bilt Rewards, Crane Worldwide Logistics, General Mills

## Video description Seth Wiesman - Field CTO, Materialize

How do you keep search indexes and vector databases fresh enough for an agent to act on? Search has become the predominant way agents see the world. But keeping vectors and attributes up to date is complex, forcing teams to choose between stale documents, expensive batch updates, or complex pipelines. This talk will show how to architect a search pipeline in SQL that keeps your search index up to date and trustworthy enough for agents to rely upon. You'll learn how to transform your operational data into documents and semantic objects, patch your search index with only changed attributes and embeddings, and enrich results with fresh context to give agents the full picture. Attend if you're deploying AI agents to production and want to give them fresher, more complete context, and tighten their read-act-react loop.

[Source](https://www.youtube.com/watch?v=k5tTZwvMPos)

中文简报

Materialize 利用 SQL 差异将 AI Agent 反应时间缩短至一秒 增量视图维护在写入时预计算业务逻辑，使自主 AI Agent 能够在一秒内观察到事务状态变化，同时避免高昂的向量重嵌入开销。 AI Agent 依赖于迭代的“观察-思考-行动”循环，但生产环境中的落地往往因 Agent 基于过时的上下文做出决策而频繁失败。将原始 CDC 流直接导入搜索引擎会导致查询时缓慢的多路连接，而批处理数据仓库则面临严重的锯齿状数据陈旧问题；相比之下，增量视图维护（IVM）在写入时预计算业务层面的“语义对象”。该方法输出细粒度的数据差异，能即时更新实时运行属性，且无需对静态文本触发昂贵的向量重嵌入。通过保持持续的新鲜度和确定性的亚秒级响应时间，IVM 构建了实时上下文图谱，使多 Agent 工作流能够与真实世界状态展开实时交互。 AI Agent 在迭代的“观察-思考-行动”循环中运行，生产环境的失败绝大多数源于对过时或不可信上下文的糟糕观察，而非推理缺陷。 (0:04) 全文搜索提供词法匹配，向量搜索实现语义检索，但 Agent 还需要实时运行属性来确定某一项在当下是否有效且可操作。 (1:40) 交互式 Agent 依赖即时反馈，架构上大约需要一秒的“达成可信行动时间”反应预算，以验证自身操作带来的后果。 (3:25) 将原始 CDC 记录直接流式传输到搜索引擎，会迫使 Agent 在读取时执行复杂的多路连接，从而引发数秒级的查询延迟和基础设施瓶颈。 (5:36) 提前将原始数据预计算为统一的语义对象，能最大限度降低 LLM 提示词中的 Token 开销，提高推理准确性，并确保确定性的读取性能。 (7:21)

Reading summary

Seth Wiesman argues that autonomous AI agents fail primarily during observation due to stale context, and that bridging natural language search with transactional data requires precomputing unified semantic objects using Incremental View Maintenance rather than ad-hoc queries or periodic batch jobs. The Observation Dilemma and Agent Reaction Time (0:04) Autonomous agents execute a continuous loop: observe the world, reason using a large language model, act, and inspect the consequences. In production, failures cluster at the observation phase: when an agent reasons over stale data, its actions fail to advance goals regardless of model sophistication. Wiesman compares the required contextual awareness to modern keyless entry, where a vehicle continuously knows the precise location of an authorized key fob and unlocks instantly upon contact. While lexical search retrieves direct matches and vector embeddings capture semantic intent (such as connecting "bananas" to "plantains"), static relevance fails without live operational attributes like local inventory, dynamic pricing, and delivery eligibility. Because production agents execute incrementally rather than "one-shotting" complex tasks, Wiesman defines the core architectural benchmark as "time to trusted action"—the latency between a physical or digital event and an agent's ability to observe it—which must remain within an approximate one-second reaction budget. The Limits of Raw Search and Batch Warehouses (5:36) Using a hypothetical on-demand delivery platform named FreshMark, Wiesman outlines two standard architectural failures. The first involves streaming Change Data Capture (CDC) events directly into search engines like Elasticsearch or OpenSearch, expecting LLMs to stitch records together dynamically. In practice, search indexes are poorly optimized for multi-way relational joins across disparate operational tables; in FreshMark's tests, agent context queries caused multi-second latencies and severe database CPU spikes. Teams often pivot to batch SQL runs in cloud data warehouses or context lakes, which reduces agent read times to single-digit milliseconds. However, this introduces a "sawtooth staleness pattern": once an agent executes a change, the outcome remains invisible until the next hourly or daily batch refresh runs. Context drifts continually away from reality, reducing the agent to a read-only observer incapable of validating its own actions in an interactive loop. Precomputing Semantic Objects via Incremental View Maintenance (7:21) To eliminate the trade-off between read speed and data freshness, Wiesman advocates precomputing "semantic objects"—foundational enterprise business nouns like customers, orders, and couriers that package operational records together with business logic and refund policies. Drawing an analogy to Chipotle, where staff proactively prep ingredients so customers can assemble custom bowls on demand, data pipelines should continuously pre-aggregate business context so agents can read complete entities instantly. This continuous precomputation relies on Incremental View Maintenance (IVM). Unlike standard database views that re-execute entire queries upon each request, an IVM engine computes on write, applying the minimal mathematical delta required to update materialized view state as base tables change. This incremental computation functions across complex SQL joins, aggregations, and window functions without requiring full table scans, keeping agent read costs deterministic regardless of concurrent traffic. Fine-Grained Diffs, Cost Controls, and Multi-Agent Workflows (13:46) A major operational benefit of IVM is generating granular row- and column-level diffs automatically. In e-commerce catalogs, this allows systems to push frequent numerical inventory updates to search indexes in roughly one second while keeping static text descriptions untouched, avoiding repeated API costs for regenerating vector embeddings. Wiesman notes that because the engine updates pre-joined semantic views via minimal deltas, reaction times become significantly faster than executing heavy multi-table analytical queries directly against source databases. In production environments, sub-second reaction times enable multi-agent collaboration and a live enterprise context graph. When a support agent modifies a customer order, the updated state, logistics constraints, and pricing become instantly visible to downstream fulfillment agents without batch pipeline pauses. Materialize has deployed this architecture across organizations including Notion, Bilt Rewards, Crane Worldwide Logistics, and General Mills. Wiesman emphasizes that IVM platforms typically sit directly upstream of data warehouses adjacent to transactional OLTP systems to consume live CDC streams, rather than replacing warehouses altogether. While IVM is designed for interactive operational loops and predictable semantic entities, traditional data warehouses remain the appropriate architecture for ad-hoc, retrospective, and exploratory analytics where real-time freshness is unnecessary.

精炼阅读摘要

Seth Wiesman 指出，AI 智能体在生产环境中受阻的核心原因并非模型推理能力欠缺，而是系统缺乏反映现实世界的即时可信上下文。为了将智能体的反应时效控制在约 1 秒内，架构设计需要借助增量物化视图（IVM）预计算业务语义对象，化解传统数仓的批量滞后与搜索索引实时多表关联的高昂开销。 智能体执行循环与反应时间挑战 (0:04) AI 智能体的基本工作流表现为“观察、思考、行动”的持续闭环。然而，当实验性智能体迁移到生产环境时，最容易在最开始的“观察”阶段崩溃。如果智能体无法获知行动发生那一刻的真实环境状态，大语言模型的推理就只能基于过时或虚假的前提展开，造成幻觉或无效决策。智能体极少能通过单次生成（one-shot）直接解决复杂任务，其运作本质依赖于实时的增量反馈与纠错，正如软件工程师依赖实时的代码编译和单元测试结果调整实现方案一样。 这一交互要求确立了智能体架构的核心衡量指标——“可信行动反应时间”（Time to Trusted Action），即物理或数字世界产生状态变更到智能体能够观测到该结果的时间差。以假设的即时生鲜平台 FreshMark 为例，系统需要动态协调顾客、商户、派送员、库存与订单微服务，若要让调度或客服智能体顺利运作，其观察到自身行动后果的反应时间预算必须收敛在约 1 秒左右。 朴素搜索管道与批处理数仓的失效 (5:36) 为了向智能体注入上下文，常见的初期设计是借助变更数据捕获（CDC）将微服务、关系型数据库及 ERP 的原始事件直接写入 Elasticsearch 或 OpenSearch 等通用搜索引擎，寄希望于大语言模型自行关联拼凑原始碎片。然而，原始搜索索引并非针对跨多张数据表的复杂多路关联（multi-way joins）设计。FreshMark 的实测显示，哪怕仅有一个智能体在循环中运行，多表实时查询也会导致检索延迟激增至数秒并引发数据库 CPU 满载，无法支撑生产级规模。 为规避关联计算开销，团队往往转向在数据仓库或“上下文湖”中按固定计划运行 SQL 批处理模型。这种方式虽然能将智能体的单次读取延迟压低至数毫秒，却引入了严重的“锯齿状陈旧（sawtooth staleness）”问题。由于底层数据仅按小时或按天刷新，智能体一旦执行了某项操作，其操作后果在下一个批处理周期前完全不可见。在此期间，上下文与真实世界持续脱节，导致智能体退化为无法验证自身行动影响的“只读”执行器。 增量物化视图与预计算语义对象 (11:41) 业务智能体并不需要直接面对数据库的外键与微服务架构，而是需要标准化的“语义对象”（Semantic Objects），例如封装了基础信息、活跃订单、支付状态、退款资格判定和业务策略的统一“客户”对象。为了兼顾灵活性与低延迟，Wiesman 借用 Chipotle 餐厅流水线的运作模型：厨房提前将各类食材切配烹饪就绪，柜台服务员便能在顾客点单的瞬间即时组装个性化餐食，而无需现场重头制作。 在数据架构中，持续维护这些结构化语义对象的技术实现是增量物化视图（Incremental View Maintenance, IVM）。与传统数据库在读取时重新扫描执行的视图不同，IVM 引擎将计算负载前置到数据写入阶段。当底层源表发生变更时，引擎在数学层面仅计算更新当前结果集所需的最小增量（delta），而无需重算全量数据。即使面对多表连接、窗口聚合及递归查询，一千条记录中若发生一条变动，系统也只处理受影响的那一行，保证读取端稳定的确定性成本。 细粒度差异与向量嵌入成本优化 (13:46) 增量架构的另一核心优势在于能够天然输出细粒度的数据变更差异（diffs），精确指明发生变动的行与列。这一特性允许系统对外部搜索索引进行增量补丁更新，避免了耗费计算资源的全表覆盖重写。同时，细粒度差异消除了非必要的模型调用开销，大幅降低了向量嵌入的运行成本。 在电商产品目录等典型场景中，商品的文本描述常被转换为向量以支持语义检索，这类描述文本变更极少，但可用库存数量却在全天持续浮动。借助基于差异的精准推送机制，系统在库存发生波动时仅需单向更新搜索索引中的状态属性，而无需对静态文本重新计算嵌入向量。这使得智能体的查询响应时间保持在毫秒级单点查找水平，同时确保从业务系统发生写入到索引可见的反应时间进入秒级区间。 多智能体动态图谱与技术适用边界 (16:18) 当客户、商品、库存及物流等领域的语义对象均通过 IVM 持续同步至检索层后，各业务实体将在底层相互交织，形成实时的“动态上下文图谱”。以上游客服智能体协助完成包含 50 人餐食的大额订购为例，系统能即时校验库存与配送约束，订单生成并写入的瞬间，更新后的物流状态与定价会同步暴露给下游的仓储履约智能体，无缝触发发货流程，消除了跨系统协作中的批处理延迟。 关于系统落地边界，Wiesman 澄清 Materialize 等 IVM 引擎通常部署在业务 OLTP 数据库与下游数据湖之间，直连 CDC 变更流以保证新鲜度，计算出的规整数据可反哺给数仓。IVM 专为已知语义对象的高并发、即时交互操作设计，避免了智能体直接压垮核心事务库；然而，对于非预设模式的宽泛探索、管理层季度报表或事后回顾性分析，传统数据仓库与数据湖依然是更为合适的选择。 增量物化视图通过在写入路径上执行最小增量计算，消除了智能体在反应延迟与数据新鲜度之间的取舍，但该方案依赖于预先建模的业务语义对象，无法完全替代面向非预设、探索性分析的传统数据仓库与数据湖。

Detailed notes — zh

## Background 本视频由 Ai4 于 2026 年 8 月 18 日发布在 YouTube 平台，由 Materialize 的 Field CTO Seth Wiesman 主讲。视频简介指出，演讲核心探讨如何通过 SQL 构建交互式搜索与向量管道，利用增量更新属性和向量嵌入来保持检索索引的新鲜度，从而为生产环境中的 AI Agent 提供实时、可信的上下文并缩短其反馈回路。 ## TL;DR 演讲指出 AI Agent 在生产环境中落地的核心瓶颈在于缺乏“实时可信上下文”，并提出应将约 1 秒的“反应时间”作为衡量交互闭环的北极星指标。主讲人深入剖析了将 CDC 原始数据直接倾倒至搜索引擎导致高延迟，以及传统数仓批处理引发锯齿状数据滞后的两大架构反模式。针对这些痛点，Materialize 借鉴 Chipotle 备餐模式提出了基于增量物化视图（IVM）的语义对象方案，仅需增量推导最小计算量并打补丁式更新向量与属性。该方案不仅将反馈回路压缩至秒级，还通过多实体交织构建出实时在线的“企业级上下文图谱”。 ## Atmosphere & style 整场演讲呈现出干练务实、直击痛点的技术布道风格，主讲人善于运用汽车无钥匙进入与连锁快餐备餐等生活化比喻拆解晦涩的数据流概念。内容节奏紧凑且逻辑严密，通过清晰的架构对比与真实案例展示了深厚的系统设计功底。在最后的现场问答互动中，讲者对“IVM 反应时间为何快于直查数据源”等硬核疑问进行了透彻的算力剖析，整体氛围兼具技术深度与工业实战指导意义。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=k5tTZwvMPos&t=4s) AI Agent 的核心运行机制是“观察-思考-行动（Observe-Think-Act）”的闭环，而系统失败往往源于无法观察到物理世界真实发生的实时可信上下文（Live trustworthy context）。 - [01:31](https://www.youtube.com/watch?v=k5tTZwvMPos&t=91s) 关键词检索与语义向量检索仅解决了相关性（Relevance）问题，而围绕文档的实时动态业务属性（如实时库存、折后价格、履约能力）才决定了什么是当下相关的业务事实。 - [03:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=205s) 评估交互式 Agent 系统的北极星指标是反应时间（Reaction Time / Time to Trusted Action），即从现实世界变化到系统能观察到变动结果的时间，理想状态需压缩在 1 秒左右。 - [05:04](https://www.youtube.com/watch?v=k5tTZwvMPos&t=304s) 架构反模式一：直接将 CDC 原始表数据倾倒至 Elasticsearch 等搜索引擎，会让 Agent 面临多表关联与复杂查询瓶颈，导致查询延迟高达数秒甚至系统崩溃。 - [07:21](https://www.youtube.com/watch?v=k5tTZwvMPos&t=441s) 解决复杂读取的关键在于构建预计算的语义对象（Semantic Objects），将底层零散的表关联和动态业务规则前置计算，既提升推理准确性又大幅节省 LLM 输入 Token 开销。 - [09:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=565s) 架构反模式二：依赖传统数据仓库/数据湖进行定时批处理物化，会产生严重的锯齿状延迟衰减（Sawtooth Pattern），导致 Agent 退化为只能处理陈旧历史数据的只读型系统。 - [11:41](https://www.youtube.com/watch?v=k5tTZwvMPos&t=701s) 增量物化视图（Incremental View Maintenance, IVM）在行级数据写入时主动计算最小变更差分（Diffs），即使面对多表 Join 与窗口函数也能实现极低算力开销的实时维护。 - [11:41](https://www.youtube.com/watch?v=k5tTZwvMPos&t=701s) IVM 带来的轻量差分更新避免了昂贵的重复 Embedding 计算，文本未改动时仅局部 Patch 更新库存等变动数值，大幅降低向量数据库维护成本。 - [14:54](https://www.youtube.com/watch?v=k5tTZwvMPos&t=894s) 由于写入时已前置完成增量计算，IVM 架构下的业务反应速度甚至远快于直接在 OLTP 原始库上执行全量扫描关联查询，成功将交互闭环压进 1 秒内。 - [16:18](https://www.youtube.com/watch?v=k5tTZwvMPos&t=978s) 由 IVM 维系的客户、订单、库存等语义对象交织形成“活的企业级上下文图谱（Live Context Graph）”，使多个协同 Agent 能毫秒级感知彼此的写入动作与最新业务状态。 - [19:20](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1160s) 系统拓扑上，IVM 应当紧贴上游 OLTP 业务数据库通过流式 CDC 捕获变更，而不是架设在已经存在数小时延迟的数据湖之上；计算后的宽表可再异步回写至数仓。 - [22:34](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1354s) 技术选型边界：IVM + 实时检索层适用于业务模式明确、追求秒级反馈的交互式生产 Agent，而对于不可预测、无规律的历史探索性报表分析，传统数据仓库仍是更合适的选择。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=k5tTZwvMPos&t=4s) AI Agent 的核心闭环与实时可信上下文 Materialize 的 Field CTO Seth Wiesman 探讨了如何将 AI Agent（智能体）从实验室推进到企业生产环境。从底层逻辑来看，Agent 的运行本质上是一个不断循环的回路：它首先**观察（Observe）**世界的当前状态，然后利用大语言模型（LLM）进行**思考（Think）**，接着采取特定的**行动（Act）**。这一“观察-思考-行动”的循环会持续重复，直到 Agent 达成预设目标。 ```mermaid flowchart LR accTitle: Agent Read-Act-React Loop subgraph AgentLoop ["Agent 闭环运作机制"] direction LR O["观察世界状态<br/>(Observe)"] --> T["LLM 逻辑思考<br/>(Think)"] T --> A["执行具体操作<br/>(Act)"] A --> O end ``` 然而，在实际落地中，系统往往在最基础的第一步——“观察”——就宣告崩溃。如果 Agent 无法感知当前真实发生的状态，那么无论底层的模型多么聪明，它都是在基于虚假或过时的信息进行推理，其采取的任何行动都无法真正推进任务。Wiesman 以自己的汽车无钥匙进入功能做类比：只要车钥匙在口袋里，伸手拉动车门把手，车门就会瞬间自动解锁。汽车之所以能做到这一点，正是因为拥有多数 Agent 所匮乏的“关于物理世界的实时可信上下文（Live trustworthy context）”——汽车确切知道车主正带着特定的车钥匙站在门边。正是基于这种实时上下文，系统才能做出精准、可靠的物理响应。 ### [01:31](https://www.youtube.com/watch?v=k5tTZwvMPos&t=91s) 从关键词检索、语义向量到动态业务属性 Agent 主要通过自然语言来理解世界与进行推理，因此它获取上下文最直接的方式就是“提问”，而**搜索（Search）**则是将问题转化为上下文的关键机制。传统的全文搜索能够精准匹配具体关键词，例如在商品目录中搜索“香蕉（bananas）”，系统能召回所有包含该词条的库存商品：有机香蕉、香蕉面包、香蕉干，甚至是印着香蕉图案的 T 恤。 但很多时候，Agent 仅知道模糊的意图而缺乏精准的词汇。引入向量检索（Vector Search）后，系统能够进行语义层面的关联推理。例如搜索“香蕉”时，向量检索能关联出“大蕉（plantains）”——即便大蕉的商品描述中从未出现“香蕉”一词，但两者的语义与科学特征高度相似。然而，单纯的关键词与向量检索仅解决了“相关性（Relevance）”问题，无法解答实时的业务事实： - 当前仓库里到底有没有大蕉库存？ - 是否能够及时配送给特定的目标客户？ - 结合当前的各种促销活动，该商品的实时折后价格是多少？ 因此，搜索和向量决定了“什么是相关的”，而环绕在文档周围的**动态属性（Attributes）**才决定了“什么在当下是相关的”。 ### [03:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=205s) 交互式闭环的北极星指标：反应时间（Reaction Time） 在构建交互式 Agent 时，其“观察-思考-行动-再次观察”的闭环至关重要。Agent 几乎不可能单次尝试（one-shot）就完美解决复杂问题，它通常会制定计划并逐步执行，每走一步都需要校验：“我是否正朝着正确方向前进？当前的行动是否奏效？我是否需要调整计划？”这与工程师使用代码辅助 Agent 的体验一致——写完代码后，必须立刻看到编译是否通过、单测是否跑通。 因此，衡量此类系统的北极星指标应当是**反应时间（Reaction Time / Time to Trusted Action）**：从真实世界发生变动（或 Agent 采取某项操作），到系统能够观察到该变动产生的结果，究竟需要耗费多长时间？为了构建真正的交互式系统，这一反应延迟必须被压缩到**1 秒左右**。 | 评估维度 | 原始 CDC 直连搜索索引 | 传统数据仓库 / 数据湖批处理 | 理想的交互式搜索管道 | |:--- |:--- |:--- |:--- | | **数据接入延迟** | 极低（实时写入） | 较高（批量抽取） | 极低（持续流式接入） | | **单次上下文读取查询耗时** | 极高（多秒级，CPU 飙升） | 极低（毫秒级，预计算） | 极低（毫秒级，即时响应） | | **真实业务反应时间 (Reaction Time)** | 极长（查询瓶颈导致闭环卡顿） | 极长（呈锯齿状，依赖批处理周期） | **~1 秒**（兼具低读取延迟与高时效性） | | **对大规模 Agent 的承载力** | 差（高并发复杂读取下系统崩溃） | 好（并发读取成本低，但数据过时） | 优秀（预先物化，低成本支撑海量 Agent） | ### [05:04](https://www.youtube.com/watch?v=k5tTZwvMPos&t=304s) 架构反模式一：直接将 CDC 原始数据倾倒至搜索引擎 以一家类似 DoorDash 的生鲜杂货配送平台“Freshmark”为例，其业务涵盖客户、门店、骑手、实时订单，底层充斥着复杂的微服务与数据库集群。Freshmark 尝试为其客服支持 Agent（处理自动升级诉求）和车队调度 Agent（监控货车并实时重新规划路线）构建上下文搜索管道。 常见的工程做法是利用成熟的变更数据捕获（CDC）和 ETL 技术，将各个微服务、关系数据库、CRM/ERP 系统中的原始变更数据实时同步到共享的检索系统（如 Elasticsearch、OpenSearch 或 TurboPuffer）中，期望 LLM 自行去理清关联。 ```mermaid flowchart LR accTitle: CDC to Search Index Bottleneck subgraph Ingestion ["数据摄取"] direction TB DB["微服务 / 多源数据库"] -->|CDC 实时摄取| IDX["共享搜索索引<br/>(Elasticsearch / OpenSearch)"] end subgraph QueryBottleneck ["查询与推理瓶颈"] direction TB IDX -->|散落 10+ 系统的低级数据| AG["Agent 发起复杂关联读取"] AG -.->|查询耗时多秒 / CPU 爆表| AG end ``` 这种架构的致命缺陷在于**底层的存储与检索模型无法承载 Agent 所需的复杂上下文读取**。客户数据往往分散在 10 多个不同的微服务和表中，Agent 只关心统一的“客户”概念，并不关心底层的分布式架构。直接在原始数据上执行复杂的上下文检索，会导致查询延迟高达数秒、CPU 算力过载，一旦并发上线多个 Agent，系统就会彻底崩溃。 ### [07:21](https://www.youtube.com/watch?v=k5tTZwvMPos&t=441s) 引入语义对象（Semantic Objects）与预计算 解决这一矛盾的关键在于**提升业务抽象层级**。新入职的客服人员不需要了解底层的微服务架构或 ER 图外键关系，他们只需要一份统一的客户全景档案。这种业务的核心名词被称为**语义对象（Semantic Objects）**——例如客户、订单、商品、门店、卡车和车队。 语义对象不仅仅是一张宽表（Denormalized Table），而是**结合了动态业务逻辑的数据实体**。一个高价值的“客户语义对象”应当封装： - 客户基本档案及其实时有效订单； - 当前的支付状态与退款资格判断； - 适用于该客户的所有实时业务规则与策略。 为了在支撑海量 Agent 并发运行的同时保持低成本，语义对象必须**提前预计算（Precompute）**。无论是 1 个 Agent 还是 100 万个 Agent 读取上下文，系统消耗的算力成本都应当保持平稳。预计算语义对象带来两大直接优势： 1. **显著提高准确性**：避免将低层级的业务规则、表关联细节等噪声塞满 Context Window，让 Agent 专注于核心业务推理。 2. **大幅提升 Token 效率**：只向 LLM 传递最终的业务计算结果，极大节省输入 Token 开销。 ### [09:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=565s) 架构反模式二：数据仓库批处理带来的“锯齿状”延迟衰减 如果直接利用传统数据仓库或数据湖（如基于对象存储构建的 Context Lake），工程师可以使用熟悉的 SQL 逻辑将分散的多源数据清洗、整合并聚合成语义对象。采用定时批处理（例如每天或每小时跑一次 batch refresh）后，Agent 的上下文检索查询耗时确实能从多秒级降至毫秒级，且能平稳承受数千个 Agent 的并发读取。 ```mermaid flowchart TD accTitle: Batch Warehouse Sawtooth Latency subgraph BatchPipeline ["批处理链路"] direction LR S["业务多源数据"] -->|定时抽取| DW["数据仓库 / 数据湖 (SQL 批处理)"] DW -->|周期性刷新 (天/小时)| SO["物化语义对象"] end subgraph LatencyIssue ["反应延迟缺陷"] direction TB SO -->|查询耗时: 单位数毫秒| AG["Agent 极速读取"] AG -->|执行动作并产生新变更| S SO -.->|数据严重滞后 / 呈锯齿状衰减| AG end ``` 然而，这种设计引发了严重的**反应时间漂移（Sawtooth Pattern，锯齿模式）**： - 系统刚完成一次批处理刷新时，数据是最新的； - 随着时间推移，现实世界发生的变化（包括 Agent 自身执行的操作）无法被即时反馈，数据与真实世界的偏差越来越大； - Agent 必须等待下一次批处理完成才能观察到上一动作的结果。 这种长延迟的反馈链路从根本上限制了 Agent 的能力，使其退化为只能处理静态历史数据的“只读型 Agent（Read-only Agent）”。 ### [11:02](https://www.youtube.com/watch?v=k5tTZwvMPos&t=662s) 理想解法：像 Chipotle 一样实现“持续集成与即时物化” 为了同时满足“高集成度、毫秒级查询、实时新鲜度”三个要求，Wiesman 借用了连锁餐厅 Chipotle 的供应链模式做比喻：Chipotle 能够做到既出餐快又保证食材新鲜，原因在于其门店内实行**持续集成（Continuous Integration）**——源源不断的原材料被送达门店后，后厨会持续将其加工成半成品并整齐陈列在柜台前。 正是因为所有的清洗、切配、烹饪工作都已提前主动完成，当顾客来到柜台前点单时，无论是想要一份牛排碗（Steak bowl）还是一份鸡肉卷饼（Chicken burrito），店员都可以在几秒钟内快速组装并交付，既保证了食材的鲜度，又实现了极致的响应速度。这也正是构建互动式 Agent 所需要的流式数据管道核心范式。 ### [11:41](https://www.youtube.com/watch?v=k5tTZwvMPos&t=701s) 借鉴 Chipotle 模式：反应式组装与增量物化视图（IVM） 构建智能体上下文时，可以从知名快餐连锁店 Chipotle 的备餐流程中汲取灵感：后厨预先将各种原材料加工到半成品状态，当顾客到店点单时，服务员再根据其精确口味进行快速组装。在数据工程中，同样可以借助这种思路——持续集成底层业务数据，并将其预先转换为可在向量数据库或搜索引擎中检索的语义对象（Semantic Objects）；而在智能体执行具体任务的读取时刻（Read Time），依然保留极高的灵活性，按需把各部分拼装成所需的最终上下文。 计算机科学领域其实很早以前就给出了保持数据实时更新的标准解法，那就是**增量物化视图（Incremental View Maintenance，简称 IVM）**。在传统关系型数据库中，视图（View）本质上只是一种方便编写的“语法糖”或命名业务逻辑，每次调用时底层仍需重新执行全部 SQL 查询。而 IVM 则完全不同，它在数据发生写入（Write）时主动对视图结果进行维护。 ```mermaid flowchart LR accTitle: Incremental View Maintenance Flow subgraph Operational ["业务数据源 (OLTP)"] Raw["原始行级更新 / CDC"] end subgraph Engine ["IVM 引擎 (如 Materialize)"] IVM["增量物化视图 (IVM)<br/>多表 Join / 聚合 / 图递归"] Diff["变更差分提取 (Diffs)"] IVM --> Diff end subgraph Serving ["智能体消费层"] Index["搜索引擎 / 向量索引<br/>(仅更新改动属性)"] Embed["按需重算 Embedding<br/>(非修改文本跳过)"] Agent["智能体执行回路 (~1秒)"] end Raw --> IVM Diff --> Index Diff --> Embed Index --> Agent Embed --> Agent ``` 这里的关键词是“增量（Incremental）”，意味着系统不再对全量数据进行反复扫描计算，而是精准推导出更新结果所需的最小计算量。即便是面对复杂的跨表多路 Join、窗口函数，甚至是遍历图形结构的递归 SQL，IVM 都能实时消化行级变更。如果数据库有 1,000 个客户，其中某个客户信息发生变化，IVM 只需重算受影响的那一行，整套引擎在绝大多数时刻所消耗的计算资源微乎其微。 - **免费获得的变更差分（Diffs）**：增量计算天然带来变更粒度的清晰可见性，系统能够精确掌握哪些行的哪些列被修改，并据此对搜索索引执行轻量 Patch 操作。 - **大幅降低 Embedding 成本**：向量嵌入需要昂贵的 API 调用成本。商品描述等文本可能经年不改，但库存量却整天实时波动；借助增量差分，系统只更新库存数值字段，避免因库存变更而无谓地将描述文本重新向量化上千次。 --- ### [14:54](https://www.youtube.com/watch?v=k5tTZwvMPos&t=894s) 性能断层优势：秒级反应时间与闭环交互 将绝大部分计算前置为主动推进（Proactive）后，系统达成了理想的数据架构平衡：搜索索引与 Embedding 永远处于最新鲜的状态，且没有冗余开销，同时还能保障动态上下文组装的自由度。在性能表现上，IVM 展现了惊人的反直觉特性： 1. **响应时间（Response Time）**：从发起查询到返回结果的时间，IVM 与顶尖数据仓库处于同一数量级，因为所有数据早已预计算完毕，本质上仅是一次简单的点查找（Point Lookup）。 2. **反应时间（Reaction Time）**：从底层业务发生变动到上层智能体感知到该变动的时间窗口。IVM 的反应速度甚至远快于直接去查询原始数据源。 直接去查询包含原始数据的业务库时，数据库必须在读取时刻暴力扫描所有表以完成运算；而在 IVM 体系下，上游变更通过 CDC（变更数据捕获）实时推入，引擎只花极小代价增量更新对应行。这种架构最终将智能体的“感知-决策-行动-反应”反馈循环（Feedback Loop）压进了大约 1 秒钟之内。 --- ### [16:18](https://www.youtube.com/watch?v=k5tTZwvMPos&t=978s) 落地实战：从办公订餐到全企业动态上下文图谱 在具体业务落地场景中（例如智能支持代理），智能体经常需要处理高度依赖即时状态的复合指令。比如一位员工发起需求：“帮我为 50 人的办公室派对订购墨西哥卷饼碗（Burrito Bowl）的原材料。”这绝不仅仅是查询静态的商品目录，智能体必须实时掌控： - 当前商品真实的动态库存量（In Stock）； - 能否准时发货运送到指定地点； - 是否符合预算上限及实时变动的价格策略。 ```mermaid flowchart TD accTitle: Live Context Graph Customers["客户实体 (Customers)"] Orders["订单实体 (Orders)"] Products["产品目录 (Products)"] Inventory["动态库存/仓储 (Warehouses)"] Customers -->|"发起"| Orders Orders -->|"包含"| Products Inventory -->|"履约支持"| Orders ``` 利用基于 IVM 构建的语义对象，代理能在几毫秒内检索齐备全部动态属性并完成自动下单。更关键的是，当该代理完成写入操作后，更新立刻反映在系统中，不仅人类可以在仪表盘上实时看到订单总价与交付时间，其他智能体（例如负责拣货配货的仓储履约代理）也能毫秒级感知该订单的存在并立即展开行动，而不是等到第二天批处理同步后才迟钝介入。 从单点应用逐步扩展，系统将融入客户、订单、产品、库存等越来越多的实体。这些由 IVM 维系的语义对象交织在一起，自然构成了一张“活的企业级上下文图谱（Live Context Graph）”。它永远保持精准、永远实时在线，使得各类 AI 智能体真正成为组织运营中的协同参与者。Materialize 团队已将该模式推向生产实践，服务了包括 Notion、Bilt Rewards、Crane Worldwide Logistics 以及通用磨坊（General Mills）在内的众多企业级客户。 --- ### [19:20](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1160s) 现场问答：透视“反应时间”本质与系统拓扑定位 现场观众在 Q&A 环节围绕系统指标与架构部署提出了深度疑问： #### 反应时间为何能超越直查数据源？ 观众对“反应时间优于原始系统”深感困惑。对此，Seth Wiesman 举例剖析：假设 Postgres 数据库中某个业务对象需要跨 5 张标准化表做关联，外加窗口函数与聚合计算。 - **直查 Postgres**：尽管底层行写入可见是即时的，但为了生成最终的顾客业务对象，每次查询都必须耗费昂贵的算力跑完复杂的 5 表 Join 与窗口函数，整个反应时间可能需要长达 10 秒。 - **IVM 架构**：写入发生后，通过 CDC 将变动推送进 IVM 仅需数毫秒；随后 IVM 迅速判断出此次更新仅波及 1 个客户的一行数据，瞬间完成视图增量刷新。尽管看似在前端增加了链路，但它所执行的实际计算量低了几个数量级，让数据生效的速度反而提前了数倍。 #### IVM 是否必须架设在数据湖（Data Lake）之上？ 答案是否定的。实际上，IVM 系统通常不会架在数据湖之上，而是布局在更靠近上游的地方——介于 OLTP 业务数据库与下游数据仓库/数据湖之间。原因在于实时性： - 真实的鲜活数据源头在 OLTP、CRM 或 ERP 系统中。 - 当数据历经批处理流转到数据湖时，往往已经产生了一小时以上的延迟（Stale）。 - 正确的模式是将 IVM 紧贴 OLTP，通过低延迟 CDC 流式捕获，在 IVM 内部生成实时上下文服务智能体；同时，计算好的客户大宽表或业务快照还能被异步回写推送到下游数据仓库，避免数仓团队重复造轮子进行二次计算。 --- ### [22:34](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1354s) 现场问答：避坑指南与选型边界 在谈及该架构的局限性与不推荐采用的场景时，Seth 明确指出没有任何工具是放之四海皆准的灵丹妙药（Panacea），并给出了明确的场景红线： | 评估维度 | 推荐方案 | 不推荐方案 / 避坑要点 | |:--- |:--- |:--- | | **生产级交互智能体 (Interactive)** | **IVM 引擎 + 实时检索层**<br/>业务模式清晰（如高频复用客户、订单、库存等预定义实体），追求极致新鲜度与紧凑反馈回路。 | **绝不要让智能体直连 OLTP 跑复杂 SQL**<br/>这是生产部署的重大禁忌，极易打垮核心线上事务。 | | **探索性分析与离线决策 (Exploratory)** | **传统数据仓库 (Data Warehouse)**<br/>应对不可预测的复杂只读查询，如为管理层拉取上一季度的营销转化与销售趋势复盘。 | **避免使用 IVM 承接无规律报表**<br/>对于系统无法预测其访问路径的纯只读低频大查询，数仓是更成熟且划算的选择。 | 最根本的决策分水岭在于：应用究竟属于要求秒级互动的生产型代理（Interactive Application），还是仅仅作为一个消费静态历史报表的只读客户端（Read-only Consumer）。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=k5tTZwvMPos&t=4s) 如果 Agent 无法感知当前真实发生的状态，那么无论底层的模型多么聪明，它都是在基于虚假或过时的信息进行推理，其采取的任何行动都无法真正推进任务。 — Seth Wiesman > [01:31](https://www.youtube.com/watch?v=k5tTZwvMPos&t=91s) 搜索和向量决定了‘什么是相关的’，而环绕在文档周围的动态属性（Attributes）才决定了‘什么在当下是相关的’。 — Seth Wiesman > [03:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=205s) 从真实世界发生变动（或 Agent 采取某项操作），到系统能够观察到该变动产生的结果，究竟需要耗费多长时间？为了构建真正的交互式系统，这一反应延迟必须被压缩到1秒左右。 — Seth Wiesman > [05:04](https://www.youtube.com/watch?v=k5tTZwvMPos&t=304s) 底层的存储与检索模型无法承载 Agent 所需的复杂上下文读取。 — Seth Wiesman > [07:21](https://www.youtube.com/watch?v=k5tTZwvMPos&t=441s) 语义对象不仅仅是一张宽表（Denormalized Table），而是结合了动态业务逻辑的数据实体。 — Seth Wiesman > [07:21](https://www.youtube.com/watch?v=k5tTZwvMPos&t=441s) 无论是 1 个 Agent 还是 100 万个 Agent 读取上下文，系统消耗的算力成本都应当保持平稳。 — Seth Wiesman > [09:25](https://www.youtube.com/watch?v=k5tTZwvMPos&t=565s) 这种长延迟的反馈链路从根本上限制了 Agent 的能力，使其退化为只能处理静态历史数据的‘只读型 Agent（Read-only Agent）’。 — Seth Wiesman > [11:41](https://www.youtube.com/watch?v=k5tTZwvMPos&t=701s) 增量（Incremental），意味着系统不再对全量数据进行反复扫描计算，而是精准推导出更新结果所需的最小计算量。 — Seth Wiesman > [11:41](https://www.youtube.com/watch?v=k5tTZwvMPos&t=701s) 商品描述等文本可能经年不改，但库存量却整天实时波动；借助增量差分，系统只更新库存数值字段，避免因库存变更而无谓地将描述文本重新向量化上千次。 — Seth Wiesman > [14:54](https://www.youtube.com/watch?v=k5tTZwvMPos&t=894s) IVM 的反应速度甚至远快于直接去查询原始数据源。 — Seth Wiesman > [19:20](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1160s) 尽管看似在前端增加了链路，但它所执行的实际计算量低了几个数量级，让数据生效的速度反而提前了数倍。 — Seth Wiesman > [22:34](https://www.youtube.com/watch?v=k5tTZwvMPos&t=1354s) 绝不要让智能体直连 OLTP 跑复杂 SQL，这是生产部署的重大禁忌，极易打垮核心线上事务。 — Seth Wiesman ## Mentioned Seth Wiesman, Materialize, Ai4, DoorDash, Freshmark, Elasticsearch, OpenSearch, TurboPuffer, Chipotle, PostgreSQL, Notion, Bilt Rewards, Crane Worldwide Logistics, 通用磨坊 (General Mills), CDC (Change Data Capture), IVM (增量物化视图 / Incremental View Maintenance) ## Video description Seth Wiesman - Field CTO, Materialize How do you keep search indexes and vector databases fresh enough for an agent to act on? Search has become the predominant way agents see the world. But keeping vectors and attributes up to date is complex, forcing teams to choose between stale documents, expensive batch updates, or complex pipelines. This talk will show how to architect a search pipeline in SQL that keeps your search index up to date and trustworthy enough for agents to rely upon. You'll learn how to transform your operational data into documents and semantic objects, patch your search index with only changed attributes and embeddings, and enrich results with fresh context to give agents the full picture. Attend if you're deploying AI agents to production and want to give them fresher, more complete context, and tighten their read-act-react loop. [Source](https://www.youtube.com/watch?v=k5tTZwvMPos)

Source quotes

[0:04] Seth Wiesman: 如果 Agent 无法感知当前真实发生的状态，那么无论底层的模型多么聪明，它都是在基于虚假或过时的信息进行推理，其采取的任何行动都无法真正推进任务。 [1:31] Seth Wiesman: 搜索和向量决定了‘什么是相关的’，而环绕在文档周围的动态属性（Attributes）才决定了‘什么在当下是相关的’。 [3:25] Seth Wiesman: 从真实世界发生变动（或 Agent 采取某项操作），到系统能够观察到该变动产生的结果，究竟需要耗费多长时间？为了构建真正的交互式系统，这一反应延迟必须被压缩到1秒左右。 [5:04] Seth Wiesman: 底层的存储与检索模型无法承载 Agent 所需的复杂上下文读取。 [7:21] Seth Wiesman: 语义对象不仅仅是一张宽表（Denormalized Table），而是结合了动态业务逻辑的数据实体。 [7:21] Seth Wiesman: 无论是 1 个 Agent 还是 100 万个 Agent 读取上下文，系统消耗的算力成本都应当保持平稳。 [9:25] Seth Wiesman: 这种长延迟的反馈链路从根本上限制了 Agent 的能力，使其退化为只能处理静态历史数据的‘只读型 Agent（Read-only Agent）’。 [11:41] Seth Wiesman: 增量（Incremental），意味着系统不再对全量数据进行反复扫描计算，而是精准推导出更新结果所需的最小计算量。 [11:41] Seth Wiesman: 商品描述等文本可能经年不改，但库存量却整天实时波动；借助增量差分，系统只更新库存数值字段，避免因库存变更而无谓地将描述文本重新向量化上千次。 [14:54] Seth Wiesman: IVM 的反应速度甚至远快于直接去查询原始数据源。 [19:20] Seth Wiesman: 尽管看似在前端增加了链路，但它所执行的实际计算量低了几个数量级，让数据生效的速度反而提前了数倍。 [22:34] Seth Wiesman: 绝不要让智能体直连 OLTP 跑复杂 SQL，这是生产部署的重大禁忌，极易打垮核心线上事务。

Source quotes

Seth Wiesman: How do you keep search indexes and vector databases fresh enough for an agent to act on? Seth Wiesman: Search has become the predominant way agents see the world. But keeping vectors and attributes up to date is complex, forcing teams to choose between stale documents, expensive batch updates, or complex pipelines. Seth Wiesman: patch your search index with only changed attributes and embeddings, and enrich results with fresh context to give agents the full picture. [1:40] Seth Wiesman: scientifically speaking... pretty banana-y. [3:25] Seth Wiesman: time to trusted action [9:25] Seth Wiesman: sawtooth pattern [16:18] Seth Wiesman: live context graph [19:20] Seth Wiesman: Let's say that you have a Postgres database. And you have data in there, and it's normalized across five tables. And we know to turn it into the customer object, you got to run a five-way join, and there's a window function, and there's some aggregation... If you query Postgres directly, yes, when a write occurs, it's visible instantaneously. But it has to run through that complicated query for you to see the result. [21:10] Seth Wiesman: almost exclusively a bad idea

Original transcript

[0:04] Thank you so much for joining. My name is Seth  Weisman. I am field CTO at Materialize. We are [0:08] the live context engine for the enterprise. Uh  and I have the privilege every day of working [0:13] with engineering leaders taking agents from  the lab into production. Now, fundamentally [0:21] and I I think everyone here knows this, an agent  is something that works in a loop. It observes the [0:25] current state of the world, it thinks using its  large language model, and then takes some action. [0:30] That loop is going to repeat over and  over until the agent reaches its goal. [0:36] Now, when I see things fail in practice, often it  is in that very first step of observation. Because [0:44] if your agent isn't able to observe what's true  right now, then it doesn't matter how smart it is [0:51] because it's reasoning over false information,  and the action is not going to move you forward. [0:58] Now, my car has this really cool feature where  if the door is locked, but I have the key in my [1:04] pocket, if I grab the handle and pull, it is going  to automatically unlock and open. And that works [1:11] because my car has what most agents are missing.  And that is live trustworthy context about the [1:18] real world. It knows that I'm standing next  to the door with my key for this specific car. [1:26] And because it has that information, it is able  to act. It is going to unlock the door and let [1:31] me get inside. So, this is a talk about powering  agents with interactive search pipelines, sort of [1:40] keyword search here. Uh so, when an agent needs  to understand the world, it's going to reason in [1:48] language. Like, that's what large language models  do. And so, the most natural thing an agent can [1:53] can do to get context is ask a question. Search  is a way that we can turn questions into context. [2:02] Now, sometimes this agent knows what it's looking  for. We're searching our product catalog for [2:07] bananas and we're going to find all the different  varietals in stock. We have bananas and organic. [2:13] We also have banana bread. We have banana chips.  We have a t-shirt with a banana doing one of [2:18] these. It's a lot of things that have the word  banana in it and and full text search can help us [2:22] find those. But sometimes your agent knows the  idea but not precisely what it's looking for. [2:31] So, we're going to layer on vector search for  semantic reasoning and now a search for bananas [2:36] is going to turn back plantains. Nor in the  description of a plantain does it use the word [2:42] banana but scientifically speaking they are pretty  banana-y and they might be what you really meant. [2:48] So, meaning is hard and embeddings vectors give us  a way to associate the meaning between different [2:55] ideas, find what's similar. But this is only half  the answer because while search and vectors are [3:02] going to tell us what's relevant, that doesn't  help us in knowing do we have plantains in stock [3:07] right now? Can we ship them to the specific  customer? What's the current price given [3:13] the various promotions we might be running? So,  while search and vectors tell us what's relevant, [3:18] these attributes around your document  tell us what's relevant right now. [3:25] So, this is a talk about powering agents  with interactive search pipelines. [3:29] Keyword on interactive. When you are building  an agent, again, it runs in a loop. It is going [3:37] to observe the world, think, take an action,  and then critically is going to observe again. [3:44] And that second observation, your agent wants to  see what happened after the last action I took. [3:53] More likely than not, an agent is not going to  one-shot a solution. It's going to create a plan [3:57] and it's going to start working against that plan.  But every step along the way, it needs to know [4:02] am I going in the right direction?  Am I not? Should I rethink my plan? [4:05] If you use a coding agent, you're you're  deeply familiar with this, right? You write [4:09] some code and then does it compile? Do my unit  tests pass? Have I solved the problem or not? [4:14] You have that live feedback and more  generic applications want that same flow. [4:20] So, the question becomes how long does it take  from when something happens and do we until we [4:26] can observe the consequence of that action? So,  that's the North Star metric we're going to set [4:31] for ourselves. It is time to trusted action  or reaction time. How long does it take from [4:37] when something happens in the real world until  we can observe the consequence of that change? [4:44] To build an interactive system, we're looking  for something on the order of about a second. [4:50] About 1 second from when we do something until we  can see if it worked. And this is going to unlock [4:55] interactive agents that can take charge in the  world. So, we're going to explore this through uh [5:04] example company Fresh Mark. Think of  them like a DoorDash delivery service [5:08] or like DoorDash for your pantry. And they  have customers and stores and couriers and [5:13] orders and lots of microservices and databases.  It's a busy app. There's a lot of moving parts. [5:19] And they want to put agents into production.  Again, we're not talking about coding agents, [5:23] but maybe a support agent that can  take care of escalations automatically [5:29] or a fleet manager that can watch your trucks and  reroute them to the most uh appropriate location. [5:36] So, what we said is that we want to have live  data and we want to be able to search it. Well, [5:44] ETL, CDC, these are well-tried and technologies.  We know how to put them into production. [5:49] And you go, "Look, I got a bunch of microservices,  I got a bunch of databases and ERMs and CRPs and [5:54] another acronym that I'm not thinking of." And  so, we'll go ahead and CDC all that data into [5:59] some shared search index. This could be an  elastic and open search or a turbo puffer. [6:03] And the agent can go reason over it. This thing's  smart, it'll figure it out. And and and it might [6:09] actually figure it out. The problem is this  system is not built for the complex context [6:17] reads that agents need. Because I might have  customer data spread across 10 different systems, [6:23] but the agent doesn't care about that, right?  It just wants to know what's a customer. [6:28] And so, what we find is that well, yeah, we can  get the raw data into our system very quickly. [6:35] But the read is very slow. And so, we end up with  a feedback loop that's broken because any given [6:42] read is going to take so long that it it just  doesn't work in practice. And Freshmark tries [6:47] this, and that's exactly what they see. This is a  single agent running just over and over in a loop. [6:54] Uh and on our system, it's taking multiple  seconds to get a response back. Our CPU is [7:01] is off the charts. If you try to run this at real  production scale, it's going to fall over. This is [7:05] not something that you could put into production.  And the problem is not that search is bad or fresh [7:13] data is bad. Like that's that's what we want. But  that we're reasoning over the wrong abstraction. [7:21] If we just hired a new support person, they  don't care about your microservice architecture, [7:28] your D diagrams, and foreign keys. They just want  to know what's a customer. I don't care where that [7:32] information came from. I just want a place I can  go and see, here's my unified customer profile. [7:39] We call these semantic objects. Often, you can  think of them as the nouns of your business. [7:44] They're the things that you and your team  are talking about day-to-day. Customers, [7:49] orders, products, stores, trucks, fleets, the  the important heartbeats of what you build. [7:56] And importantly, a semantic object  is not just a denormalized table, [8:02] but it's your data along with business logic.  Because a useful customer object might include [8:09] the customer record with their active  orders, with their payment status, [8:13] with their refund eligibility, and  all the policies that apply to them. [8:18] And because we want to run this at agent scale,  right? That we can have lots of these things [8:23] running at once, we want to make sure that we can  do this in a cost-effective way. And that means we [8:29] need to compute this ahead of time. If I have one  agent running or I have a million agents running, [8:34] it should cost me dollars and cents the same  amount to to serve those those context queries. [8:41] That means we need to precompute the results. [8:44] And if we do this, two really interesting things  are going to happen. The first is our agent [8:51] is going to naturally become more correct. Because  we're no longer filling its context window with [8:58] low-level details and policies and information  that isn't actually driving it towards its goal. [9:04] We're simply saying, "Here's the customer record.  Now, reason over the actual problem at hand." [9:10] We also become more token efficient because  again, we're not putting all this information [9:15] in the context window. We're giving it the final  results, the only thing that it actually needs [9:19] to reason over. So, maybe we go out and we try  to to build something, but that's complicated. [9:25] And you know what? There are tools out there that  are really great at taking lots of disparate data [9:32] and combining them in interesting ways. And it's  called the data warehouse or the data lake or [9:37] sometimes you hear people use the word context  like, but just hey, take some object storage, [9:41] put all your data in there, reprocess  periodically. And we can define maybe [9:47] complex sequel, but still just sequel, something  that your team knows how to write and ship. [9:53] And we'll rerun this once a day, once an hour. And  we ship to production and oh my god, we solved our [9:59] problem, right? Everyone's high-fiving, everything  seems great. We've gone from multi-digit seconds [10:03] to single-digit milliseconds. If you turn on  1,000 agents, this isn't going to materially [10:07] change because again, we've already done the hard  work. We're just serving the result. [snorts] [10:12] But you know this isn't the end of the story  because while our queries are fast, our reaction [10:18] time has fallen off a cliff. It falls into this  sawtooth pattern. Where once a day, once an hour, [10:24] we refresh the results, but then it drifts further  away from reality. Right? What action they take? [10:31] I don't know. You'll find out on the next  batch batch refresh. Batch refresh, excuse me. [10:36] So, we've ended up in this world where it takes a  little more time for the data to hit the warehouse [10:41] or the data lake. Then it takes a long time until  we refresh it. And yes, our context reads are very [10:46] fast at this point. But it takes so long for us  to observe the consequence of a change for that [10:54] action to propagate through the loop that we've  still fundamentally only built a read-only agent. [11:02] So, what we want is data that is integrated,  it's fast, it's fresh. And there's one company [11:08] out there that does this really well,  one of my favorite companies, Chipotle. [11:14] Chipotle has found a way to provide food that is  both fast and fresh by continuously integrating, [11:20] bringing raw ingredients to their stores, [11:23] continually transforming it into those raw  goods that you see sitting at the counter. [11:30] And now all of that work can be done proactively  so that if you or I show up to the counter, we [11:36] can order what we want. I can get the steak bowl  that I like, you can get your chicken burrito. [11:41] They have the raw parts finished enough that  when you show up, you can have this in exactly [11:48] the way you like. And context engineering can  take a lot of inspiration from from Chipotle. [11:56] Doing that last bit of work reactively. We can  continuously integrate our data and continually [12:02] transform it into these semantic objects  available in our search index or vector database. [12:10] And still give the agent the flexibility to  combine these in exactly the shape it needs [12:15] at at read time. If you want  to keep something up-to-date, [12:21] computer science literature has actually  had a solution to this for a very long time. [12:27] And it's called incremental view maintenance. This  is a concept in in some databases and starting to [12:33] become more popular. Where you can define some  SQL as a view. And and you're all familiar with [12:40] views. You say, "Here's some business logic with a  name." And a traditional database that just means [12:45] it's a convenience. You show up and you query the  view and it's like you ran all the SQL yourself. [12:50] But with incremental view maintenance, IVM,  we can proactively keep the results of that [12:55] view up-to-date as the underlying data changes.  It's the database is able to do work on a write. [13:02] And incremental is the important word here because  it means we're not reprocessing all the data, [13:09] but we are able to determine what's the minimum  amount of work required to update our result [13:16] through arbitrarily complex SQL, through  multi-way joins, window functions, maybe [13:22] even recursive SQL that's traversing a graph.  So, we can define our semantic objects as views [13:28] using incremental view maintenance and keep them  always up-to-date. It's going to be fresh because [13:35] at any given moment, the database is doing  almost no work, right? You have 1,000 customers, [13:40] we're not reprocessing all the data all the time.  We're reprocessing the one row that was updated. [13:46] The other interesting benefit  that comes out of here is that [13:52] when you work in this incremental pattern, you  get diffs of your data for free. What that means [13:59] is on any given change, you can see specifically  what did change. What rows were modified and what [14:07] columns within those rows were modified. And that  allows us to efficiently patch our search index [14:14] all the time, keeping it up-to-date. And for  embeddings, which might be a little expensive, [14:20] right? You got to pay somebody to embed your  data. We'll only re-embed things when they change. [14:26] That's really critical when you think about with  the text and the attributes. Like I might have a [14:31] product and a description that is embedded and  it could update at any time, but realistically [14:36] it won't. But the inventory of that product,  well, that's going up and down all day long. [14:42] And making sure that we can keep the index  up-to-date, we can keep the inventory of that [14:46] product up-to-date, but also don't re-embed the  description 1,000 times when nobody touched it. [14:54] So, we try this now and we end up in a much  better scenario. We are able to do the bulk of [14:59] our work ahead of time. We're able to do most of  it proactively. Keep that search index up-to-date, [15:05] keep our embeddings up-to-date without doing  any extra work, but still have the flexibility [15:10] for context assembly. And so, here we have all  of what we're seeing before. At the top are our [15:18] uh response times, like how long  does it take to query the thing? [15:21] And the bottom is our reaction time. And what you  can see at the top is that using an IVM engine, [15:27] we are able to get response times on the same  order of magnitude as our data warehouse. [15:32] We've already done the work. Like, it's just a  point look up of the data. But our reaction time [15:38] is actually better than querying the source system  itself. Now, this can be a little unintuitive, [15:45] but it's key. It's faster than querying the thing  that has the raw data. And the reason that happens [15:51] is that again, on any given change, we do almost  nothing. We do almost no work, as opposed to that [15:57] source system that's going to have to munch  through all your data every time you show up. [16:02] And so now we're in this world where, yep, we have  our IVM engine, our data shows up, we CDC it in, [16:09] we continuously do our contexts, and now we can  have a feedback loop that runs in about a second. [16:18] So, First Marqeta is going to take this into  production. And we're going to have a support [16:23] agent. And the first thing it might do is help  somebody place an order. So, somebody shows up, [16:27] and I The text is a little small, but  we're saying help somebody place an order [16:31] for an office party for 50 people. We want the  ingredients for a burrito bowl. We have to work [16:38] not just knowing what's in our product catalog,  but what's in stock, what can we ship to this [16:42] person, what's within our budget, attributes  that might modify at any given moment. And using [16:50] these semantic objects in a search system,  we can pull the relevant information quickly [16:58] and place the order on their behalf.  Looking at, again, what's in stock, [17:02] what's in budget, what do we actually want  to do. And when the agent places the order, [17:08] we will immediately see it available  to us. So, our order has been placed, [17:13] we can see the prices of the items, we can see  when it's going to be delivered. And this is [17:19] available to us as humans in the dashboard, but  more importantly, it's available to other agents. [17:23] Cuz maybe you have a fulfillment agent that's  going to go out and start to make sure this [17:27] order gets placed. Well, it's going to see that  right away. It's not going to see it tomorrow. [17:34] So, what we've described is a way to take  raw, siloed operational data and use an [17:42] incremental view maintenance engine to define  your semantic objects, keep them up to date, [17:47] ensure that you have the agility  to make changes as they come, [17:51] and enable these tight feedback loops. And  you can start to bring this to production. [17:55] You start with customers, but then you  bring in products and orders and inventory. [18:01] And what we find as we build these out is that  these semantic objects have relationships. Your [18:09] customers place orders, and orders are made of  products, and orders get fulfilled by warehouses. [18:15] And this is information your agent  can use to understand your business. [18:21] Hey, what should I be re-fulfilling based on the  orders? What should be true in the warehouse? [18:29] What we've built is a context graph. We've built  a live context graph of our business that is [18:34] always up to date, that is always correct, and  allows agents to become interactive participants [18:40] in our organization. Now, there are lots of  wonderful tools you can use to build this. Um [18:49] Materialize is is a company that that that tries  to do something like this. We work with lots of [18:53] very cool brands like Notion, Built Rewards,  Crane Worldwide Logistics, General Mills. [18:57] Um if that's at all something you're interested  in, we will be around and have a booth. [19:02] But I I appreciate everyone taking the time  today. And uh we have a little time left if [19:07] there are any questions. I would I would love  to answer them, but thank you all so much. [19:20] [applause] [19:21] Have any questions for Seth? Go ahead and  raise your hand. I can come over with the mic. [19:30] Hey, so great presentation. I understood how  you got the response times down. I was a bit [19:38] unclear about the concept of the reaction  time that you were talking about. Yeah. [19:42] So So, let's put search aside for a second. Like  let's forget about that. Let's say that you have [19:50] a Postgres database. And you have data in  there. And it's normalized across five tables. [19:57] And we know to turn it into the customer object,  you got to run a five-way join. And there's a [20:03] window function, and there's some aggregation.  There's all this work that has to happen. [20:08] If you query Postgres directly, yes, when a  write occurs, it's visible instantaneously. But, [20:15] it has to run through that complicated query for  you to see the result. And so your reaction time [20:22] still takes 10 seconds. Just making up a  number there. Whereas with an IVM engine, [20:30] it's working incrementally. So, a write  happens, it has to be CDC'd into the IVM system. [20:36] But, that's a couple milliseconds. That's  pretty fast. And then the IVM goes, "Oh, [20:41] I only need to update one row cuz this  update only affected one customer." [20:45] And so now, even though we have what  looks like more work at the front, [20:51] it's actually much less work. And you can see the  result of that change orders of magnitude sooner. [21:10] Thank you. So, does this IVM engine especially  materialize, right? So, does this have to sit [21:15] on top of your data lake or what if you don't  have a data lake? Yeah, so often it doesn't sit [21:23] on top of your data lake. It often sits upstream  of We what we find is these systems tend to live [21:29] closer to say your OLTP databases than your data  warehouse. It's it's sort of a trade between them. [21:35] And a common pattern may be and so just to expand  on why is that if you care about fresh data [21:44] that's in your OLTP system, it's in your CRM,  it's in your ERP. That's where live data lives. [21:49] By the time it hits the data lake  it might already be an hour stale. [21:55] So, you often want to live close to that OLTP  and you do the live CDC into the IVM engine. [22:03] And then a common pattern is  yes, you serve live contacts. [22:06] You can also push that data downstream. Like  I'm computing customer records. Data warehouse [22:11] probably also wants to know that for other use  cases. Be a shame to have to do the work twice. [22:16] So, these tools often support mechanisms  for integration out. But definitely closer [22:23] to the software engineering world, closer  to the OLTP database. Got you. Thank you. [22:34] Hi. Um curious to know how much like are  there instances where you wouldn't recommend [22:41] implementing this or any pitfalls? Yeah,  so when I absolutely like nothing is a [22:48] panacea. There there's no tool that you want  to use all the time. Here's what I would say is [22:53] having agents run against your OLTP [22:57] is almost exclusively a bad idea. That's the  one thing I will say sort of definitively. [23:02] Question is where should it run? And to that  I say, what are you doing? So, if your goal is [23:09] production applications, look, agents, part of the  power is that there's the flexibility, you don't [23:15] know what they're going to do. But at the same  time, you know, they all need to know customer [23:21] information, they all need to know warehouse  and like there's this these common patterns. [23:26] That's a great IBM use case. If, however,  you're building something that is exploratory, [23:32] I have no idea what this thing is going to want to  look at. And it's probably a read-only system. I'm [23:39] pulling a report for my executive team that  wants to look at understand sales trends from [23:44] last quarter. And wants to understand why that  big marketing initiative didn't work out or [23:49] did gangbusters. That like data warehouses are  phenomenal at that. You should absolutely stick [23:55] with those for those sorts of applications.  Um the what I would always think is [24:02] is this an interactive application  or is it a read-only consumer?