Change data capture is not a business event.

The pattern is common enough to be a default. A team wants an AI agent to respond to what happens in the business, so they point it at the change stream they already have: change data capture from the database, a webhook, or a queue topic. The agent gets a payload, a prompt template, and a couple of tools.

It demos well. Then it goes to production and behaves strangely in ways nobody can quite characterize. The agent reacts three times to one thing that happened once. It escalates an order a human already handled. After a schema change it starts confidently misreading the situation. And when someone asks why it did what it did in March, the honest answer is that nobody can reconstruct it.

None of this is a model quality problem, and none of it is CDC's fault. CDC is excellent at its actual job. The problem is that its job is not the one being asked of it.

What change data capture actually gives you

CDC gives you a faithful, ordered, complete record of row-level mutation. That is genuinely hard and genuinely valuable. It is also deliberately meaningless:

table:   orders
op:      UPDATE
before:  { id: 3812, status: 3, eta: "2026-03-04" }
after:   { id: 3812, status: 7, eta: "2026-03-06" }

Everything a business cares about is absent. Is order 3812 important? What is status 7? Is a two-day slip normal for this customer or a breach? Did something already respond to this? Is anyone allowed to act on it automatically?

The row is the evidence. The event is the interpretation. CDC ships evidence and leaves the interpretation to whoever is downstream.

The reconstruction tax

Something has to supply that interpretation, and today it is usually the prompt. The integration fetches related records, flattens them into text, hard-codes that status 7 means delayed in transit, adds a paragraph about what the agent is allowed to do, and sends it to the model.

That works. It also means the operational meaning of your business now lives in a string, is rebuilt slightly differently in every integration, and is discarded the moment the response comes back.

This is the reconstruction tax, and it produces three specific failures.

1. Meaning drifts and nothing tells you

A team adds status 9 and reassigns the meaning of 7. The database is correct. The dashboards are updated. The prompt is not, because the prompt is not part of anyone's migration checklist. The agent keeps reasoning fluently over an interpretation that stopped being true, and fluency is exactly what makes this hard to catch.

2. There is no idempotency at the business level

One thing happened: an order became at risk. Your stream may express it as three row mutations across two tables, possibly out of order, possibly retried. Row-level deduplication cannot fix this, because the unit you need to deduplicate on—this order entered the at-risk state—does not exist anywhere in the stream. So the agent either acts more than once or you invent a fragile key and hope.

3. Causality cannot be audited

You can prove a row changed. You can prove an agent called a tool. You usually cannot prove why, because the reasoning input was assembled at request time and never stored as a first-class fact. For an internal summarizer that is tolerable. For anything touching money, customers, or commitments, "the model decided" is not an audit trail.

What a business event is instead

A business event is a change expressed over meaning your domain owners have accepted, not over storage layout:

event:    fulfillment.order_at_risk
subject:  Order 3812  (priority customer)
because:  shipment.eta +36h, no alternative routing
policy:   delay_over_24h_priority
allowed:  [inspect_options, prepare_response]
decision: Human review required

The difference is not formatting. It is that identity, meaning, policy, and permitted response are explicit and versioned rather than improvised per call. The agent stops being asked to infer what matters, and starts being told—with the same statement everything else in the system uses.

Five questions for your own stack

You do not need Aware to apply this. Take one workflow where you already want an agent to act, and ask:

1. Can you name the event without naming a table? If the best description is "when orders.status changes," you have a row trigger, not a business event.
2. Would it survive a schema migration? If splitting a table silently changes agent behavior, meaning is coupled to storage.
3. Is it idempotent at the business level? If the same real-world occurrence can trigger two reactions, the unit is wrong.
4. Can you replay it and get the same decision? If the inputs were assembled in a prompt and discarded, you cannot replay—only re-guess.
5. Can you explain an action six months later? Not "which tool ran," but which change, which interpretation, and which policy made it permitted.

Most teams pass one or two. That is not a failure of engineering discipline; it is that nothing in the standard stack owns this layer. CDC owns delivery. The model owns reasoning. The space between—what the change means and who may act on it—has no default home, so it ends up distributed across prompts and glue code.

Why this is hard to retrofit

The honest answer is that declaring accepted meaning is real work. It requires someone with authority to say what an order is, when it is at risk, and what may happen automatically. It is the step teams skip, because a prompt gets to a demo faster.

The cost arrives later, and it arrives as trust: the agent is technically running and nobody is willing to let it act unsupervised. Adding autonomy on top of unstated meaning is what makes that permanent.

Where Aware sits

Aware is building this layer explicitly: your existing system stays the fact authority, your domain owners approve the operational meaning, and changes over that meaning become events with policy, bounded agent capability, Human control, and a connected audit trail.

We work one bounded workflow at a time, on purpose. That is how this layer gets built without asking anyone to hand over their operating model on faith. What is available today is a two-week engagement that turns one workflow into an implementation-ready blueprint: the source, the approved meaning, the policy, the agent boundary, the audit trail, and a fixed scope for what comes next.

If the five questions above landed uncomfortably for a workflow you care about, that is the conversation worth having.