Solving the architecture gap in operational AI

Systems that make decisions on live, changing data at scale tend to hit the same wall, and AI is pushing teams into it faster. The models work, the compute is available, the application logic is sound, and the agentic workflow is set up. But the data layer underneath can't keep pace with the decisions being made on top of it.

Autonomous agents that reason, plan, retrieve, validate, and retry can generate far more data operations than their application-driven counterparts. A single business question that once produced a handful of database queries can now produce tens or hundreds, as agents decompose problems, assemble context from multiple sources, and verify their own outputs before acting.

The model provides the intelligence. What keeps that intelligence connected to what's happening now, deciding in time and running reliably at production scale, is the data layer beneath it.

In this post, we explain how Aerospike's architecture can break past that wall, mapped to the dimensions that separate production-ready platforms from those that hold AI initiatives back.

Where the data layer sits in the operating loop

Operational AI supports decisions while work is happening, and each decision feeds the next. The operating loop behind it moves from state to the context a decision needs, then to the decision, the action, and its consequence. That consequence becomes the updated state the next decision starts from.

The data layer sits at both ends of every turn. It supplies the state and context going in and records the consequence coming out, so every decision depends on how current, complete, and fast that data is:

Every real-time AI workload runs its own version of this loop, whether it’s fraud detection, personalization, risk management, or inventory optimization. If the data layer serves a stale value, the decision inherits it. If it loses an update, the next decision can’t see it. If a read is slow, the decision misses its time budget, and the customer has already moved on.

The loop has to handle two patterns: one where application code runs each step, and one where AI agents decide the steps themselves. In application-driven workloads, the code calls models, reads state, acts, and writes the result in a fixed sequence. In agentic workloads, agents plan their own steps and iterate until they reach a validated answer. Both run on the same data layer, but agents raise the pressure, with many actors reading and writing the same records simultaneously.

The data layer decides whether the loop keeps up or falls behind. To keep up, it has to save every change as it happens, build context from current data rather than a cached copy, return that context before the decision’s deadline, and do it all at a cost the workload can sustain.

What agentic AI changes for the data layer

Agents turn one request into many trips to the data layer. An agent doesn't resolve a request in a single model call. It decomposes the task into sub-queries, pulls context from several sources, validates intermediate results, retries what fails, and cross-references before answering, and every one of those steps is a read or a write.

Consider an agent performing fraud analysis. Checking one transaction means pulling account history, related entity graphs, and behavioral baselines, scoring against several models, cross-checking the result, and writing the new risk state back, all inside the same decision window. Now multiply that across thousands of concurrent agents.

A data platform that handles application-driven workloads well can strain under this increased load. If agents read their own writes to validate each step, eventual consistency becomes a liability. Read latency that didn't matter at one query per request adds up fast across dozens of chained steps. And the cost of supporting each decision has to hold up as agent activity grows.

The key layers behind every production AI system

Every production AI system runs on four layers, whether apps or agents drive the loop:

1. The model layer creates intelligence. These are the large language models, machine learning models, and statistical models that generate the predictions, scores, and recommendations that power AI applications and agents alike.

2. The compute layer executes intelligence. It's the GPUs, CPUs, and inference engines that run the models and process results at the speed the application or agent demands.

3. The operational intelligence layer sustains intelligence. This is the data layer: the platform that maintains authoritative state, assembles context, supports decisions, and preserves the consequences of every action. For application-driven workloads, it serves the application's data requests. For agentic workloads, it serves the agent's more frequent retrieval, validation, and progress writes.

4. The orchestration layer turns intelligence into action. Whether it's application code or an agent framework, it translates model outputs into decisions, workflows, and user-facing experiences. It owns the decision logic and the actions.

Most AI infrastructure investment flows to models and compute. But the data layer decides whether that investment holds up under production load.

As agents chain more steps into each decision, the data layer can become the bottleneck. If it can't keep pace, the best models and fastest compute still end up waiting on stale or slow data, and the investment in them goes to waste.

Six dimensions of a production-ready data layer, and how Aerospike measures up

Whether a data platform can sustain the operating loop comes down to six measurable dimensions. Each one tends to surface when a workload moves from prototype to production, and each gets harder as agents add more reads and writes.

These dimensions depend on each other. Fast reads don't help if latency climbs as agent load grows, and scale doesn't help if eventual consistency means decisions run on stale data. The data layer has to deliver on all of them at once, at the scale that agentic workloads demand.

How Aerospike delivers: Hybrid Memory Architecture

At the center of Aerospike's ability to deliver across these dimensions is Hybrid Memory Architecture, or HMA. 

HMA pairs an in-memory primary index with a storage engine built for flash. Aerospike reads and writes the drives directly, spreads that work across them in parallel, and defragments continuously in the background. As a result, reads perform the same whether or not the data is cached in memory. Because the data doesn't have to fit in memory, data volume can grow independently of memory capacity, and that changes the economics of large deployments.

An all-in-memory database has to add RAM for every gigabyte of growth. Aerospike adds SSD capacity instead and keeps reads fast as data grows, because the index stays in memory. Infrastructure grows with the data you keep, not with a memory footprint sized to hold all of it. That matters more as agents add to both the data and the query volume.

Keeping the index in memory also shortens recovery: a restarted node can pick its index back up instead of rebuilding it from storage.

Beyond HMA: Aerospike capabilities that sustain the loop

HMA is the foundation, but sustaining the loop also takes the right guarantees for consistency, updates, and recovery. These Aerospike capabilities cover them:

• Strong consistency: In strong consistency mode, acknowledged writes aren't lost, even when the network splits, and a client always reads back its own writes. An agent can write an intermediate result and trust what it reads before the next step. Stricter reads across all clients are available when a decision needs them, at some cost in latency.

• Collection data types (CDTs): Maps and lists let you update parts of a record, like appending to a transaction history, incrementing a counter, or updating a risk score, in one operation without reading the whole record back first. When many agents update the same records, that removes a round trip from every change.

• Multi-record transactions: Transactions commit changes across several records together or not at all, so application code doesn't have to unwind partial updates.

• Multi-site clustering and XDR: Aerospike offers two ways to run across data centers. Cross Datacenter Replication (XDR) copies changes between clusters asynchronously, which suits disaster recovery and data where the latest value is enough, like a last-known location. Where every update matters, like a wallet balance, multi-site clustering runs one cluster across locations.

• Auto-sharding and rapid rebalance: Data distributes automatically across nodes. When a node joins or leaves, data rebalances without manual work and keeps full replication while it moves. Absorbing more agent demand means adding nodes, not running a migration project.

• Rack-aware data placement: Rack awareness keeps copies of each partition in different racks or availability zones, so losing one doesn't take data offline. Clients can also read from the nearest copy to cut latency.

• Fast restarts: After a planned shutdown, a node restarts warm: it picks its index back up and rejoins the cluster without rereading its data from storage, so maintenance doesn't stall the loop. Index checkpointing extends that to host reboots and container replacements.

The operating loop at scale: PayPal fraud detection on Aerospike

PayPal evaluates fraud risk at login, account changes, purchases, transfers, and withdrawals, with a tight time budget for every decision. Within that window, the system has to retrieve account history, assemble contextual signals, score the activity against current risk models, and return a decision.

Every step of the operating loop shows up here. State changes with every transaction, context draws on petabytes of risk data, each decision has to finish inside the time budget, and its result updates the account state the next decision reads.

Aerospike serves as PayPal's operational store for feature access and model execution, using memory and SSD together. It handles more than 8 million database operations per second, with about 75% of risk calls completing in under 50 milliseconds. It does that with 8x fewer servers than before its migration to Aerospike.

Agentic fraud workflows will push the same loop even harder. An agent investigating a suspicious pattern cross-references entity graphs, coordinates across several risk models, and chains many steps, each one a read or a write against the data layer.

Is your data layer ready for agentic AI?

Models and compute get outsized attention, but the data layer is what keeps the operating loop turning. Agents multiply the reads and writes behind every decision. The question is no longer whether your data layer is fast enough, but whether it stays fast as agents multiply the load.

The Aerospike operational AI workload assessment checks your workload against the dimensions in this post, whether apps or agents drive it. It guides you through charting your business initiative and the decisions it depends on, then tracing each decision through its time budget, the state changes involved, and the architecture behind it.

Along the way, it sorts what your production data already shows from the assumptions you still need to test. You come away with a clear view of how ready your data layer is on each dimension.