Why AI Agents Act on the Wrong Context: Shared, Live, and Semantic

I gave this talk on the AI agents track at AI4 in August. The recording is above; this is the written version, with the arguments I had to compress for the clock restored.

The claim is narrow and, I think, uncomfortable: when your agent makes a bad decision, the model is usually not what failed. The context it was handed was already wrong when it arrived, and nothing in your stack was built to notice.

Start with the week most engineers have had. A coding agent hands you four hundred lines with green checkmarks all the way down, and you sit there wondering what it did to make the tests pass. So you block an afternoon and read it properly — line by line, edge case by edge case. The code is good. You hit merge, and you get forty-seven conflicts across nine files, because a teammate refactored the module while you were reading and the API your agent built on stopped existing an hour ago. The code was right. Your review was right. The world moved on from under both of you.

The important part is what saved you: git caught it. And git only catches one kind of conflict — a textual one, two edits to the same line. It does not catch a semantic one, where two agents edit different files, the merge is clean, and the program is now broken. The collision was in meaning, not in text.

Business decisions are almost all semantic. The fraud counter and the account balance don’t touch the same row — there’s nothing to lock, no conflict to throw — but together they’re incoherent, and the agent approves on the incoherence. In code, at least the textual case gets caught. In a business decision, the failure that matters was never catchable. It just executes. The money moves.

Machines Got Speed. Humans Got Context.

The context gap is the structural mismatch between what an automated decision needs — a coherent, current, semantically rich view of the world at the instant it decides — and what any existing data system was designed to serve. It isn’t a bug in a pipeline. It’s a missing row in the grid of systems we have built.

Start with a question we usually skip: who consumes data, and for what? For as long as we’ve built data systems there have been exactly two answers, and we built a separate system for each.

Machines got the database. Applications need data at machine speed — record this transaction, fetch that row, current to the millisecond. But look at what they asked for: thin data. Raw records and point lookups. An application never asked the database for a risk profile, a velocity trend, or a set of similar prior cases, because applications didn’t make that kind of call. They executed logic; they didn’t judge.

Humans got the lakehouse — the warehouse before it, the dashboard on top. Judgment calls, the decisions that needed rich context, went to people, and we built systems to feed people. A person reads the report, takes it into a meeting, argues, and decides some days later. That timescale got baked into the architecture: freshness barely mattered, because the human was the bottleneck. If the dashboard is five minutes stale, who cares — the person staring at it will take three days anyway.

So the split was clean. Machines got speed without context. Humans got context without speed. And it worked, because no consumer on earth needed both.

No system you own was ever asked to serve rich context at machine speed. Hold that.

The Agent Is an Application With Human Capability

Agents arrive and do two radical things, not one.

First, they remove the human from the loop. An agent is an application with human capability. It runs like an application — machine speed, machine volume — but it does the human’s job: it judges. It makes the decision that used to take a meeting, in a hundred milliseconds. Remember the split: two consumers, a system for each. The agent is both consumers in one body. It needs the rich context the analyst had, at the latency the application had. That’s the consumer that finally asks for the thing nobody built.

Every decision runs the same loop — observe, decide, act. For decades the slow stage was deciding: a human, in a meeting, taking days. Everything else was paced around us, which is why batch data was fine. The agent just collapsed deciding to one API call. Acting is a write, so it’s milliseconds. Which stage is slowest now? Observing — assembling the context to decide on, still served by pipelines paced as if a human were waiting on the other end. The bottleneck didn’t disappear. It moved, from deciding to observing, from the human to the context.

Second — the part people miss — agents multiply. There’s a common assumption that multi-agent means division of labor: a researcher agent, a coder agent, a reviewer agent. That’s one use case. The deeper reason you run many agents is concurrency. Even a single perfect agent that can do every job works serially, one thing after another, and serial is too slow for your business. So you run many copies of it in parallel. You don’t need multiple kinds of agent to have a concurrency problem. You just need multiple agents.

Go back to the merge conflict and notice what actually caused it. The agent wasn’t alone. It was working in parallel with you and your teammates, and one of you changed the ground underneath it. Even one agent lives in a concurrent world, because the world keeps moving while it works. That was concurrency at human scale — one agent, a few people — and it already broke. Now scale it the way you’re already trying to: five agents on the same codebase at once, not because they have different roles, but because one at a time is too slow. Every one of them is building on a snapshot the other four are busy invalidating. The ground now moves at machine speed too.

That isn’t a division-of-labor problem. It’s shared state under concurrency, and it’s the normal operating condition of every multi-agent system in every domain, not just code. So the new world is machine-speed decisions, at machine volume, in parallel, on shared state — running on infrastructure that assumed a slow human absorbing the lag.

The Error Is Silent, and It Compounds

An agent’s decision is only as good as the context it acts on, and the context is where the mismatch bites. The infrastructure was built to feed a human who could wait, so the fresh count hasn’t been computed yet and the coherent snapshot doesn’t exist in any system for the agent to fetch. The agent acts on the wrong context because there is no better one available to it.

Wrong context, wrong decision — that part is mechanical. Here’s the part that makes it dangerous: the agent takes what it’s given, treats it as ground truth, and reasons flawlessly on top, producing a decision exactly as confident as a right one. Nothing throws. The error is silent.

A silent error is uniquely dangerous in the world just described, where agents run in parallel and are wired to each other. One agent’s decision becomes the next agent’s input, with no human in between and no alarm to stop it. The next agent trusts it, builds on it, passes it on. One bad decision becomes the ground the next ten stand on. Errors don’t add, they compound. By the time anything surfaces you’re three steps downstream of the wrong context that started it, and nothing in the chain ever looked wrong.

A decision has two ingredients: reasoning and context. The labs are fixing reasoning, fast. Nobody is fixing your context. So the better the models get, the larger the share of your errors that comes from context. The labs are fixing reasoning. Only you can fix context.

And fixing it is not a prompting problem. This is the line between context engineering and context infrastructure: no amount of window management, compaction, or tool-selection technique repairs context that was already incoherent before the agent read it.

And the compounding runs both ways. If incoherent context makes errors build on errors, coherent context makes intelligence compound: every decision becomes a sound premise for the next. That’s what collective intelligence actually is — many agents producing something smarter than any one of them — and it is only possible when they share a coherent view of the world. Agents that disagree about reality cap each other. Coherence isn’t only how you avoid the catastrophe. It’s the precondition for the entire promise of multi-agent systems.

Shared, Live, Semantic — What Correct Context Requires

So what does correct context actually take? For any agent decision — a tool call, a routing choice, an approval — the context behind it has to be three things at once: Shared, Live, and Semantic.

Shared. Many agents deciding concurrently all need the same coherent picture: one consistent snapshot, not each pulling from its own cache that has drifted out of sync with the others.

Live. The context has to describe the world as it is at the moment of decision. Every decision has a validity window — the span in which its context is still true enough to act on — and there’s no human absorbing the lag anymore to widen it. If the world moved and the context didn’t, the agent is deciding on a world that no longer exists.

Semantic. Real decisions need more than raw data. They need signals derived from it — risk tiers, velocity counts, rolling aggregates — and context looked up by meaning — similar prior cases, relevant documents, vector search. Meaning, not just values. This is the part teams consistently underestimate, because derived state is where most of the decision’s actual information lives.

Shared. Live. Semantic. Keep those three, because the entire problem fits in one sentence: every system you already own gives you some of these, and none gives you all three.

Pick Two, at Best

Two obvious candidates.

The database — Postgres, your OLTP store — is Live, current to the millisecond. But it doesn’t scale horizontally: one box, a ceiling, and the moment you hit that ceiling you shard, replicate, and cache. Every one of those splits the single consistent view, so it isn’t Shared. And it was never Semantic: raw rows, not derived signals and vectors.

The lakehouse — Snowflake, Databricks — is the mirror image. Shared and Semantic: one consistent view, rich derived data. But not Live. It was built for humans reading dashboards, where freshness never mattered. Data lands in batches, minutes behind. Point a hundred-millisecond agent at it and it’s deciding on the past. This is the same OLTP versus OLAP division we’ve lived with for forty years, and it held up fine right until the consumer changed.

So: Shared, Live, Semantic — you pick two, at best. The lakehouse managed two. The database didn’t even manage that. And an agent’s decision needs all three at the same instant. No row in the grid has all three, and that’s the context gap: not a bug your team wrote, but a missing row.

The Composed Stack Doesn’t Close It

I know what agent builders are thinking here: my stack is fine — Postgres for state, Redis for the counters, a vector store for retrieval.

Walk through one decision. Postgres has the new $900 purchase, committed a second ago. Redis holds the velocity counter, fed by a stream that hasn’t ingested that purchase yet. The vector index for similar cases was built minutes before the purchase existed. Assemble the prompt and the purchase is in the balance, missing from the velocity, and invisible to retrieval. The agent is now reasoning about a world in which the purchase both happened and didn’t.

And I was generous — I gave you three systems. Your real stack adds the lakehouse for signals and Elastic for search. Every one is another moment in the picture.

Here’s the part you can’t fix by tuning: these systems don’t share a clock. Each one answers “here’s the state now” — but each one’s “now” is a different instant. You cannot ask all five for the same moment, because there is no moment they all agree on. And nothing warns you. Every system gives you a correct answer and none of them is lying; they’re just answering different questions about different points in time. No error, no exception. Five honest answers, five different moments, assembled into a picture of a world that never existed.

Composing more systems doesn’t fix it. Every system you add is one more clock, one more moment. More systems, more gap. That’s the structural reason polyglot persistence produces incoherent reads rather than merely slow ones.

The Alarm Fires After the Burst

When decisions are spread out — seconds apart — the patchwork gets away with it, because the pipeline catches up in between. Under load, decisions run continuously and there are no gaps to catch up in. Watch what that does.

A bot on stolen accounts fires a transfer every twenty milliseconds: fifty decisions a second. Your defense is a velocity rule. But that count isn’t a stored row — it’s maintained by a pipeline. Transaction, stream, aggregation, cache: two seconds end to end, even healthy.

Fifty a second, against a counter two seconds behind. The first hundred transfers are decided before the first one is counted. Every one of them reads the same calm counter, sees no burst, approves, commits. The bot sized the run to finish inside your propagation delay, then rotates and does it again. Your alarm fires perfectly — right after the burst is through. A control that fires after authorization isn’t prevention. It’s an incident report. The arithmetic is the whole argument: the propagation delay is wider than the validity window, so the context was already void at the instant the decision read it.

And you can’t reach for the usual database safeguards, because the signal isn’t in the database as one value. It’s a pattern spread across thousands of rows and a pipeline. The context a decision needs doesn’t live in any single place you can protect.

Every one of these failures has the same shape. No single system was Shared, Live, and Semantic at once, so you stitched several together — and the stitching is where the gap lives. That isn’t something you tune your way out of. It’s a missing system.

A System of Record for Decisions

The answer is one sentence: stop stitching, and serve every dimension of context from one system that is Shared, Live, and Semantic at the same time.

That system needs a name, and the name writes itself. The lakehouse is the home of analytics — dashboards, reports, the picture a human studies before deciding. What agents need is a home for decisions, where context is assembled and acted on at the moment the decision is made. Analytics informs; decisions act. This is what we build at Tacnode, and we call it the Tacnode Context Lake™.

Think about what already has a system of record. Your money has one. Your customers have one. Your analytics have one. Your decisions — the most consequential thing your company now produces at machine speed — have never had one. They live in log lines. In the Context Lake a decision is a first-class, transactional fact: the action and the context it was made on, committed together. Not a cache and not a read replica — state born there and held authoritatively. Which buys you something new: when someone asks why the agent did that, you replay the exact world it saw.

Notice the shape of it. It’s a loop, not a lookup. Agents read context from the Lake — everything, under one coherent snapshot, maintained live — decide, and commit the decision back into that same snapshot, so it becomes context for the next agent the instant it’s made. The freshness the lakehouse never had, the richness the raw database never had, and what neither ever had: the decision and the coherent context it acted on, written and read in one place, so nothing falls out of sync between deciding and the next decision.

One scoping note I want to be precise about, because it’s the first question every architect asks. Your existing systems of record stay authoritative for their data; the Context Lake ingests from them by change data capture and does not enforce their invariants. The Lake is authoritative — and ACID — for the state born in it: decisions, agent actions, derived state. That boundary is configurable, and teams move it over time. Nothing forces a migration on day one.

How One Engine Serves All Three

Making a single system do all three is a set of engineering decisions, not a slogan. Six of them matter.

It speaks Postgres. The Context Lake is PostgreSQL-compatible — standard SQL, standard drivers, standard tooling. Your agents already know how to talk to it, and a new context dimension is a view and a column rather than a new pipeline and a new system. Adoption is a connection string, not a migration project.

Elastic scale-out. Compute is separated from storage; nodegroups scale horizontally on demand and isolate workloads, so a heavy analytical scan can’t starve decision serving. Remember why the database lost its Shared checkmark — it couldn’t serve the crowd. This is how the crowd gets served: many concurrent agents, one snapshot. Shared stays true under load.

ACID transactions. When agents write back — an approval, a spend, a claim — the Lake commits it with full ACID guarantees. Concurrent writes don’t step on each other and every reader sees one coherent state, so the next decision is never racing an update it can’t see. This is the argument we’ve made at length in ACID for agents.

Those three make it a serious system. The next three are how it actually serves context.

Native vector, JSON, and full-text. Semantic and document retrieval run in the same engine, against the same snapshot, in the same statement as the structured lookup and the live aggregate. Not three stores to reconcile — one point of truth that every read resolves against.

Hybrid tables. A table can be stored row-wise for fast point lookups, column-wise for fast scans, or both when a workload needs both, chosen per table. So “fetch this account” and “aggregate ninety days of its transactions” can both be served well against the same committed data. That per-request aggregation your OLTP engine couldn’t afford is exactly what the columnar side is built for — computed on demand, with no pre-computation pipeline to be stale by.

Incremental materialized views. That’s the on-demand path; this is the pre-computed one. When a signal is heavy or read constantly — a risk tier, a rolling aggregate — you don’t want to recompute it on every query. You define it as a view and the engine keeps that result continuously current as events arrive, converging as the stream lands rather than rebuilding on a schedule. Not a nightly refresh, and not a stream-processing job your team writes and operates for that one signal: a standing query the engine maintains. Event transport stays where it is — what goes away is the derived-state pipeline hanging off it, and the lag it added. Incremental materialized views are the mechanism, and the choice between computing on demand and pre-computing is yours per signal, in one engine.

Put it together and the assembly that used to span a stack of systems — the live balance, the velocity aggregate, and the similar-prior-cases vector search — resolves against one snapshot, at one moment in time. That’s the patchwork problem, deleted.

Where This Shows Up

This isn’t slideware. It’s in production today, SOC 2 and HIPAA, on AWS Marketplace, and it’s built for one thing: automated decisions that can’t afford to be wrong. You already know where those live.

Risk management — fraud, credit, exposure, policy: decisions inside an authorization window, against live customer and network state.

Personalization — recommendations on live session behavior and current inventory, not a profile that went stale minutes ago.

Agentic systems — shared memory, multi-step workflows, and observability across agents acting on the same state in parallel.

But it isn’t really about the list. Wherever a machine decides, with consequences, under concurrency, this is the problem — and no smarter model will save you, because the failure was never in the model.

If you remember one sentence, make it this one: the lakehouse is your system of record for analytics; the Tacnode Context Lake is your system of record for decisions, providing context that is Shared, Live, and Semantic in one snapshot.

That property — every agent deciding against the same version of the world — is what we call decision coherence.

The lakehouse was built for a world where the human was the bottleneck, so it never had to be Live. Agents removed the human and then multiplied, and no legacy system gives you all three properties at once. That gap is why your agent acts on the wrong context, and no model fixes it, because it isn’t a model problem.

And on the other side: when every agent decides on the same coherent context, errors stop compounding and intelligence starts to. That’s the prize.

One last thing, for anyone who remembers their algebraic geometry. A tacnode is a singular point — the point where two curves touch. Decades ago data split into two curves: machine speed, and human context. We named the company for the point where they meet.

Frequently Asked Questions