Agent-Native Systems Become More Deterministic Over Time, Not Less

Here’s what everyone gets wrong about agent-native systems: they assume it means more AI, more flexibility, more agents doing everything. The reality is the opposite. The best agent-native systems start flexible and gradually harden into mostly-deterministic code. The agent’s footprint shrinks as the system matures. The agent never leaves entirely, but it gets smaller, more focused, and infinitely more valuable.

I didn’t see this pattern clearly until building infrastructure for agent-native teams at both Autoblocks and Hex. It kept happening the same way: a flexible agent system at day one. Stable patterns emerging by week four. Deterministic code extracting those patterns by month three. The agent relegated to genuine edge cases and novel problems. And suddenly, the system was faster, cheaper, more reliable, and easier to audit.

This is crystallization. It’s happening in production systems right now. It’s the difference between agent-native companies that win and ones that get buried in token costs.

The Crystallization Lifecycle

Picture this. On day one of your agent-native system, you’re roughly at 85% agent reasoning and 15% deterministic tools. The agent is exploring, figuring out what works, what doesn’t, which workflows matter. It’s messy. It’s inefficient. It’s also necessary.

Six months in? You’re inverted. Maybe 20% agent reasoning, 80% deterministic code and typed tools. The agent has been promoted from “do everything” to “handle what’s actually novel.”

This mirrors something Will Larson and Dan Shipper call compound engineering. The system learns from its own behavior. Observability feeds insights. Insights become code. Code becomes the new floor. The agent’s next iteration handles a different set of problems.

It’s like the relationship between an interpreter and a compiler. An interpreter is flexible. It can execute anything you throw at it. A compiler knows what you’re going to execute, optimizes it ahead of time, and runs it in microseconds. The best agent-native systems gradually compile themselves.

How Crystallization Actually Happens

Let’s be concrete. Your agent is running email workflows. It’s pulling emails, classifying them, drafting responses, escalating to humans when needed. After two weeks, your observability logs show something: the fetch_emails → classify_intent → route_to_team pattern has been identical for 147 consecutive runs. No variation. No edge cases. Just the same sequence, over and over.

That’s a candidate for crystallization.

You take that pattern and extract it into deterministic code. A typed function. Maybe a small MCP server. No agent reasoning required. Just input, deterministic logic, output. The agent no longer touches this workflow.

But something new happens: the agent encounters emails that don’t fit the original pattern. Ambiguous intent. A customer asking for something that crosses two teams. The agent still handles it. Now it’s not burning tokens on the 80% case. It’s focused on the 20% that actually needs reasoning.

Greg Mays calls this the “earned trust” model. Everything is a draft until a human approves it. But the moment a pattern is approved multiple times, it graduates from “agent decision” to “rule.” That rule becomes deterministic code. Over time, approval patterns compound into the system’s backbone.

This is also why Jared Zoneraich’s observation about bug fixes becoming prompt edits is only half the story. Yes, you can edit a prompt. But better systems crystallize common bug fixes into code and leave the agent to handle the rare cases that broke the previous rule.

Why This Matters: The Cost Argument

This is where crystallization stops being philosophy and becomes engineering.

Deterministic code costs you $0 per call. Zero. A function call is nanoseconds of CPU. An agent call is tokens. Right now, using Claude Opus, that’s roughly $15 per million tokens. Sonnet is $3 per million. Haiku is $1 per million. But deterministic? It doesn’t exist on that spectrum.

The General Intelligence Company is spending $4,000 per engineer per month on Opus tokens. That’s not a complaint. It’s the current reality of agent-native engineering at scale. But it also means that crystallization isn’t optional. It’s the difference between a sustainable business and one that gets crushed by compute costs.

If your mature system is still 85% agent reasoning, you’re leaving money on the table. You’re also accepting latency, reliability, and auditability problems that deterministic code doesn’t have.

Consider the latency dimension. A deterministic function call: sub-millisecond. An agent reasoning call on Haiku: 500 milliseconds to 2 seconds, depending on complexity. On Opus: 3-5 seconds. If 80% of your operations are deterministic, you just cut your p95 latency in half.

Reliability is the third lever. Deterministic code doesn’t hallucinate. It doesn’t have bad days. It doesn’t confuse contexts or skip steps because it got distracted. For the 80% of your system that deals with stable, well-defined operations, deterministic is strictly better.

And auditability? A human can read deterministic code in seconds and understand exactly what happened. An agent’s reasoning is a black box. A token stream that’s human-readable but not easily defensible. If you’re handling anything compliance-adjacent, deterministic code is the only honest answer.

The Art of Knowing What to Crystallize

Not everything should crystallize. This is where the judgment lives.

Routing and classification logic, for instance, often benefits from staying flexible. Intent detection in particular. You’ll always get edge cases, nuance, domain-specific context that a rule won’t capture. Your agent should stay in the loop there.

Open-ended input spaces are another red flag. If the customer can ask you anything, and it’s genuinely open-ended, crystallization backfires. You’ll encode the 95% case and then spend all your time fixing edge cases.

Decisions requiring cross-domain reasoning should probably stay with the agent too. If your operation touches both customer support and billing, and the right answer depends on factors from both domains that change independently, you’re not going to capture that in typed functions. The agent sees the whole system.

Workflows that change frequently? Crystallize at your own risk. If your product team is reshaping requirements every sprint, deterministic code becomes technical debt faster than you can extract it.

But here’s the principle that separates good crystallization from crystallization theater: crystallize the verbs, not the sentences.

Deterministic code should be small, typed, composable operations. fetch_emails(query). classify_intent(text). generate_invoice(order_id). These are verbs. They’re reusable. They’re testable. They compose well with other verbs.

What should not be deterministic is the orchestration logic, the sequencing, the “if this then that then check this other thing” choreography. That’s the sentence. That’s where the agent still lives.

The worst crystallization I’ve seen locks an entire workflow into code: “If emails come in, classify them, route them, generate a response, escalate if revenue is above threshold.” Now you’ve encoded your entire business logic. Your first tweak to the escalation threshold requires a code change. Your first novel case breaks the whole pipeline.

Better: crystallize each verb, let the agent compose them.

The Inflection Point

Here’s the thing that separates real agent-native engineering from just “using AI everywhere”: the inflection point.

There’s a moment when your system flips from “agent doing most things with some tools” to “deterministic code doing most things with the agent handling exceptions.” That moment is when your observability tells you it’s time to crystallize.

Some systems reach that inflection point in weeks. Some in months. Some never reach it because they were badly designed to begin with.

The companies doing agent-native engineering well are obsessed with observability, pattern detection, and knowing when to extract. They’re building infrastructure, not just wiring APIs together. They’re thinking about the lifecycle.

(If you want a framework for understanding where your organization sits today, I laid out the full spectrum in Most Companies Aren’t Agent-Native.)

This is probably why tools like Autoblocks matter. You need visibility into what your agents are doing. You need to know which sequences are identical. You need to track approval patterns, reliability metrics, cost per operation. Without that visibility, you’re flying blind. You’ll crystallize the wrong things, or worse, not crystallize at all and wonder why your token bill is insane.

The Agent Never Fully Leaves

One last thing: don’t fall into the trap of thinking the agent is a temporary crutch. It’s not. The agent is still doing the most valuable work, even at 20% of the system’s operations.

The 20% of cases that need reasoning are often the 80% of the value. A novel customer request. An edge case that breaks the rule. A situation that requires judgment across domains. The agent is still there, but now it’s not distracted by routine operations. It can actually think.

This is what makes agent-native systems different from the older paradigm where everything had to be rule-based from day one. You don’t need to predict all the edge cases upfront. You let the agent explore. You crystallize the stable patterns. The agent handles the novel cases.

Over time, this creates systems that are simultaneously more deterministic and more intelligent than what came before.

That’s the real promise of agent-native architecture. Not AI everywhere. A system that starts flexible, learns from itself, crystallizes what it knows, and gets better at handling what it doesn’t.

If you’re building agent-native systems, the question isn’t whether to use agents or deterministic code. It’s knowing when to transition between them. The companies winning right now are the ones that obsess over that transition point.