The AI Compute Constraint and the Case for an Intelligence Layer
Article
The AI Compute Constraint and the Case for an Intelligence Layer
On May 6, Anthropic announced a new compute partnership with SpaceX. Buried in the announcement was a number that should reframe how every CIO in a regulated industry plans their 2026 AI roadmap: Anthropic is projecting roughly 80x demand growth in Q1 2026.
If that number holds, the race has shifted to compute, infrastructure, and orchestration capacity. The winners will be the enterprises that build an Intelligence Layer: the discipline and architecture to know when not to use frontier models.
For the last couple of years, enterprise AI strategy has had a simple shape: pick a frontier model, point your workflows at it, and let intelligence flow. That worked when usage was experimental, costs were absorbed in innovation budgets, and compliance teams hadn’t yet asked the hard questions. It doesn’t work at the scale we’re now entering.
Three forces are converging on enterprise AI:
Frontier capacity is constrained, and the constraint is physical.
Anthropic's deals with SpaceX, Amazon, Google, Microsoft, and NVIDIA are a signal. The frontier labs themselves are telling us the binding constraint has moved from capability to capacity.
Frontier models are economically inappropriate for most enterprise tasks.
A regulated bank doesn't need a trillion-parameter reasoning model to classify a transaction or route a service ticket. Sending those tasks to a frontier endpoint is the equivalent of dispatching a corporate jet to pick up the mail. It works. But it also burns capital that should be funding actual differentiation.
Regulated industries can't tolerate opaque dependencies on a single model path.
When every workflow is wired directly to a frontier API, you inherit that vendor's outages, rate limits, data residency posture, and pricing changes, with no control plane to absorb the shock. For a CIO at a regulated institution, that arrangement belongs on a risk register, not an architecture diagram.
The architectural conclusion: an Intelligence Layer
The strategic message is clear: frontier intelligence is becoming too expensive and too scarce to sit in the direct execution path for every request. Enterprises that recognize this are moving toward an architecture where frontier models are a selectively-invoked resource rather than the default destination for every request.
We call this an Intelligence Layer, and it sits between your business systems and the model landscape. It does five things:
- Routes each request to the right tier of intelligence (frontier, specialized, classical ML, or a deterministic rule);
- Governs policy, data residency, masking, and audit at the routing point before any data leaves your environment;
- Contextualizes the right enterprise data into the right prompt without leaking the rest of the warehouse;
- Orchestrates multi-step agent workflows so a single business task doesn’t become a hundred opaque API calls; and
- Observes every decision, model call, cost, and latency, turning AI from a black-box expense into a measurable operational system.
Framed plainly, the Intelligence Layer is the economic control plane for enterprise AI. It’s what allows a CIO to answer the questions a board is starting to ask: What did AI cost us this quarter? Which workloads drove the cost? Which of those workloads needed a frontier model? Are we compliant? Are we resilient if our top vendor has an outage tomorrow?
The opportunity hiding inside the constraint
Here’s the part that gets missed in the headlines about GPU shortages and gigawatt deals: scarcity is clarifying. It forces enterprises to ask a question they should have been asking all along, “What is the right intelligence for this task?” instead of defaulting to the most intelligence for every task.
Banks that get this right will see lower AI run-rates, faster compliance reviews, and better outcomes from the workflows that genuinely need frontier reasoning, because those calls will no longer be competing with thousands of trivial requests for the same capacity.
IT leaders who get this right will have something they can defend in front of a board, a regulator, and an auditor: a documented, observable, governed system for deploying AI — not a collection of integrations stitched into production.
The compute race that Anthropic’s announcement signals is real, and it will reshape the economics of this industry. But for the CIO of a regulated enterprise, the strategic question is less about how much frontier capacity you can secure and more about how much of your business genuinely needs it, along with how disciplined you are about routing the rest.
That discipline is the moat, and the Intelligence Layer is how you build it.
Memory-Centric AI: Your Real Advantage Isn't the Model
Article
Memory-Centric AI: Your Real Advantage Isn't the Model
In April 2026, Andrej Karpathy published a short essay on Wikis for LLMs. His argument: the enterprises that win with AI will be the ones that build, govern, and refine the curated knowledge their AI systems draw on, not the ones with access to the best models.
For a CIO in a regulated industry, that argument lands differently than it does for a startup. The shift from model-centric to memory-centric AI is the most important reframing of enterprise AI in the past year, with direct implications for how you spend your 2026 AI budget.
The Shift from Model-Centric to Memory-Centric AI
For three years, enterprise AI strategy has been organized around models. Pick the best one, prompt it carefully, and upgrade when something better ships. Performance, in most board decks, is a function of model capability.
That framing is starting to break.
CIOs running these systems in production are finding that two enterprises using the same frontier model can produce wildly different AI outcomes. The variable is what the model has been told about the business: the policies, definitions, prior decisions, escalation paths, and institutional rules that turn a generic LLM into something that behaves like a useful colleague.
Karpathy gave that body of knowledge a name: a wiki for the LLM. We’ve been building it under a different name — resolutions — inside our IT operations agent for months. The terminology matters less than the architectural conclusion both arrive at: the durable AI advantage is the curated memory the system draws on, not the model it calls.
What This Looks Like in Practice
Consider a recurring problem in IT operations: a Windows build update fails on an end-user device. A model-centric approach treats every occurrence as a fresh prompt and the work product evaporates the moment the ticket closes. A memory-centric approach captures the resolution as a structured, durable artifact that records the context, troubleshooting steps, and escalation criteria. Every subsequent occurrence draws on it, so the model applies a vetted answer instead of re-deriving one.
The economic difference is significant. Inference costs drop because known problems stop consuming frontier compute, and resolution times drop because the system is executing rather than reasoning. For a regulated environment, the bigger payoff is auditability: you can point a regulator at the exact knowledge artifact that produced an outcome.
The Failure Mode No One Warns You About
There is a specific risk in memory-centric AI that we’ve watched play out in real systems, and it deserves a CIO’s attention before it shows up in your environment. We call it error baking.
When AI systems enrich tickets, documents, or workflows by drawing on prior outputs, any error embedded in those prior outputs gets reused, reinforced, and amplified. A resolution that was 80% correct becomes the source material for the next resolution, which is now 75% correct, which trains the next one, and so on. There is no single moment of failure, just a subtle compounding drift.
The fix is governance at the memory layer, not better models: a reviewed, version-controlled knowledge base the AI is allowed to draw on, kept separate from the raw outputs it generates. Without that separation, your AI gets worse over time, in ways that are nearly impossible to detect from outside the system. With it, the system improves with every resolved incident, because every resolved incident becomes a vetted asset the next one builds on.
For a CIO in a regulated industry, this is the difference between an AI investment that compounds and an AI investment that decays.
Owning The Memory Layer
The memory layer is not documentation, and it is not a side project. It is infrastructure. It belongs in the same conversation as your data warehouse, access controls, and audit logs — because functionally, it is all three.
Three questions a CIO should be asking now: Where does our AI’s institutional knowledge live today — in prompts, in chat histories, in individual employees’ heads, in scattered Confluence pages? Who owns the curation, review, and version control of that knowledge? Can we point an auditor at the specific artifact that produced a given AI output?
In financial services, healthcare, and government IT, the answer to that last question is going to determine which AI workloads are allowed in production at all.
The Reframe
The competitive advantage in enterprise AI will not belong to the organizations that access the most capable models. Those models are becoming a commodity, available to your competitors on the same terms they’re available to you.
The advantage will belong to the organizations that own — and govern — what their models know.
That asset compounds, a regulator can inspect it, and a competitor cannot replicate it by signing a different vendor contract.
The model is rented. The memory is yours.
AI is Only As Good As Your Data
Article
AI is Only As Good As Your Data
Every week, another AI vendor promises their platform will transform your financial institution. Better member insights, smarter lending decisions, and automated reporting. The pitch is compelling and the pressure to act is real.
Before you sign a contract, there’s a question worth asking: Do you actually have the data to back it up?
AI is only as good as the data underneath it. And most financial institutions don’t have the data that’s ready for AI yet.
The key is starting with your data foundation first.
For financial institutions, the challenge isn’t the amount of data, it’s the data readiness. When you skip the step of cleaning and structuring your data and go straight to the AI layer, here’s what happens:
- The AI produces answers that feel authoritative but are statistically probable, rather than being declaratively accurate.
- You can’t audit the decision: you don’t know why it said what it said.
- You keep running the same calculations over and over, driving up costs with every query.
This isn’t a tech failure. It’s a sequencing failure. The intelligence has to be built into the data before you hand it to an AI.
What "AI-Ready Data" Actually Means
AI-ready data has been transformed, enriched with business logic, and structured so that when a question is asked, the answer is calculated, not guessed.
Think of it this way: if you ask an AI to tell you which members are at risk of leaving this quarter, it needs more than raw transaction records. It needs a unified view of each member’s relationship with your institution, behavioral signals over time, and the business rules your team uses to define “at risk” in the first place. That context must be built in.
The intelligence is in the platform. You must build it into the data layer before AI can deliver answers you can trust and act on.
Two Approaches and Why They're Not Equal
Approach One: Ask the AI to Figure It Out
Some vendors take raw data, often pulled from a cloud warehouse, and let the AI model do the calculations on the fly. The model ingests your data, runs its analysis, and returns an answer.
This sounds efficient. It’s not. Every calculation runs repeatedly, consuming tokens and compute resources with each query. Costs scale with usage, not with value. And when you ask, “why did you flag this member?” the answer is a statistical distribution, not a reason.
Approach Two: Pre-Compute the Intelligence
The more effective approach, and the one Aunalytics is grounded in, is to do the hard work before the AI ever sees the question. Every relevant metric, every business rule, every behavioral signal is calculated, validated, and stored in a structured intelligence layer.
When a question comes in, the AI retrieves a precise answer from data that was already prepared for it. The result is faster, cheaper, more accurate, and fully auditable.
This is what we mean when we say Aunalytics makes data AI-ready.
What This Means for Your Institution
If you’re a CEO, CIO, or CTO at a financial institution, this distinction matters for three reasons:
- Accuracy: Declarative answers built on prepared data are more reliable than probabilistic outputs from raw data. When a banker acts on an insight, they need to trust it.
- Auditability: Regulators and examiners want to know why a decision was made. With pre-computed intelligence, you can show your work. With probabilistic AI, you can’t.
- Cost: Paying for compute on every query — at scale — adds up fast. Pre-computed data means you’re paying for results, not repeated calculations.
The Partner Question
Most community financial institutions don’t have the data science teams, the infrastructure, or the time to build this foundation themselves. They don’t need to.
But they do need a partner who’s already done the work — one who understands community banking deeply and can deliver production-ready AI data as a service.
That’s not a software tool. It’s not a dashboard. It’s a managed service built on years of experience working with the specific data structures, core systems, and regulatory environment of community banks and credit unions.
Aunalytics has been building and refining banking-specific data sets for over eight years. The Intelligent Data Warehouse isn’t a general-purpose platform adapted for banking. It was built for banking from the ground up.
Before you evaluate the next AI platform, ask the vendor one question:
What does your solution do to prepare my data for AI before the AI ever touches it?
The answer will tell you everything.
Start With the Right Foundation
The institutions that will win with AI aren’t the ones who adopt it fastest. They’re the ones who build the right foundation first — and find a partner who can help them get there without building a data science department from scratch.
