Vector databases, agent runtimes, model registries, feature stores, GPU clusters. Five foundational layers in the standard AI architecture diagram. If you consume a managed model, most are either features of software you already run or infrastructure for a problem you do not have.
Third of four groups in a component-by-component teardown. The overview is in The Enterprise AI Platform: What’s Left When You Unpack It, and the first two groups covered the model call and the quality bar.
Start with a Payment Variance
A claim paid less than the contracted rate, and someone has to work out why.
The reasons are known. The contracted rate was applied incorrectly. The service was bundled. A modifier changed the allowed amount. Patient responsibility was miscalculated. A sequestration adjustment applied. A prior overpayment was recouped.
Six checks. Revenue cycle teams have had that list written down for twenty years.
So run them. In parallel, since none depends on another. Collect what fires, rank by dollar impact, present with the supporting data. A model call reads the remittance narrative where one exists. Everything else is lookups and arithmetic.
That is not an agent. It is a function.
Agents: The Question Is Not Which Framework
The comparison usually offered is a managed agent service against an orchestration library. It is the wrong comparison — both require the same integration code. The lookups against your contract system, eligibility, and payer rules get written either way.
The real question is whether you let the model decide the sequence. Saying yes costs more than it appears:
- Every lookup must become independently callable with arguments the model generates, rather than called once with a validated parameter. That is a wider surface than you had.
- You cannot unit test the orchestration, because it is decided at runtime.
- A wrong sequence produces a plausible wrong answer with no error. Skip the check for an existing authorisation and you tell staff to submit a duplicate. Nothing failed. The answer just looked fine.
Those costs are real, but they do not make the pattern wrong. They make it something to earn.
Two Tests, and Both Must Fail
An agent is unnecessary only when the work fails both of these. Most arguments about agents conflate them.
Scope. Does the work stay inside one domain, or coordinate across systems that each own part of the outcome? Payment variance sits in one domain, against one set of contract and remittance data. A procurement workflow spanning contracts, supplier validation, approval routing, ERP posting and email does not.
Sequence. Is the path documented, or does it genuinely vary per instance? In mature single-domain work it is documented, or documentable in an afternoon with someone who has done it for a decade. Claims adjudication, underwriting, accounts payable exceptions, credit review. Across systems and business units the combinations stop being enumerable even when each individual step is known.
All five use cases in this series fail both tests, which is why none of them needs an agent. That is a fact about this portfolio, not about enterprises — and the portfolio was deliberately chosen from work that sits inside a single domain.
Cross-system automation is where the pattern genuinely begins, which is the argument I made in Realizing Enterprise Agentic Architecture. A customer service agent reaching across CRM, knowledge, ticketing and workflow, or a procurement agent coordinating contracts, approvals and ERP transactions, is doing something a function cannot reasonably express.
Where the reflex still deserves resistance is the single-domain case. Reaching for an agent because nobody wrote down the process is expensive avoidance — an analysis gap, not an architecture requirement.
And the runtime is not the decision. Deployment patterns, identity and authorisation, evaluation, observability, and lifecycle management are what a platform team actually provides. Those are the paved road. The framework is an implementation choice made underneath it.
Single domain with a documented path is a function. Cross-system coordination is where agentic architecture starts.
Retrieval: You Bought It Twice Already
Vector databases are presented as foundational infrastructure. Two things have happened since that diagram was drawn.
Vector search became a database feature. Postgres, OpenSearch, Elastic, Snowflake, Databricks, SQL Server, Mongo. If you run any of them, you already have it.
And purchased products ship their own. Any product doing document search, policy lookup, or knowledge assistance has retrieval inside it, indexed against its own content. You are not going to re-index your core platform’s knowledge base into your vector store, and you should not want to.
So the question is not which vector database. It is whether you need a retrieval step at all.
If the answer is a specific known record, look it up. Does this plan require prior authorisation for this procedure code? That is a filtered query returning a specific rule with a citation. Semantic search returns documents that resemble the question — and nearly right is useless when the answer determines whether you get paid, and unauditable when someone asks how you reached it.
Where retrieval genuinely applies, quality is determined by chunking, metadata, freshness, and citations. None of which is the database. And measure retrieval separately from the answer: if the right document was never retrieved, no prompt change helps.
The MLOps Layers, and an Important Exception
Model registry. Feature store. GPU infrastructure. Training pipelines and drift monitoring.
If you consume a managed model, all of it is irrelevant. Your model registry is a version identifier in a configuration file. There is no training pipeline, therefore no consistency problem between training and serving. There are no clusters to schedule.
The exception is real and worth stating plainly. Enterprises run predictive models — clinical risk scoring, propensity models, forecasting. Those genuinely need versioned artefacts, feature consistency, training lineage, and drift monitoring. Mature discipline, existing owners, legitimate components.
The problem is that most enterprise AI diagrams conflate the two stacks. An organisation running one risk model inherits the infrastructure requirements of a model builder, then applies them to its document extraction work as well.
And these systems increasingly sit in the same pipeline. A risk model produces a score, and a model call turns that score into something a clinician can act on. Two halves, two governance regimes, one seam.
The seam is where the risk concentrates, because it produces a failure neither half can detect: the score is correct and the interpretation is wrong. Both halves pass their own checks.
The practical rule is that anything mappable deterministically should be. A risk tier maps to protocol-mandated actions through a table, not a generation step. Reserve the model call for what genuinely requires synthesis, and most of the audit problem disappears with it.
One Boundary Worth Stating
This series is grounded in process automation — documents arriving, data read, a decision made, a system of record updated.
Decision intelligence is a different answer. Forecasting, margin analysis, churn, planning — work that reasons across enterprise data, metrics, policies, and history. That is where a lakehouse, retrieval, and a semantic layer stop being optional and become architectural capabilities.
The components dismissed on this page are not deletable there. They are deletable here.
Not every AI technology belongs in every enterprise architecture. The failure is applying one diagram to different classes of work.
Final Thoughts
A large share of published enterprise AI architecture is written for organisations that train and serve models, and consumed by organisations that call an API. Starting at layer one solves a problem you do not have.
Five layers. Four are not applicable to a managed-model consumer, and the fifth is a feature of a database you already run. The agent runtime is the one that turns on what you are automating rather than what you are buying.
Check what you already own.
Then check what problem you actually have.
Tech Canvas 