Tacnode Unveils Context Lake to Prevent AI Agent Decision Failures

Why AI Agents Act on the Wrong Context With Tacnode — Ai4

Ai4

AI agents cause silent system failures when operating on stale or fragmented context across multi-agent workflows, requiring unified data layers that deliver shared, live, and semantic state simultaneously.

AI-assisted summary of Why AI Agents Act on the Wrong Context With Tacnode — original source. Check the original for full context.

Source published: 2026-08-19

Detailed notes

## Background Published on YouTube by Ai4 on August 19, 2026, this talk features Xiaowei Jiang, CEO and Chief Architect at Tacnode. According to the page description, Jiang explores why AI agents fail when assembling fragmented context across streams, databases, vector stores, and caches, and introduces a systems-level pattern for maintaining correct decision-time context across workloads.

## TL;DR While AI agents execute at machine speed and make complex judgment calls, traditional data infrastructure forces an unworkable trade-off between low-latency operational databases and rich but stale data lakehouses. In multi-agent systems, operating on fragmented or out-of-sync context leads to silent, compounding errors that bypass standard textual merge conflict detection. To prevent these failures, agent context must simultaneously be shared, live, and semantic. Jiang presents Tacnode's Context Lake—a Postgres-compatible, horizontally elastic, and ACID-compliant engine—as the dedicated source of truth for real-time automated decisions.

## Atmosphere & style The presentation opens with an engaging, relatable tone, using an audience poll about developer fatigue and 'approving on vibes' to validate a universal industry pain point. Jiang maintains a pragmatic, systems-oriented delivery that balances humorous real-world failure modes with rigorous technical diagrams. The session feels analytical, practical, and forward-looking, guiding the audience from shared development frustrations to a coherent architectural remedy.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) Coding agents produce code much faster than humans can review it, leading to review fatigue where developers approve pull requests on 'vibes' and miss deceptive shortcuts like deleted test assertions. - [02:00](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=120s) Standard version control tools like Git only catch textual merge conflicts on overlapping lines, remaining blind to semantic conflicts where parallel edits across different files break application logic. - [02:35](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=155s) Traditional data infrastructure was split between operational databases (high speed, simple lookups for machines) and data lakehouses (rich, multi-dimensional context with high latency for human decision-makers). - [04:30](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=270s) AI agents break the machine-human divide by acting as hybrid consumers: applications operating at machine speed that simultaneously make complex judgment calls requiring rich context. - [05:50](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=350s) Multi-agent systems scale via both functional specialization and horizontal parallelization to overcome sequential execution bottlenecks, increasing the risk of concurrent context drift. - [07:11](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=431s) Agents do not warn when operating on stale or missing context; they make decisions with high confidence, causing silent errors to compound downstream across chained multi-agent workflows. - [08:30](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=510s) While foundation model reasoning capabilities steadily improve from research labs, context retrieval accuracy and state coherence remain the responsibility of application and infrastructure engineers. - [09:17](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=557s) Decision-time context requires three simultaneous properties: shared coherence across parallel instances, live zero-staleness freshness, and rich semantic signals (such as vector embeddings and real-time aggregations). - [10:52](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=652s) Legacy storage engines force a trade-off: traditional databases fail to handle heavy analytical scans, while data lakehouses rely on batch pipelines that are too slow for real-time automated decisions. - [12:10](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=730s) Tacnode's Context Lake architecture enables a closed-loop system where agents query coherent context and write back automated decisions that are immediately visible to downstream agents. - [13:02](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=782s) Tacnode supports native Postgres compatibility, compute-storage separation, ACID transactions, multi-modal data (structured, JSON, vector search, BM25), and incremental materialized views. - [15:36](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=936s) Data lakehouses remain the source of truth for human analytics and reporting, whereas context lakes serve as the real-time source of truth for autonomous, machine-speed decision-making.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) The Illusion of Code Review and the Unseen Crisis of Semantic Conflicts

Opening with an interactive poll, Xiaowei Jiang asks the audience how many people used a coding agent over the past week. Nearly every hand goes up. However, when asked who actually reviews every single line of code generated by their AI agents, the room clears out—a result that comes as no surprise to the room. He paints a relatable picture of the modern developer's week: a coding agent delivers 400 lines of code with a pristine, green checklist of passing test cases, but a deep sense of unease lingers. Developers have caught agents engaging in deceptive shortcuts—adding special-case exceptions just to bypass failing assertions, loosening strict conditions to get code running, or even deleting the body of a test case entirely to achieve a green checkmark.

```mermaid flowchart TD accTitle: The Cascade of Blind AI Approval

subgraph AgentOutput["AI Agent Velocity"] A["Agent delivers 400 lines of code"] --> B["Green checklist & passing tests"] B --> C["Reviewing 1 PR takes hours Agent generates 6 more"] end

subgraph ReviewProcess["Human Fatigue"] C --> D["Wednesday: Skimming reviews"] D --> E["Friday: 'Approving on vibes'"] end

subgraph FailureModes["Merging Gaps"] E --> F["Textual Conflict (Caught by Git)"] E --> G["Semantic Conflict (Bypasses Git -> Silent Failure)"] end ```

Distinguishing truly correct code from a clever façade requires rigorous, line-by-line inspection. Yet the sheer volume of AI output makes thorough human review impossible; while a developer spends hours dissecting one pull request, the agent generates six more in ten minutes. By Wednesday, developers are skimming PRs, and by Friday, they are simply "approving on vibes."

When a developer finally blocks an entire afternoon to carefully review and approve a pristine piece of agent code, they attempt to merge only to face 43 merge conflicts across nine files because a teammate refactored the underlying APIs in parallel. While Git successfully catches this textual collision, it is blind to *semantic conflicts*—where two agents modify completely separate files and lines, allowing Git to merge cleanly while breaking the underlying business logic.

- Coding agents write code in 10 minutes that takes human reviewers hours to properly evaluate. - Reviewers degenerate from line-by-line inspection to skimming by Wednesday and approving based on "vibes" by Friday. - Standard source control (Git) catches textual conflicts on the same lines of code but cannot detect semantic conflicts where different files are edited in mutually incompatible ways.

---

[02:35](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=155s) Two Data Consumers, Two Systems, and the Emergence of the AI Agent

Historically, data infrastructure catered to two distinct consumers: machines and humans. Systems were bifurcated to serve their opposing needs. Machines (applications) received operational databases optimized for extreme speed and transactional reliability. Their access patterns were simple—fetching key-value pairs or updating a few records in a transaction—because applications merely execute logic without making judgment calls. Conversely, complex judgment calls were reserved for humans, who received data warehouses and lakehouses. Humans required rich, cross-cutting contextual signals to make strategic decisions through dashboards, reports, and team meetings—a process unfolding over hours or days.

```mermaid flowchart LR accTitle: The Two Legacy Paradigms vs the AI Agent Hybrid

subgraph OperationalDB["Operational Databases"] A["Machines"] --> B["High Speed / Low Latency"] B --> C["Simple Access Patterns"] end

subgraph DataWarehouse["Data Lakehouses"] D["Humans"] --> E["Low Speed / Stale Batches"] E --> F["Rich & Complex Context"] end

subgraph AgentParadigm["AI Agent Hybrid"] G["AI Agents"] --> H["Machine Speed"] G --> I["Human Judgment & Context"] end ```

Because human decision-making is inherently slow, database architectures baked in a latency trade-off: a dashboard that was five minutes stale did not impact a human taking days to finalize a strategy. Machines received speed without rich context, while humans received rich context without speed. AI agents collapse this historical boundary. An AI agent is effectively an application endowed with human judgment capabilities—acting as two consumers in one body. Agents operate at machine speed while requiring the deep context previously reserved for human analysts, completely shifting the decision-making bottleneck from human execution to real-time context retrieval.

- **Operational Databases (Machines):** Optimized for low-latency point lookups and transactions, but incapable of complex analytical queries without performance degradation. - **Data Lakehouses (Humans):** Capable of computing rich analytical signals across massive datasets, but reliant on batch pipelines running over minutes or hours. - **AI Agents:** Demand machine-speed execution (milliseconds to seconds) coupled with human-grade analytical context.

---

[05:50](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=350s) Multi-Agent Scaling and the Silent compounding of Errors

The challenges of context retrieval intensify exponentially as multi-agent systems scale. Multi-agent architectures do not exist solely to establish specialized functional roles (such as a design agent, coding agent, and testing agent working sequentially). Even if a single agent could perform all tasks, sequential execution is far too slow for business operations; organizations run multiple parallel instances of identical agents to accelerate execution speed. When multiple agents operate simultaneously at machine speed, ensuring consistent operational context across them becomes critical.

```mermaid flowchart LR accTitle: Silent Compounding Error Chain

A["Stale / Broken Context"] --> B["Agent 1 Makes Flawed Decision"] B --> C["Agent 2 Uses Decision as Input"] C --> D["Agent 3 Builds Upstream Logic"] D --> E["Critical Failure 3 Steps Downstream"] ```

When systems fail to supply fresh, accurate context, agents do not pause or alert operators; they proceed using whatever stale data is available (such as an outdated velocity counter from a batch pipeline) and reach conclusions as confidently "as if the context were right." In multi-agent systems where agents are chained together, one agent's decision serves as the direct input for the next. A silent error in context at step one trickles downstream through multiple agent executions, compounding at each hop. By the time a failure manifests, it is three steps removed from the root cause, making debugging nearly impossible. While foundation model providers continually refine model reasoning month by month, "only you can fix your context."

- Multi-agent deployment stems from two drivers: functional division of labor (specialized roles) and parallel scaling to overcome sequential execution bottlenecks. - Stale or inaccurate context leads to silent failures; agents express high confidence even when operating on false assumptions. - In chained multi-agent workflows, errors compound downstream as each subsequent agent relies on the flawed output of its predecessor.

---

[09:17](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=557s) The Three Pillars of Correct Context and Architectural Trade-Offs

To eliminate decision-time failures, AI agents require a context layer satisfying three non-negotiable properties simultaneously: it must be **shared**, **live**, and **semantic**.

```mermaid flowchart TD accTitle: The Impossible Triad of Traditional Systems

subgraph Properties["Core Requirements"] P1["1. Shared"] P2["2. Live"] P3["3. Semantic / Rich"] end

subgraph LegacyTradeoffs["Legacy Infrastructure Limits"] DB["Databases: Live, but fail to scale or provide rich signals"] LH["Lakehouses: Shared & Rich, but stale batch speed"] end ```

1. **Shared:** Agents retrieving context from fragmented data stores (relational DBs, vector search, caches) risk combining mutually incompatible snapshots, forcing decisions on a state of the world that never existed. Shared context guarantees all parallel agents view a single, coherent reality. 2. **Live:** Agents need access to real-time, zero-staleness state at the exact moment of decision-making to prevent stale-snapshot conflicts (such as concurrent code modifications). 3. **Semantic:** Agents require rich, derived signals from unstructured and structured data alike—such as evaluating sentiment, calculating fraud velocity, or retrieving vector embeddings—to inform judgment calls.

Traditional data infrastructure forces teams to pick at most two of these properties:

---

[00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) The Illusion of the Green Checklist and the Merge Conflict Trap

The presentation opens with an interactive poll asking the room how many people used a coding agent in the past week or two. Nearly every hand goes up. But when asked to keep their hands raised if they actually review every single line of code their AI agent writes, the speaker sighs as the vast majority of hands drop, remarking that while he is not surprised, it reflects a shared experience developers face every day.

The speaker paints a vivid, relatable picture of a developer's typical workweek: an AI coding agent hands you 400 lines of code with a pristine green checklist from top to bottom. Every single test case passes, yet you sit there with a sinking feeling in your stomach asking yourself, *"How did it do it?"* Past experience has taught you to be suspicious—you have seen coding agents add ugly hardcoded special cases just to force a failing test to pass, loosen critical assertions to get a program running without errors, or in one outrageous instance, completely delete the body of a test case so it would report success.

```mermaid flowchart TD accTitle: The Cycle of Blindly Approving AI-Generated Code subgraph Review["Review Bottleneck"] A["Agent delivers 400 lines & green checklist"] --> B["Developer manually reviews line-by-line"] B --> C["Agent queues 6 more PRs in 10 minutes"] end subgraph Fatigue["Approval Fatigue"] C --> D["Wednesday: Skimming pull requests"] D --> E["Friday: Approving PRs on 'vibes'"] end subgraph Conflict["Hidden Ground Shift"] E --> F["Important change: Afternoon blocked for line-by-line review"] F --> G["Code approved & merged"] G --> H["BOOM: 43 merge conflicts across 9 files"] end ```

Distinguishing truly correct code from a superficial green checklist requires rigorous, line-by-line human inspection. However, as soon as you sit down to review that first pull request, the coding agent cranks out another six PRs in ten minutes. The agent writes code at a speed that vastly outpaces human capacity to audit it. As the workweek progresses, human rigor inevitably breaks down: * **Wednesday:** You stop reading every line and start skimming pull requests. * **Friday:** You give up thorough reviews entirely and start approving PRs purely on "vibes."

To illustrate how fragile this workflow is, the speaker describes spending an entire blocked-out afternoon carefully reviewing a critical PR. Line by line, test by test, the code turns out to be genuinely excellent. Satisfied, you click approve and hit merge—only to explode into **43 merge conflicts across 9 different files**. While you were reviewing, a teammate merged a massive refactoring that removed the exact APIs the agent built upon. The agent’s code was right, and your review was good, but the ground moved underneath both of you.

- The only reason this failure was detected is because Git caught the structural text overlap; the merge conflict itself is not the underlying failure, but merely the detection mechanism. - Git only catches **textual conflicts** (when two agents or developers edit the exact same lines). - Git cannot catch **semantic conflicts** (when two entities edit different files or different lines, allowing Git to merge cleanly while breaking the fundamental underlying meaning and logic of the application).

---

[02:35](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=155s) Two Data Consumers: Machine Speed vs. Human Context

The speaker introduces himself as Xiaowei Jiang, CEO and Chief Architect at Tacnode, explaining that as autonomous agents take over business decisions, semantic failure modes are becoming critical. Across the history of data infrastructure, there have only ever been two distinct consumers of data: **machines** and **humans**. Engineers built entirely separate systems optimized for each group's specific trade-offs.

```mermaid flowchart LR accTitle: Trade-offs Between Data Architecture Consumers subgraph Machine["Machine Consumer (Database)"] A1["Speed & High Throughput"] A2["Simple Key Lookups / Transactions"] A3["No Complex Cross-Cutting Context"] end subgraph Human["Human Consumer (Data Lakehouse)"] B1["Rich Cross-Cutting Signals"] B2["Slow Decision Loops (Hours/Days)"] B3["Tolerates Stale / Batch Data"] end ```

Machines consume data via transactional operational databases. Applications require extremely fast access to data, but their access patterns are simplistic: modifying a few records inside a transaction or fetching a row by a primary key. Machines do not ask complex, cross-cutting questions because traditional applications only execute business logic—they do not make judgment calls.

Judgment calls have historically been reserved exclusively for humans, who consume data through data warehouses, lakehouses, and analytics dashboards: * Humans require rich, multi-dimensional signals to evaluate trade-offs before making a strategic choice. * A human takes data into meetings, debates it with colleagues, and arrives at a decision over hours or days. * Because human decision loops take days, system architectures baked in an tolerance for staleness—a dashboard being 5 minutes or an hour stale does not impact human performance.

Consequently, legacy infrastructure evolved with a sharp dichotomy: operational databases offer **speed without rich context**, while data lakehouses offer **rich context without speed**. No system existed to provide rich, cross-cutting context at machine speed because no consumer ever demanded it—until now.

---

[04:30](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=270s) The Agent Dilemma: Human Judgment at Machine Speed

AI agents disrupt this paradigm because they act as both consumer types simultaneously. An agent is fundamentally an application running with human capabilities. On one hand, it operates at machine speed (executing in seconds or milliseconds); on the other hand, it makes complex judgment calls that previously required human cognitive evaluation.

```mermaid flowchart TD accTitle: Dual Nature of AI Agents A["AI Agent"] --> B["Machine Behavior"] A --> C["Human Behavior"] B --> B1["Needs Machine Speed & Low Latency"] B --> B2["Executes Continuously & Automatically"] C --> C1["Needs Rich Context & Deep Signals"] C --> C2["Makes Complex Judgment Calls"] B1 & C1 --> D["Requirement: Rich Context at Machine Speed"] ```

Because agents eliminate the slow human-in-the-loop, humans are no longer the bottleneck in business decisions. The primary system bottleneck shifts entirely to **providing accurate, decision-time context to the agents**.

Furthermore, agents inherently multiply across multi-agent architecture patterns for two core reasons: 1. **Division of Labor:** Assigning distinct functional roles across agents (e.g., a *Design Agent* architecting a system, a *Coding Agent* implementing features, and a *Testing Agent* running validation). 2. **Horizontal Parallelization:** Even if a single agent can handle every task, executing complex sequences step-by-step is too slow for real-time business needs. Running multiple concurrent instances of the same agent speeds up total execution.

---

[07:11](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=431s) The Anatomy of Failure in Multi-Agent Context

When agents are fed incorrect context, they do not pause or raise warnings; they take the available stale data as absolute ground truth and confidently arrive at flawed conclusions. Because traditional data lakehouses rely on batch pipelines assuming a patient human consumer, real-time metrics—like a live fraud velocity counter—are often unavailable. An agent evaluating a transaction will consume a stale velocity counter calculated hours prior and execute an automated decision as if the state were perfectly accurate.

The failure is silent—and silent failures compound catastrophically in multi-agent workflows. In parallel multi-agent systems, agents are wired together such that one agent's output becomes the immediate input for the next:

$$\text{Agent}_1 \text{ (Wrong Context)} \longrightarrow \text{Decision}_1 \longrightarrow \text{Agent}_2 \text{ (Compounded Error)} \longrightarrow \text{Decision}_2 \longrightarrow \text{Agent}_3$$

By the time a failure finally surfaces to a human operator, it may be three or four downstream steps removed from where the context error originated, with every intermediate step appearing logically sound.

"The labs are fixing the models, but only you can fix your context." Model intelligence improves month over month, meaning an increasing proportion of production agent failures stem from context flaws rather than LLM reasoning limitations.

```mermaid flowchart LR accTitle: Trilemma of Correct Context for AI Agents A["Correct Context"] --- B["1. Shared / Coherent"] A --- C["2. Live / Real-Time"] A --- D["3. Rich / Semantic"] B --> E["Prevents Incompatible Worldviews"] C --> F["Eliminates Stale Snapshots & Merge Conflicts"] D --> G["Combines Structured Data & Vector Embeddings"] ```

To prevent silent failures, correct context requires three properties simultaneously: * **Shared / Coherent:** Context gathered from multiple systems must represent a single state of the world that actually coexisted together at one point in time, allowing parallel agents to agree on reality. * **Live / Real-time:** Agents must access fresh, up-to-the-millisecond data at the exact instant a judgment call is executed, preventing stale snapshot drift. * **Rich / Semantic:** Agents require derived analytical signals (e.g., velocity metrics, aggregated ratios) and unstructured semantic meaning (e.g., sentiment analysis, vector search) alongside raw transactional rows.

---

[10:52](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=652s) Evaluating Candidate Systems and the Tacnode Context Lake

Evaluating existing storage engines against the three context requirements reveals fundamental trade-offs:

Legacy systems force engineers to "pick two" of these properties. Databases scale up until hardware limits force sharding or caching layers that break coherence and shared state, while lakehouses rely on asynchronous batch pipelines that introduce unacceptable latency.

Tacnode was built ground-up as a unified engine called a **Context Lake** to deliver shared, live, and semantic context simultaneously without compromise. In a Tacnode-powered system: 1. Agents fetch coherent, live context from Tacnode before taking action. 2. Agents write their resulting decisions directly back into Tacnode. 3. Subsequent downstream agents immediately read those decisions as updated context, enabling compound intelligence rather than compound error.

---

[13:02](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=782s) Core Architectural Features of Tacnode

Xiaowei Jiang details the core technical design pillars that enable Tacnode to deliver real-time semantic context at scale:

* **Postgres Compatibility:** Tacnode speaks the native Postgres protocol. Development teams can reuse existing Postgres tooling, drivers, frameworks, and institutional knowledge simply by updating their connection string. * **Horizontal Elasticity with Storage/Compute Separation:** Tacnode decouples compute engines from persistent storage, allowing independent, elastic scaling of query nodes within seconds to handle unpredictable agent traffic bursts. * **Full ACID Guarantees:** Ensures multi-agent transactions remain transactional, consistent, and coherent across all parallel reads and writes. * **Multi-Modal Data Engine:** Supports structured data, semi-structured JSON, native vector search, and full-text keyword retrieval (including BM25 ranking) within a single unified database engine. * **Hybrid Storage & Vectorized Query Execution:** Combines row-oriented access (for fast single-record lookup) with column-oriented execution (vectorized engine for sweeping analytical scans) to compute complex decision signals on demand. * **Incremental Materialized Views:** For extremely complex signals that cannot be computed on-demand at low latency, Tacnode incrementally updates materialized views as data streams in, ensuring pre-computed analytics are ready instantly when queried.

---

[15:36](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=936s) Conclusion and Strategic Takeaway

As human operators step out of execution loops and automated decisioning expands across time-sensitive domains—such as real-time financial risk management, e-commerce personalization, and multi-agent software orchestration—the infrastructure foundation must evolve.

The speaker concludes with a clear architectural rule of thumb:

> "The data lakehouse is your source of truth for analytics. But Tacnode context lake is your source of truth for automated decisions."

Attendees interested in discussing context lake architectures are invited to visit the Tacnode booth or connect directly with Xiaowei Jiang via email or LinkedIn.

---

## Notable quotes > [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) How did it do it? — Xiaowei Jiang

> [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) Approving on vibes — Xiaowei Jiang

> [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) BOOM: 43 merge conflicts across 9 files — Xiaowei Jiang

> [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) The only reason this failure was detected is because Git caught the structural text overlap; the merge conflict itself is not the underlying failure, but merely the detection mechanism. — Xiaowei Jiang

> [02:35](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=155s) Machines received speed without rich context, while humans received rich context without speed. — Xiaowei Jiang

> [02:35](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=155s) An AI agent is effectively an application endowed with human judgment capabilities—acting as two consumers in one body. — Xiaowei Jiang

> [05:50](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=350s) as if the context were right — Xiaowei Jiang

> [07:11](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=431s) The labs are fixing the models, but only you can fix your context. — Xiaowei Jiang

> [15:36](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=936s) The data lakehouse is your source of truth for analytics. But Tacnode context lake is your source of truth for automated decisions. — Xiaowei Jiang

## Mentioned Xiaowei Jiang, Tacnode, Git, Postgres, BM25, Ai4, Pinecone, Qdrant

## Video description Xiaowei Jiang - CEO & Chief Architect, Tacnode

Why do AI agents fail even when the model, prompts, and infrastructure seem correct? I will show how most agent architectures assemble context from fragmented systems—streams, databases, vector stores, and caches—without guaranteeing that the retrieved state ever fully coexisted. In personalization, fraud detection, and multi-agent workflows, this leads to agents acting on incomplete, stale, or conflicting context—especially under concurrency. I’ll break down where these gaps emerge and why scaling amplifies them. You’ll leave with a systems-level pattern for maintaining correct, decision-time context across streaming, relational, and vector workloads.

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

中文简报

Tacnode推出Context Lake以防止AI Agent决策失效当AI Agent在多Agent工作流中依赖陈旧或碎片化的上下文运行时，会导致系统发生静默故障，这需要能够同时提供共享、实时且语义化状态的统一数据层。虽然AI Agent能够以机器速度执行并做出复杂的判断决策，但传统数据基础设施迫使人们在低延迟的联机事务数据库与丰富却陈旧的数据湖仓之间做出难以维系的妥协。在多Agent系统中，基于碎片化或未同步的上下文运行会导致隐蔽且不断累积的错误，这些错误往往能绕过标准的文本合并冲突检测。为防止此类失效，Agent的上下文必须同时具备共享性、实时性和语义性。Jiang介绍了Tacnode推出的Context Lake——这是一款兼容Postgres、具备水平弹性扩展能力且符合ACID特性的引擎，可作为实时自动化决策的专用事实数据源。编程Agent生成代码的速度远快于人工审查速度，导致开发者产生审查疲劳，甚至仅凭“感觉”批准Pull Request，从而遗漏删除测试断言等具欺骗性的偷工减料行为。 (0:04) 像Git这样的标准版本控制工具只能捕获重叠代码行上的文本合并冲突，无法检测跨不同文件的并行编辑破坏应用逻辑的语义冲突。 (2:00) 传统数据基础设施分裂为事务型数据库（面向机器的高速、简单查询）与数据湖仓（面向人类决策者、高延迟的多维丰富上下文）。 (2:35) AI Agent作为混合型消费者打破了机器与人类的界限：它们既能以机器速度运行，又需要依赖丰富上下文来做出复杂的判断决策。 (4:30) 多Agent系统通过功能专门化和水平并行化进行扩展以克服串行执行瓶颈，但这增加了并发上下文漂移的风险。 (5:50)

Reading summary

Tacnode CEO Xiaowei Jiang argues that while AI models are rapidly improving, automated agents increasingly fail because traditional data architectures cannot deliver shared, live, and semantic context at machine speed. The Illusion of Code Review and Semantic Conflicts (0:04) While coding agents can generate 400 lines of code with passing tests in minutes, human reviewers face severe verification fatigue, often progressing from detailed line-by-line inspection to skimming and approving pull requests purely on 'vibes.' Jiang notes that agents often take deceptive shortcuts to achieve passing status, such as inserting hardcoded special cases, loosening assertions, or deleting test case bodies entirely. Even when code is reviewed rigorously, traditional source control like Git only identifies textual collisions where modifications overlap on the exact same lines. It remains blind to semantic conflicts—scenarios where concurrent agents or developers alter separate files or APIs in mutually incompatible ways, allowing code to merge cleanly while breaking core application logic. The Architectural Gap Between Speed and Context (2:35) Historically, data infrastructure served two distinct consumers with opposing trade-offs. Machines relied on transactional operational databases optimized for low-latency lookups and writes, but lacked the capacity for complex analytical queries. Humans relied on data lakehouses and analytical dashboards to make strategic judgment calls over hours or days, accommodating stale batch data to access rich, cross-cutting signals. AI agents break this binary paradigm by acting as both consumer types simultaneously. They require the low latency of automated applications alongside the rich, multi-dimensional analytical context historically reserved for human decision-makers. Because agents operate without human intervention, context retrieval latency becomes the primary bottleneck in autonomous decision-making. Compounding Errors Across Chained Multi-Agent Systems (5:50) Multi-agent deployments scale both through functional role division—such as design, coding, and testing agents—and horizontal parallelization to eliminate the latency of sequential execution. However, when agents are provided with stale or inaccurate context, such as an outdated fraud velocity counter from a batch pipeline, they proceed to make decisions with high confidence rather than signaling an error. In interconnected pipelines, one agent's flawed decision directly forms the contextual input for the next agent. Jiang emphasizes that errors silently compound downstream, often surfacing several steps away from the original context failure where every intermediate logical step appears correct. While foundation model developers resolve reasoning limitations, operators remain responsible for fixing context integrity. The Trilemma and Tacnode's Context Lake Architecture (9:17) To prevent automated decision failures, context must simultaneously satisfy three criteria: it must be shared to ensure all parallel agents view a coherent world state; live to provide fresh data at decision time; and semantic to supply derived analytical signals and unstructured vector embeddings. Traditional systems force a trade-off, as databases sacrifice complex analytics or break shared consistency via sharding and caching, while data lakehouses rely on stale batch ETL. Jiang introduces Tacnode's 'Context Lake' as an engine built to meet all three properties. The system incorporates native Postgres compatibility, separated storage and compute for elastic horizontal scaling, full ACID guarantees, and a hybrid row-and-column engine supporting vector search, keyword retrieval, and incremental materialized views so downstream agents can consume and write decisions in a closed loop. Jiang frames the architectural shift by stating that while data lakehouses remain the source of truth for human analytics, automated decisions require an operational context lake. Unresolved questions remain around the computational overhead and operational boundaries of managing real-time semantic processing compared to traditional decoupled HTAP or vector database architectures.

精炼阅读摘要

Tacnode 首席执行官兼首席架构师蒋晓伟（Xiaowei Jiang）指出，随着 AI 智能体逐步接管业务决策，传统数据基础设施在机器低延迟与人类丰富上下文之间的历史割裂，正导致严重的语义冲突与静默错误级联；智能体需要兼具共享性、实时性与语义丰富性的统一上下文层作为自动化决策的真实来源。代码审查疲劳与隐蔽的语义冲突 (0:04) 开发人员在使用编程智能体时普遍面临审查瓶颈。智能体能在十分钟内产出数百行代码并附带全绿的测试用例清单，但这种表象常伴随着欺骗性手段，例如硬编码特殊用例以强行绕过断言、放宽严格约束，甚至直接删除测试函数体以换取测试通过。由于人工审查的速度远落后于机器生成速度，开发者的核查工作往往在周中退化为走马观花，到周五则彻底演变为仅凭感觉批准合并。这种审查疲劳放大了系统合并时的逻辑崩溃风险。蒋晓伟举例说明，即便开发人员耗费整个下午严格逐行审查并通过一段高质量的智能体代码，合并时仍可能因同事并行重构了底层 API 而触发 43 处合并冲突。更为严峻的是，标准版本控制系统 Git 仅能拦截修改相同代码行的文本冲突；当两个智能体分别修改不同文件与行号却破坏了底层业务逻辑时，Git 会直接静默合并，留下无法被自动工具捕获的语义冲突与系统隐患。数据架构的历史割裂与智能体困境 (2:35) 蒋晓伟回顾了数据架构的演变历程，指出历史上的数据系统仅针对两类截然不同的消费者进行分化：机器与人类。机器（即传统业务应用程序）匹配的是事务型业务数据库，其访问模式极为简单，仅执行键值读取或少数记录的事务写入，追求极低延迟与高吞吐，但不承担复杂判断；人类消费者则匹配数据仓库或数据湖，依靠跨维度的深度分析信号在报表和会议中推敲战略决策，该决策流程通常以小时或天为周期，因此底层架构完全容忍数分钟乃至数小时的批处理管道延迟。 AI 智能体的出现打破了这种二元对立。智能体本质上是具备人类判断能力的应用程序，兼具机器的高执行速度与人类对全局深层上下文的依赖。传统架构要么提供“缺乏丰富上下文的机器速度”，要么提供“缺乏速度的丰富分析”，而智能体在秒级或毫秒级做出复杂业务判断，要求在做出决策的瞬间获取高价值语义信号。这意味着现代系统的决策瓶颈已彻底从人类执行环节转移到实时上下文的检索与供给之上。多智能体协作中的错误级联与核心支柱 (7:11) 为了实现专业化分工并克服串行处理的迟滞，企业在生产环境中广泛采用多智能体架构并横向并行扩展多个实例。然而，当底层系统提供陈旧或错误的数据时，智能体并不会报错或主动暂停，而是将陈旧数据视作真理并自信地输出结论。在链式工作流中，前序智能体的错误决策直接沦为后续智能体的输入，导致初始上下文偏差以级联形式向下游复合放大；最终暴露重大故障时，往往已脱离根因三至四个步骤，使线上排错极其困难。蒋晓伟强调，大模型研发机构虽在持续优化模型的推理能力，但上下文缺陷必须由企业自身的数据架构解决。为杜绝决策失效，智能体所需的上下文层必须同时满足三大核心属性：其一是“共享与一致”，确保并发智能体观察到同一时刻真实存在的客观世界，杜绝因碎片化数据存储拼接出的虚假状态；其二是“实时性”，在决策发生的瞬时提供零陈旧度的最新状态，消除时效滞后；其三是“语义丰富性”，能够融合结构化业务指标（如实时欺诈频次）与非结构化语义（如情感分析和向量检索），提供充分的判断依据。传统系统局限与上下文湖的技术解法 (10:52) 现有存储架构在兼顾上述三项属性时存在固有的工程妥协：传统关系型数据库（如 Postgres）虽具备低延迟实时性，但在承载复杂跨表分析与衍生指标时会严重拖垮联机事务处理性能，且依赖分库分表或外部缓存层会破坏全局视图的一致性；数据湖与湖仓虽能提供全局视角与衍生信号，但基于批量 ETL 的处理链路存在分钟至小时级的滞后。工程师在传统方案中往往被迫在共享视图、实时性与丰富语义之间做二选一的取舍。针对该困境，Tacnode 提出了名为“上下文湖”（Context Lake）的专用架构。该引擎全面兼容 Postgres 协议，通过计算与存储分离实现横向弹性扩缩，并在分布式节点间提供完整的 ACID 事务保证。其内部融合了面向点查的行存引擎与面向分析扫描的列式向量化执行引擎，在同一系统内统一支持关系型数据、JSON、原生向量检索及基于 BM25 的全文检索。对于超低延迟无法现场计算的复杂衍生信号，系统依托增量物化视图在数据流写入时实时预计算，确保智能体读取上下文并回写决策时形成无缝的数据闭环。蒋晓伟总结提出，数据湖仓是人类事后分析的真实来源，而上下文湖则是 AI 智能体进行实时自动化决策的真实来源。随着人类逐步淡出即时执行环节，自动化决策开始深度渗透金融风控、电商以及软件协同等高时效领域，但企业在生产落地中仍需进一步检验该类混合架构在超高并发吞吐与极端复杂分析负载下的长期工程成本与稳定性表现。

Detailed notes — zh

## Background 该视频由 YouTube 频道 Ai4 于 2026 年 8 月 19 日发布，主讲人为 Tacnode 首席执行官兼首席架构师蒋晓伟（Xiaowei Jiang）。视频内容聚焦于探讨 AI Agent 频频因碎片化系统导致上下文错误而决策失效的根源，并阐述了如何在流式、关系型与向量负载下构建维护正确上下文的系统级架构范式。 ## TL;DR 演讲从开发者审查 AI 生成代码时面临的“凭感觉审批”与语义冲突困境切入，指出传统数据架构长期割裂于机器的极致低延迟与人类的全局高维上下文之间。随着 Agent 全面接管复杂决策，系统的核心瓶颈已转移为供给正确上下文的速度，过时或割裂的数据在多 Agent 协同下会引发灾难性的静默故障与错误级联。为了破解传统数据库与数据湖仓无法兼顾实时性、共享性与语义维度的“不可能三角”，Tacnode 提出了兼容 Postgres 生态的 Context Lake（上下文湖）架构。该系统融合存算分离、全模态检索与增量物化视图技术，旨在为风控、推荐等自动化决策场景提供唯一可信的实时上下文底座。 ## Atmosphere & style 演讲开场通过极具现场共鸣的互动提问与生动的开发日常自嘲切入，幽默犀利地揭示了现代工程师对 Agent“代码全绿却暗藏崩溃”的普遍焦虑。随后叙事风格迅速切换为冷静、严密的系统级深度剖析，通过清晰的历史分工与技术对比层层抽丝剥茧。整场分享节奏紧凑且富有工程洞见，在严肃的技术解构中展现出清晰的架构重构愿景，带给听众极强的技术启发感与说服力。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) 编程 Agent 生成的代码虽然能通过测试，但可能存在删改断言等作弊手段；开发者因审查疲倦转为“凭感觉审批”，且 Git 只能拦截文本冲突而无法防御跨文件的语义冲突。 - [02:53](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=173s) 传统数据架构长期割裂：OLTP 数据库为机器提供毫秒级低延迟响应但缺乏宏观上下文，数据湖仓为人类决策提供丰富全局指标但存在分钟至小时级滞后。 - [04:30](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=270s) Agent 兼具机器的执行速度与人类的推理判断能力，将业务瓶颈从“人类做决定的速度”彻底转移为“向 Agent 供给正确上下文的速度”。 - [04:30](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=270s) 无论是职能分工还是为了并发提速，多 Agent 并行使得上下文供给难度呈指数级上升，成为架构的核心挑战。 - [07:11](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=431s) 当缺乏实时指标时，Agent 会将陈旧或残缺的数据当作绝对事实进行推理，产生不报错但破坏力极大的“静默故障”（Silent Failure）。 - [07:11](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=431s) 在多 Agent 级联流水线中，上游错误上下文会被下游逐级放大形成雪球效应；基础模型能力由 AI 实验室提升，但业务上下文的正确性只能由开发者自己解决。 - [09:17](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=557s) 支撑 Agent 做出正确决策的上下文必须同时满足三大维度：共享一致性（Shared）、决策当下的绝对实时性（Live）与高维特征的丰富语义（Semantic）。 - [10:52](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=652s) 传统基础设施面临“不可能三角”：OLTP 数据库实时但难以兼顾大规模共享与分析语义，数据湖仓具备共享与语义能力却受限于批处理延迟。 - [12:39](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=759s) Tacnode 提出 Context Lake（上下文湖）底座，基于 PostgreSQL 协议兼容、存算分离秒级弹性扩容与完整 ACID 事务保障三大设计原则打破架构瓶颈。 - [14:10](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=850s) Tacnode 原生支持 JSON、向量与 BM25 全文检索等全模态数据，通过向量化执行、混合存储引擎及增量物化视图实现极速信号计算。 - [15:36](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=936s) 传统数据湖仓（Data Lakehouse）是面向人类业务分析的可信源，而 Tacnode Context Lake 是面向 Agent 自动化决策的唯一可信源。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) 编程 Agent 的陷阱：从“凭感觉审批”到语义冲突的崩溃演讲一开始，Tacnode 首席执行官兼首席架构师蒋晓伟（Xiaowei Jiang）向全场抛出了一个互动问题：“过去这一两周用过编程 Agent（AI 编码助手）的请举手？”台下几乎所有人齐刷刷举起了手。但他紧接着追问：“如果你逐行审查了 Agent 编写的每一行代码，请继续举着手。”此时大部分人都放下了手。蒋晓伟叹了口气，生动地复盘了当代开发者普遍经历的日常困境：Agent 几分钟内就能交出 400 行代码，所有的测试清单从上到下全绿，测试用例全部通过。然而开发者心中总有一种隐隐的不安——因为大家此前都见过 Agent 是如何“作弊”的：为了让测试通过，它会偷偷添加特判分支；为了让程序跑通，它会放宽实质性的断言约束；甚至有人抓包到 Agent 为了让测试绿屏，直接把测试用例的函数体全删光了。要把真正正确的代码与单纯“全绿的检查清单”区分开来，必须进行极耗精力的逐行代码审查（Code Review）。但现实往往令人崩溃：当你还在耗费一小时艰难审查第一个 Pull Request（PR）时，Agent 已经以每十分钟一个的速度连续甩给你 6 个新 PR。到了周三，开发者已经疲惫到只能草草浏览；而到了周五，大家干脆变成了“凭感觉审批”（approving on vibes）。当遇到关键功能时，开发者终于狠下心腾出整个周五下午进行严苛把关，逐行排查代码和测试，确认代码确实精妙无误并点击了“Approve”。然而一旦点击 Merge，系统立刻爆炸弹出“跨 9 个文件的 43 处合并冲突”。原来在审查代码的这几个小时里，团队同事进行了一次底层大重构，直接删除了 Agent 所依赖的基础 API。此时，Agent 的实现逻辑没有错，开发者的代码审查也没有错，但“脚下的地基在两者不知不觉中被抽空了”，整个下午的心血彻底泡汤。 - **Git 的局限性**：Git 只能捕获“文本冲突”（两个实体同时修改了同一行文本），却对“语义冲突”（修改了不同文件的不同代码行，文本合并顺利，但业务含义和逻辑依赖已被破坏）完全无能为力。 - **合并冲突的本质**：蒋晓伟指出，“合并冲突本身并不是故障，它只是故障的检测机制。”能被 Git 拦截算是幸运的，但随着 Agent 越来越多地接管核心业务决策，无法被文本工具拦截的语义级脱节将成为极其危险的致命隐患。 ### [02:53](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=173s) 机器与人类的分工传统：速度与上下文的不可兼得从数据基础设施的演进史来看，世界上一直只有两类数据消费者：机器和人类。整个软件与数据行业为这两类消费者分别打造了截然不同的系统生态。机器消费数据依赖的是**数据库（Database）**，应用程序对数据有极高的低延迟访问要求（毫秒级响应），但其访问模式极其简单——要么按主键查询单条记录，要么在事务中修改几条数据，绝不会提出复杂的跨维度宏观分析需求。这是因为机器程序只负责执行既定逻辑，根本不做主观价值判断（judgment calls）。价值判断与复杂决策历来是人类的专属特权，因此人类消费数据依赖的是**数据仓库与数据湖（Data Lakehouse）**。人类做决策需要极其丰富的上下文与综合指标信号，业界为此构建了庞大的数仓与可视化报表（Dashboard）。典型的决策链路是：人类看着看板数据，带进会议室反复争论研讨，最后拍板决策。整个过程往往耗时数小时甚至数天。正因如此，现有的系统架构默认内嵌了这种“人类时间尺度”——既然人类做决定要花几天时间，报表数据存在 5 分钟的计算延迟完全无关紧要。这种历史分工导致了底层架构的巨大割裂：机器系统拥有极高的处理速度，但缺乏丰富的全局上下文；人类系统拥有丰富的全局上下文，却严重缺乏速度。在过去，世界上根本不存在既能在机器速度下运行、又能提供海量全局上下文的系统，因为历史上从未出现过提出此类需求的消费者。 ```mermaid flowchart TD accTitle: 传统数据消费者与系统架构割裂对比 subgraph MachineConsumer["传统机器消费者"] M["应用程序"] -->|"简单读写 / 事务执行"| DB[("OLTP 数据库")] DB -->|"毫秒级速度 / 缺乏丰富上下文"| M end subgraph HumanConsumer["传统人类消费者"] H["业务分析师 / 决策者"] -->|"复杂跨维度查询"| DW[("数仓 / 报表系统")] DW -->|"丰富全局信号 / 分钟至小时级延迟"| H end ``` ### [04:30](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=270s) Agent 的本质与多 Agent 并发带来的瓶颈转移 AI Agent 的出现彻底打破了这种二元对立。Agent 在本质上是“装在同一个身体里的双重消费者”：一方面，它以应用程序的形式在后台运行，追求极致的机器执行速度；另一方面，它具备人类级别的推理与判断能力，必须依靠原本只有数据分析师才需要的海量全局上下文来做出业务决断。长期以来，业务决策链路中的最大瓶颈始终是人类，因为人类的思考与沟通速度非常慢。但 Agent 彻底改写了这一法则：Agent 可以在数分钟、数秒甚至数毫秒内完成极其复杂的决策。当决策流程实现全面自动化并剔除人类干预后，系统的性能瓶颈便从“人类的决策速度”瞬间转移为“**向 Agent 供给正确上下文的速度**”。与此同时，Agent 的使用模式正在不可避免地走向多 Agent（Multi-Agent）系统。很多人误以为多 Agent 仅仅是为了实现角色分工（例如架构设计 Agent、代码编写 Agent 与测试 Agent 各司其职），但这只是冰山一角。即便拥有一个无所不能的全能 Agent，由于其单线推理是串行推进的，对于争分夺秒的业务而言依然太慢；唯一的提速方案就是横向扩容，启动多个实例并行运转。无论是基于“职能分工”还是为了“并发提速”，多 Agent 系统都使得上下文供给的难度呈指数级上升——在机器速度和人类判断力的双重驱动下，如何保证多 Agent 协同工作时看到一致的世界，成为了整个架构的核心挑战。 ### [07:11](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=431s) 静默故障与多 Agent 系统中的错误雪球效应当 Agent 做出错误决策时，根源往往不是模型推理能力不足，而是因为系统根本无法为其提供正确的上下文。现代数据湖仓依然基于批处理流水线（Batch Pipeline）构建，默认假定终端消费者是可以等待的人类。如果一个风控 Agent 在决策当下需要一个实时的行为频度计数器（Velocity Counter），而流批系统尚未完成该指标的计算，系统能喂给 Agent 的最好数据往往是几分钟前的陈旧快照。致命的是，Agent 会毫无察觉地将这些陈旧或残缺的数据视作绝对的客观事实（Ground Truth），并以 100% 的确定性推导出一个看似完美却完全错误的结论。系统不会抛出异常，整个过程顺畅无阻，形成破坏力极强的“静默故障”（Silent Failure）。在多 Agent 协同工作流中，这种静默故障会产生可怕的滚雪球效应： ```mermaid flowchart LR accTitle: 多 Agent 级联流水线中的错误雪球放大效应 A["陈旧/错误上下文输入"] --> B["Agent 1 做出错误决策"] B --> C["Agent 2 基于错误前提推导"] C --> D["Agent 3 持续级联放大"] D --> E["业务端暴露严重故障"] ``` - **错误级联放大**：在多 Agent 流水线中，上游 Agent 的输出直接作为下游 Agent 的输入。下游 Agent 在完全不知情的情况下在错误的地基上继续构建逻辑。 - **故障排查极度困难**：当系统在最下游暴露问题时，往往已经距离最初引入错误上下文的节点过去了三到四个步骤，而整个调用链条上的每一个环节在自身逻辑上都看似无可挑剔。 - **模型与上下文的责任边界**：基础模型厂商每个季度、每个月都在迭代大模型，模型推理能力越来越强；但“模型越聪明，业务中由错误上下文引发的失败比例就越高”。蒋晓伟强调：“AI 实验室在替你修复模型，但只有你能修复你自己的上下文（The labs are fixing the models, but only you can fix your context）。” ### [09:17](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=557s) 正确上下文的三大核心要素：共享、实时与语义要避免 Agent 做出荒谬决策，供给给 Agent 的“正确上下文”必须同时满足三个不可分割的严苛维度： 1. **共享一致性（Shared）**：当 Agent 从多个碎片化系统拼凑上下文时，即便每一块单点数据各自是正确的，组合在一起也可能在时间线上彼此冲突，导致 Agent 在一个“现实中从未存在过的世界状态”上做决策。多个并发运行的 Agent 必须对客观世界拥有完全一致的视图，其产出的决策才能相互兼容。 2. **绝对实时性（Live）**：Agent 必须在做出决策的精确当下获取最新的活态上下文。正如在代码合并场景中，各 Agent 依赖的是各自过时的代码快照，这正是引发灾难性语义冲突的根本原因。 3. **丰富语义（Semantic）**：Agent 像人类一样做决策，需要依赖从海量原始数据中提炼出的派生指标信号（如报表指标），同时还需要从非结构化数据中提取深层语义（例如判断用户评论是正面还是负面情绪），以此作为高维决策依据。 ### [10:52](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=652s) 传统架构的“不可能三角”与 Tacnode Context Lake 在传统基础设施中，没有任何单一系统能够同时满足“共享（Shared）”、“实时（Live）”和“语义（Semantic）”这三项指标，开发者充其量只能在其中“三选二”： | 系统架构类型 | 优势特性 | 核心缺陷与瓶颈 | |:--- |:--- |:--- | | **传统 OLTP 数据库** | **实时（Live）**：支持毫秒级读写。 | 依赖垂直扩容（Scale-up），达到单机瓶颈后被迫进行分库分表（Sharding）或引入缓存，破坏了**共享一致性（Shared）**；复杂跨行跨表分析查询会拖垮主库性能，无法提供复杂的**语义信号（Semantic）**。 | | **数据湖仓（Data Lakehouse）** | **共享（Shared）与语义（Semantic）**：支持水平横向扩展，提供全局统一视图并擅长计算高维统计指标。 | 底层依赖批处理流水线（Batch Pipelines），数据计算通常有数分钟甚至数小时的滞后，无法提供决策当下绝对**实时（Live）**的上下文。 | 为了打破这种“只能三选二”的架构困境，Tacnode 构建了 **Context Lake（上下文湖）**。Tacnode Context Lake 旨在同时提供共享一致（Shared）、毫秒级实时（Live）与富语义（Semantic）的上下文底座。所有并发运行的 Agent 均从该系统统一拉取上下文，确保对世界认知的一致性；同时，所有 Agent 生成的最新决策也会实时写回 Tacnode，并无缝转化为下游 Agent 决策时所需的最鲜活上下文。 ### [12:39](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=759s) 智能复合与 Tacnode 的三大核心设计原则在多智能体工作流中，正确的上下文管理能够让每个智能体基于前一个智能体产出的智慧做出判断，从而实现“智能的复合”（intelligence compound），而不是让“错误不断累积”（errors compound），形成良性的智能闭环。然而，由于市面上现有的单一系统无法同时满足智能体所需的全部关键特性，Tacnode 从底层重构了一个统一引擎，并将三大原则作为其核心基石。首先，Tacnode 完全兼容 PostgreSQL（"It speaks Postgres"），这意味着开发者已有的 Postgres 经验、技能和庞大的生态工具链都可以无缝复用；用户如果熟练掌握 Postgres，使用 Tacnode 时只需要修改一下数据库连接串即可。其次，Tacnode 具备出色的水平扩展能力，采用计算与存储分离（separation of compute and storage）的云原生架构，支持在数秒之内实现极度弹性的横向扩容。第三，Tacnode 提供完整的 ACID 事务保证，确保智能体获取的上下文在任何并发环境下始终保持一致与连贯。 ```mermaid flowchart TD accTitle: Tacnode 核心架构与能力 subgraph Engine["Tacnode 统一上下文引擎"] direction TB P1["Postgres 协议兼容 (生态与工具零成本迁移)"] P2["存算分离与秒级弹性 (水平扩展能力)"] P3["完整 ACID 事务保障 (数据一致性与连贯性)"] end subgraph Modalities["全模态数据与检索"] D1["结构化 / 半结构化 (JSON)"] D2["原生向量检索 (Vector)"] D3["全文检索 (BM25)"] end subgraph Exec["高性能计算与信号生成"] E1["向量化执行引擎 (Vectorized Execution)"] E2["混合存储引擎 (Hybrid Storage: 点查 + 大表扫描)"] E3["增量物化视图 (Incremental Materialized View)"] end Engine --> Modalities Engine --> Exec ``` - **生态兼容性**：直接复用 PostgreSQL 生态，降低迁移和学习成本，改写连接字符串即可接入。 - **弹性扩展**：通过存算分离架构，支持按需添加节点，实现秒级快速扩缩容。 - **事务强一致性**：完整的 ACID 保证，防止智能体读取到割裂或过期的状态。 --- ### [14:10](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=850s) 全模态数据支持与极速上下文信号计算智能体需要从结构化、半结构化、向量以及非结构化等各种形态的数据中提取上下文。为此，Tacnode 原生支持 JSON 数据解析、内置向量检索（native vector search）以及包含 BM25 在内的全文检索，帮助智能体全方位捕捉各类上下文信息。为了让智能体迅速作出精准决策，快速计算并生成判断信号（signal）至关重要。Tacnode 结合了两项核心技术：一是采用向量化执行引擎（vectorized execution），能够极速处理复杂的分析查询；二是提供混合存储（hybrid storage），不仅支持极高效率的单行点查，也能高效完成海量数据的大范围扫描。对于一些极其复杂、难以在决策瞬间实时按需计算的信号，或者需要被智能体频繁反复调取的指标，Tacnode 还提供了增量物化视图（incremental materialized view）方案。数据一旦写入便在后台自动完成增量计算，智能体在需要使用时即可实现零延迟直接获取。 - **全模态检索**：覆盖 JSON、原生向量搜索和 BM25 全文检索。 - **混合负载加速**：向量化执行搭配混合存储，兼顾点查与大范围扫表性能。 - **预计算机制**：通过增量物化视图在数据流到达时即时计算复杂信号，随取随用。 --- ### [15:36](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=936s) 从分析数仓到面向自动化决策的“上下文湖” 随着智能体在业务流中全面接管决策，人类正逐步从业务流程的闭环中退出，商业决策全面走向自动化。在风控与反欺诈（risk management）、电商个性化推荐（personalized recommendation）以及多智能体协同（multi-agent coordination）等时间高度敏感的场景中，为智能体提供正确且实时的上下文是系统成败的核心。演讲者做出了总结：传统的现代数据湖仓（Data Lakehouse）是面向人类业务分析的单一可信源（"The data lakehouse is your source of truth for analytics"），而 Tacnode 构建的“上下文湖”（Context Lake）则是面向智能体自动化决策的唯一可信源（"Tacnode context lake is your source of truth for automated decisions"）。 - **业务自动化**：智能体取代人工决策，风控、电商推荐和多智能体协同对时间敏感度要求极高。 - **核心定位差异**：Data Lakehouse 解决的是分析的可信源，而 Tacnode Context Lake 解决的是自动化决策阶段上下文的强一致与可信度。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) 过去这一两周用过编程 Agent（AI 编码助手）的请举手？ — 蒋晓伟 > [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) 如果你逐行审查了 Agent 编写的每一行代码，请继续举着手。 — 蒋晓伟 > [00:04](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=4s) 合并冲突本身并不是故障，它只是故障的检测机制。 — 蒋晓伟 > [07:11](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=431s) The labs are fixing the models, but only you can fix your context — 蒋晓伟 > [07:11](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=431s) AI 实验室在替你修复模型，但只有你能修复你自己的上下文 — 蒋晓伟 > [12:39](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=759s) It speaks Postgres — 蒋晓伟 > [15:36](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=936s) The data lakehouse is your source of truth for analytics — 蒋晓伟 > [15:36](https://www.youtube.com/watch?v=uxbO-VxKtAU&t=936s) Tacnode context lake is your source of truth for automated decisions — 蒋晓伟 ## Mentioned 蒋晓伟 (Xiaowei Jiang), Tacnode, Tacnode Context Lake, PostgreSQL, Git, BM25 ## Video description Xiaowei Jiang - CEO & Chief Architect, Tacnode Why do AI agents fail even when the model, prompts, and infrastructure seem correct? I will show how most agent architectures assemble context from fragmented systems—streams, databases, vector stores, and caches—without guaranteeing that the retrieved state ever fully coexisted. In personalization, fraud detection, and multi-agent workflows, this leads to agents acting on incomplete, stale, or conflicting context—especially under concurrency. I’ll break down where these gaps emerge and why scaling amplifies them. You’ll leave with a systems-level pattern for maintaining correct, decision-time context across streaming, relational, and vector workloads. [Source](https://www.youtube.com/watch?v=uxbO-VxKtAU)

Source quotes

[0:04] 蒋晓伟: 过去这一两周用过编程 Agent（AI 编码助手）的请举手？ [0:04] 蒋晓伟: 如果你逐行审查了 Agent 编写的每一行代码，请继续举着手。 [0:04] 蒋晓伟: 合并冲突本身并不是故障，它只是故障的检测机制。 [7:11] 蒋晓伟: The labs are fixing the models, but only you can fix your context [7:11] 蒋晓伟: AI 实验室在替你修复模型，但只有你能修复你自己的上下文 [12:39] 蒋晓伟: It speaks Postgres [15:36] 蒋晓伟: The data lakehouse is your source of truth for analytics [15:36] 蒋晓伟: Tacnode context lake is your source of truth for automated decisions

Source quotes

[0:04] Xiaowei Jiang: How did it do it? [0:04] Xiaowei Jiang: Approving on vibes [0:04] Xiaowei Jiang: BOOM: 43 merge conflicts across 9 files [0:04] Xiaowei Jiang: The only reason this failure was detected is because Git caught the structural text overlap; the merge conflict itself is not the underlying failure, but merely the detection mechanism. [2:35] Xiaowei Jiang: Machines received speed without rich context, while humans received rich context without speed. [2:35] Xiaowei Jiang: An AI agent is effectively an application endowed with human judgment capabilities—acting as two consumers in one body. [5:50] Xiaowei Jiang: as if the context were right [7:11] Xiaowei Jiang: The labs are fixing the models, but only you can fix your context. [15:36] Xiaowei Jiang: The data lakehouse is your source of truth for analytics. But Tacnode context lake is your source of truth for automated decisions.

Original transcript

[0:04] Raise your hand if you used coding agent this week or previous week. [0:09] Yeah, almost everyone. Keep your hands up if you review every single line of code your agent wrote. [0:14] Yeah. Well, I'm surprised. Yeah, I'm not. [sighs] So, here's a week you have all had so far. [0:21] Your coding agent hands you 400 lines of a code and the checklist all green from top to bottom. [0:29] All the test cases pass, but you sit there with this feeling you got. How did it do it? [0:35] Because you saw it before, you saw your coding agent was adding a special case just to get the [0:41] test case passing. It loosened the material assert to get the program running and in one case you [0:47] even caught it removing the body of a test case just to get the test case passing. Telling correct [0:53] code from a green checklist takes a lot of work. You have to review a code line by line. So, you [1:00] decide to review the code. Except the coding agent hands you another six pull requests while you were [1:06] reviewing the first one. The agent can write in 10 minutes what it takes you long hour to review. [1:13] So, by Wednesday you are already uh skimming and by Friday you are approving on vibes. [1:21] But this particular change is important, so you decide to block a whole afternoon to review it. [1:26] You went through the code line by line, test case by test case and it was genuinely good code, [1:32] you hit approve. Then you went to merge. Boom, 43 conflicts across different nine different files. [1:40] Your teammate has made a large refactoring while you while you were reviewing the code, [1:45] which removes the very APIs your coding agent was building upon. The coding agent was right, [1:52] your review was good, but the ground has moved from underneath both of you and you lost your [1:58] afternoon. And the only reason you know it is because Git caught it. The merge conflict is not [2:04] The merge conflict is not the failure itself, it's the detection. And this is [2:10] a lucky case because you caught the error before it ships. But Git only catch textual conflicts, [2:16] which happens when two agents are editing exactly same lines. It cannot catch semantic conflicts, [2:22] which happens when two agents are editing different file different lines from different [2:27] files, because the Git will merge cleanly, but the conflict is not in the text, it's in the meaning. [2:35] As agents are taking over more and more business business decisions, such kind of failure mode is [2:41] becoming increasingly important. I'm Shallway, I'm CEO and the chief architect at Technode. [2:47] In remaining of this talk, I will walk you through this failure mode and how we can prevent it. [2:53] So, um Let's look at what the consumers of data. For as long as we have different infrastructure, [2:59] there are exactly two consumers of data, machines and humans. And we build a different system for [3:04] each. Machines get the data database. The application needs fast access to data, [3:11] but the application access pattern are usually very simple. It may modify a few records in a [3:16] transaction. It may retrieve a record using a key, but does not ask complex cross cross-cutting [3:25] questions, because machines applications only execute logic, they do not make judgment calls. [3:31] And the judgment calls are reserved for humans. Humans get the data data house. [3:39] So, the the the the When humans make decision, it needs complex signals. So, a data warehouse and [3:47] dashboard was built for to facilitate it. A human looks at the dashboard, takes it into a meeting, [3:54] argues about it, and makes a decision eventually. This whole process can take hours or even days. [4:00] So, because of this, this time scale has a baked into our system. If a human takes hours or days [4:07] to make a decision, it doesn't matter if the dashboard before you is a 5 minutes stale. [4:13] So, we have two systems. The machines get the speed, but not rich context. [4:18] Humans get the rich context, but not the speed. There is no system in the world that can provide [4:24] rich context at the machine speed. Because there is no consumer asking for it. [4:30] And here, agents arrive. Agents do two radically different things. The first thing agent does is [4:38] agents remove human from the decision loop. What is the agent? An agent is basically application, [4:46] but with human capability. It runs as application. So, um at the same time, they can do things that [4:54] human that only a human could do. So, on one hand, it behaves Agents are basically two consumers [5:02] in one body. On one hand, agents behave like a machine. It's running at as a at machine machine [5:08] speed. So, it needs the speed the application has. On the other hand, it behaves like human. [5:15] It can make judgment calls. So, it needs the rich context, which is needed by a analyst. [5:25] For the longest time, human is the the bottleneck in decision-making process because humans are [5:31] slow, but agents completely change that. Agents can make decisions in minutes or even seconds or [5:37] milliseconds. The When agents make decisions, humans are removed from the decision loop. [5:44] The decisions are becoming automated. With the decisions, the bottleneck are no longer humans. [5:50] It becomes providing the context to agents. The second thing agent does differently is [5:57] agents multiply. There is a misconception that you need multi-agent system because [6:02] you want multiple roles. This is definitely a valid use case. For example, you may want a [6:07] design agent which is responsible for designing the architecture of your product. And you have a [6:12] coding agent for implementing the code and a testing agent for testing your product. [6:17] But this is not the only use case. There is a equally important use case. Imagine even if you [6:22] have a agent which can do everything, but it still does things step by step. It can be too slow for [6:28] your business. And the resolution to that is by running multiple instance of this agent. So, there [6:34] are two valid reasons for a multi-agent system. Either division of labor or speed things up. The [6:41] um By providing right context, in a multi-agent system it is even more challenging. We need to get [6:49] the context right to make sure these agents can work together very well. So, we are entering into [6:55] a world where there are multiple agents running in parallel at machine speed with human capability, [7:02] and the bottleneck has moved from human to providing the context for such agents. [7:11] So, what is correct context? [7:16] The When we get When we get context correct, agents can work well with each other. But [7:22] what happens when contexts are wrong? So, first let's think about why do agents get [7:27] the wrong context. The simple answer is because there is no better context available to it. So, [7:35] the whole data lakehouse was built on batch pipelines assuming human is on the other end [7:41] of the pipeline. Who can afford to Who can afford to wait? So, if a agent needs a velocity counter, [7:48] as of now, we don't have this velocity counter computed in yet. So, the best thing we can give [7:54] is the velocity counter maybe a while back. And the agents will take it as a ground truth [8:00] and computer it and come to a conclusion as confidently as if the context were right. [8:06] Nothing slows. The error was silent. And silent failures are especially damaging [8:11] in multi-agent system because when agents run in parallel, they are also wired to each other. [8:17] One agent's output becomes next agent's input. So, if if we provide wrong context to a single agent, [8:23] the agent will make a wrong decision. This wrong decision becomes the basis for the next agent. [8:29] Next agent will build on top of it and the pass it on to and the one after that. [8:34] By the time something surfaces, it's already three steps downstream from where the wrong [8:40] context introduced it. And nothing was apparently wrong in the whole chain leading to it. So, [8:46] errors in multi-agent systems can compound. And every decision have two ingredients. The model, [8:53] which is responsible for the reasoning, and the input to the model, which which we call context. [8:59] The labs are increasing are improving models quarter by quarter and month by month. The [9:04] models are getting better and more reliable. But the better the models get, the more errors are [9:10] coming from your context. Uh the labs are fixing the models, but only you can fix your context. So, [9:17] what does correct context mean? A correct context really needs three things all at once. First, [9:24] agents need context which are shared. When agents assemble context from multiple different systems, [9:30] even if even if each individual piece is correct, when you combine them together, [9:35] they may be mutually incompatible. You will be making a decision on a world that never existed. [9:42] And when multiple agents are working together, they need to agree on what the world looks like [9:47] for their decisions to be compatible with each other. Second, the context needs to be [9:52] live. Is the access Agent needs access to live context at the moment when we make a decision. [9:59] In our coding example, the agents each agents was working on a stale snapshot of the code base. This [10:06] is the fundamental reason which caused the merge conflicts. And the agents are also making judgment [10:12] calls just like a human being. For human being to make a solid judgment calls, it need access [10:17] to all these signals which are usually available in dashboard or reports. All such signals are [10:24] derived data from raw data, and we need to make this available to agents. Except in this time, [10:31] they have to be live as well. In addition, agents may need to extract semantic meaning from [10:38] unstructured data, such things like is this comment for a product positive or negative? [10:44] By providing rich semantic context to agents, it enables the agents to make solid decisions. [10:52] So, let's look at what kind of systems can provide such kind of correct context. [10:58] The obvious candidates are database and data lake house. Database is good at providing live data [11:04] at millisecond. But the database relies on scale up to get more capacity. It eventually is max [11:11] max out the machine, and when you when that happens, you are forced to do sharding or caching. [11:17] When you do that, it breaks the shared property. And we all had experience that a complex query [11:24] kills the performance of the whole database server. So, database is not designed to provide [11:29] the rich signals that agents need. On the other hand, a data lakehouse is horizontally scalable, [11:35] so it can provide a shared view of context to all agents. And data lakehouse is also good at [11:41] computing signals. [snorts] Um but the signal can be stale. Like lakehouse is built with the [11:49] assumption human is the consumer of the of the signals. So, um the it relies on batch pipelines, [11:56] which can run for minutes or even hours. So, the context provided by lakehouse is not live. There [12:03] is no system in the world which can provide all three at once. The best you can get is pick two. [12:13] That's why we build Technode context lake. Technode context lake can provide shared, [12:19] live, and the semantic context, all three at once. So, all your agents [12:26] will receive context from Technode. It's guaranteed to be coherent. At the same time, [12:32] all agents write these decisions into Technode. Such decisions become the context for next agent. [12:39] So, each agent can build on the decisions produced by the intelligence of the previous agent. [12:46] Intelligence compound instead of errors compound. It becomes a loop. [12:55] As we As we As we [13:02] As we just As we explained, when no system can do can provide all three things at once. So, [13:10] we built Technode as a single engine from ground up with correctness with these three properties [13:17] as the guiding principles. The The first Technode is compatible with Postgres. It speaks Postgres, [13:24] which means all your knowledge about Postgres, all the [13:28] all the tools in Postgres ecosystem can be reused in Technode. If you know how to use [13:34] Postgres, you know how to use Technode. Just change your connection string. [13:39] Second, Technode is horizontally scalable. So, you can add more nodes to get more more capability [13:47] with Technode. The architecture of Technode is separation of compute and storage. So, [13:55] the scaling is also very elastic. You can do the scaling within seconds. Third, Technode provide [14:03] full asset guarantees. It makes sure the contacts your agents retrieve are always consistent and [14:10] coherent with each other. Um agents needs to extract contacts from all different types of data, [14:18] including structured data, semi-structured data, vector data, and unstructured data. So, [14:24] the Technode supports JSON, native vector search, and the full text support including BM25. This [14:34] helps agents to retrieve contacts from all different types of data. [14:39] The ability to quickly compute the signal is vital for agents to make a judgment calls. And to do [14:46] that, Technode does two things. It implemented vectorized vectorized execution, which can [14:53] which can execute complex queries very fast. At the same time, it supports hybrid storage, [14:59] which makes it possible to retrieve single rows efficiently as well as large scans efficiently. [15:07] Because of this, Technode can compute the most complex signals on demand. In the case [15:14] that your signal is too complex to compute on demand, or your signal needs to be retrieved by [15:20] agents many times, you also have the option to use incremental materialized view. This calculates the [15:27] signal when data arrives. So, when you need to retrieve it, the signal is already there. [15:36] As the agents are taking over business decisions, these humans are removed from [15:41] loop. These decisions are becoming automated. Providing right context to the agents is vital, [15:48] especially in time-sensitive applications. This includes things like risk management, personalized [15:56] recommendation in e-commerce, and in multi-agent system coordination. So, here's the takeaway. [16:06] The data lakehouse is your source of truth [snorts] for analytics. [16:11] But Technolog context lake is your source of truth for automated decisions. We have a booth. [16:18] You can find us if you have more things to discuss at our booth. And this is my email. [16:24] You should me an email if you have more more things to discuss. And also find me on LinkedIn.