Picture a dispute, six months from now.

A customer's loan application was declined. Or a transaction got flagged. Or a support case was auto-closed, or a record was routed to the wrong queue, or a refund was approved that shouldn't have been. Someone — a regulator, a lawyer, your own head of risk — points at it and asks the question that has ended a thousand AI projects:

"Why did the system do that?"

For the last forty years, that question had a boring, reliable answer. You read the code. Software was deterministic: the same input produced the same output, every time, and the logic that connected them was sitting right there in a file you could open. The audit trail was the source code. If you wanted to know why the system did something, you traced the branch it took.

Agentic AI quietly demolished that.

The shift nobody updated their compliance for

When you put an LLM-driven agent in the loop, the software stops merely computing and starts acting. It makes judgment calls. It decides which tool to invoke and when. It chains multiple steps together, where each step's output shapes the next. It interprets ambiguous inputs that no if statement ever anticipated. And when one model provider has an outage, it might fail over to another one mid-decision.

None of that is reconstructable from the source code, because the source code no longer contains the decision. The decision happened at runtime, inside a model, shaped by a prompt and a context window and a tool result that existed for one moment and is now gone. "Read the code" is no longer an answer. The code didn't decide. The agent did.

This is the part most teams haven't internalized: the liability moved. For years, compliance for software basically meant "is the data secure and access-controlled." That's still necessary, but it's no longer the hard part. The hard part is the new question the agentic era forces into existence — can you prove what your autonomous system decided, did, and touched, long after the moment passed? You can't secure your way to that answer. You have to have captured it.

And here's the trap: you cannot capture it after the fact. A deterministic system you can re-run — feed it the old input, watch it take the old path. A non-deterministic agent you cannot. If you didn't record what happened as it happened, the information is simply gone. There is no rewind. This is why compliance in the agentic era can't be a layer you add before the audit. It has to be a property of the engine that runs your agents, recording as it goes. That conviction is why we built it into Grove from the first line rather than bolting it on.

In practice, the agentic era forces four questions, and each one demands an answer the old logging never had to give.

1. "What is this agent even allowed to do?"

Before anyone asks what an agent did, they ask what it can do. What tools can it call? What models does it run on? What systems can it reach, and where does data flow as it moves through the steps?

With traditional software you'd answer by walking someone through the code. With an agent that's an unsatisfying, error-prone exercise — and it's exactly the kind of thing a security reviewer wants on paper, current as of today, not as of whenever someone last updated a wiki.

So Grove generates the answer on demand. Every workflow can render a compliance document — not a hand-maintained doc that drifts, but a live artifact built from the actual workflow definition. It enumerates every model the agent can invoke, every tool it can call, the order its steps execute in, and the paths data takes between them. You hand that to your reviewer instead of scheduling three meetings. The thing being audited describes itself, accurately, every time you ask.

2. "What exactly did it do on the 14th?"

This is the dispute scenario. Months later, you need to reconstruct one specific run.

Two things have to be true to answer it. First, you need to know which version of the logic ran — because the workflow has almost certainly changed since. In Grove, workflow definitions are immutable and versioned: editing one doesn't overwrite it, it creates a new version and preserves the old, and every run permanently records the exact version it executed against. The logic that ran on the 14th still exists, frozen, even though the workflow has moved on five times since.

Second, you need the execution lineage — the step-by-step record of what actually happened. Each node in the agent's graph gets its own record: what went in, what came out, how long it took, and — this is the agentic-era detail people forget — which model and provider actually served it. If the agent tried one provider, hit an error, and failed over to another, that whole chain is captured: what it attempted, what failed, why it switched. The non-determinism doesn't vanish; it gets written down.

There's a subtle but important corner here. What happens to the record if the server crashes mid-run? A naive system leaves runs frozen forever in a lying "in progress" state. Grove sweeps those on restart and marks them failed with a reason, so the audit trail never claims something is still happening that isn't. (Worth being honest about scope: that recovery currently assumes a single instance reasoning about its own work — the kind of detail you want to know before a regulator finds it, not after.) The record should never tell a story that isn't true, even when the failure is your own infrastructure.

3. "Can you audit this without becoming the next breach?"

Here's the irony that catches teams off guard: the audit log you build to satisfy compliance can itself become a compliance liability. If you log every input and every output to prove what the agent did, you've now created a giant, permanent, centralized pile of exactly the sensitive customer data you're trying to protect — and it sits there forever, by design, because audit logs are supposed to be immutable.

Grove's audit log is deliberate about what it's for. It records who invoked what, when, through which credential, and how long it took — the access record. It deliberately leaves the payloads out: not the workflow inputs, not the prompt arguments, not the customer data. Those stay in the operational record, governed by their own retention and deletion rules. When an auditor needs to connect an access-log entry to the full detail, a request ID correlates the two. You get a forever-retained proof of who did what, without minting a forever-retained copy of everyone's personal information. The audit trail proves accountability without becoming the thing that gets subpoenaed — or leaked.

4. "A customer invoked their right to be forgotten. Prove it's gone."

This is the one that exposes hand-waving fastest. Under regimes like GDPR's Article 17 — and disposal rules like SEC Reg S-P — it's not enough to delete data. You have to be able to prove you deleted it, on demand, to someone who doesn't trust you. And "we ran a DELETE statement, trust us" is not proof; the whole point is that the evidence is gone too.

The technique that actually satisfies this looks paradoxical at first: Grove doesn't just erase the row, it tombstones it. Before the content is cleared, the engine computes a cryptographic hash of it (SHA-256) and keeps that hash, along with a record of when it was disposed, by whom, and why. The data itself is gone — irrecoverable — but a permanent, tamper-evident marker remains saying this specific record existed and was destroyed on this date. An auditor can later verify the deletion happened without ever resurrecting the data to show them. Every disposal lands in a dedicated, forever-retained log: which record, which customer grouping, when, and the hash that proves it.

Two things have to hold around that for it to mean anything. Deletion can't spill across customers — so customer data is partitioned by tenant at the database level, and a deletion for one can't reach another's records even when they share a label. And the credentials an agent uses to do its work are encrypted at rest (AES-256-GCM) and never handed back out through the API — because a system that will hand you a stored secret is a system that can hand it to an attacker too.

Why this is the unlock, not the tax

It's tempting to read all of that as overhead — the boring, expensive part you do because someone makes you. That's the wrong frame, and the teams that get it right know it.

In a regulated business, this instrumentation is not what slows your AI down. It's the only thing that lets it ship at all. The initiative that dies in security review dies because nobody can answer these four questions. The deal that stalls for two quarters stalls on "can you prove it." Build the answers in from the first line — make compliance a property of how your agents run, not a binder you assemble in a panic — and the review that used to take three months takes a week, because every answer is already sitting there, generated, hashed, logged, and waiting.

When software only computed, the code was the proof. Now that software acts, the proof has to be built into the act. That's not a constraint on agentic AI in the enterprise. Right now, it's the whole ballgame — and it's why compliance isn't a feature we added to Grove, but a property of how it runs.