Blog

AI Agents

Building Model Agnostic Infrastructure for Agents

AI Agents

March 11, 2026

2 min

Michel Tricot

Summarize with AI:

Something keeps coming up in my conversations with founders building agents.

Everyone outside the arena obsesses over which model to use. Should we go with GPT-5 or Claude, Gemini or DeepSeek, or just wait for the next release?

But the AI engineers I work with who are actually shipping agents into production face a completely different set of challenges.

Rather than debating model quality, they tell me things like, "We built everything around OpenAI six months ago. Now we need Claude for long-context tasks and an on-premise model for our banking customers. Migrating is going to take us weeks."

I hear some version of this conversation every month. These infrastructure constraints, not model capabilities, become the limiting factor as teams scale from demos to production.

That migration cost is a recurring tax that compounds with every shift in the model landscape. Teams that built with abstraction layers swap providers through configuration changes. Teams that optimized around a single provider's patterns face weeks of rework every time something better comes along. I've watched that single decision define who ships fast and who stalls.

The most consequential infrastructure decision you'll make is whether your architecture treats model choice as a configuration option or an architectural commitment.

The Current Model Landscape and Why It's Temporary

The question of which model is "smartest" barely scratches the surface of what's actually happening. What's caught my attention over the past year is how quickly the axes of competition have multiplied, and how each new axis reshapes what's architecturally possible.

Consider context windows alone. Two years ago, 4K tokens was the standard, and now Claude Sonnet 4.6 and Opus 4.6 offer up to 1M tokens, Gemini 3.1 Pro offers 1M, and Llama 4 Scout pushes to 10M.

I've seen teams processing legal documents, codebases, or massive conversation histories reroute those tasks to Claude, Gemini, or Llama overnight, because the jump from 4K to millions of tokens doesn't just improve existing workflows, it makes entirely new ones feasible, like ingesting a full codebase or analyzing hours of video in a single pass.

Reasoning Over Raw Power

But context is only half the equation, because the reasoning axis cuts in a completely different direction.

OpenAI's o3 and o4-mini models are slower but dramatically more accurate for complex logic, math, and multi-step analysis. You wouldn't use them for routine tagging or sentiment checks, but for contract analysis or scientific reasoning, they outperform general-purpose models by a wide margin. GPT-5.2 remains the flagship general-purpose model, but for many tasks, you're paying for reasoning power you don't need.

That waste is invisible until you measure it.

Cost, Compliance, and the Open-Source Alternative

Neither context nor reasoning matters much when a banking customer tells you their data cannot leave their infrastructure. Cost and compliance create yet another dimension, and this is the one I see playing out most constantly.

DeepSeek V3 delivers competitive performance at a fraction of the cost of frontier models, and it's open-source, as are models like Llama 4 and Mistral Large 3, which enable on-premise deployment for organizations with compliance requirements.

For teams managing unit economics, routing appropriate tasks to these models can cut costs without meaningful quality loss while keeping data exactly where regulators demand it stays.

Fragmentation Is the Future

Every one of these models carries different pricing, latency profiles, context windows, and failure modes. What works for customer support doesn't work for code generation, and what works for quick entity extraction is wasteful for multi-step reasoning. This diversity will only increase. It will not consolidate.

Think about how data infrastructure evolved. We didn't end up with one tool to rule them all. Data teams adopted Airflow, dbt, Kafka, Spark, and dozens more, each tuned for a different problem. I saw this firsthand, and the companies that thrived built architecture-agnostic layers that let them adopt new tools, distributed systems, and cloud platforms without fundamental rewrites.

The same pattern is emerging with models. Teams are discovering that a single model doesn't work across their full range of tasks. Some need maximum reasoning power, others need blazing speed at minimal cost, and some require on-premise deployment for compliance. Others are moving toward model councils, running the same task through multiple models to produce a consensus result, the way Perplexity already does. The winners will treat model selection as composable and configurable, and the losers will be the ones still trying to renegotiate a single provider's roadmap when the market has already moved on.

Betting on a single model is betting against history.

What Model Agnostic Actually Means

The first mistake teams make is assuming model-agnostic means supporting every model equally. The goal is narrower and more practical, which is to build abstraction layers that make model choice a configuration decision rather than an architectural one.

A tightly coupled approach weaves one model's assumptions throughout your application logic. Your orchestration layer is designed around OpenAI's response format, your error handling reflects Anthropic's rate-limit behavior, and your prompt templates follow Claude-specific conventions. The architecture doesn't just use a model, it's shaped by it. I've seen codebases where this coupling runs so deep that teams can't even estimate the migration effort, let alone schedule it.

Here's what building directly against a single provider looks like in practice:

from openai import OpenAI2
client = OpenAI()
response = client.chat.completions.create(
    model="gpt-5.2",
    messages=[{"role": "user", "content": prompt}],
    temperature=0.7
)
answer = response.choices[0].message.content

A model-agnostic approach puts a clean interface between your application logic and model interactions. Your code calls something like generate_response(prompt, config) and the infrastructure handles the rest, including which model runs, how the request is formatted, and how errors are retried.

response = model_client.generate(
    prompt=prompt,
    config={
        "provider": "anthropic",
        "model": "claude-sonnet-4.6",
        "temperature": 0.7
    }
)
answer = response.content

The Iceberg We're Not Talking About

If the current model landscape already demands this level of flexibility, what's coming next makes it non-negotiable. LLMs are currently the most visible model type, and this is the part that keeps me up at night. They're just the tip of the iceberg.

World models are emerging that understand and simulate physical environments, predicting how actions affect the real world across causality, state changes, and physics. They share almost nothing architecturally with text-in, text-out LLMs, which means the abstraction layer that wraps one won't naturally accommodate the other.

Physical AI and embodied models built for robotics integrate perception from cameras and sensors, reasoning for planning, and actuation for motor control. A robot navigating a warehouse needs a very different model architecture than a chatbot answering support questions, yet both will live inside the same enterprise system.

Specialized reasoning models are fragmenting the landscape further. The o-series showed that reasoning can be a distinct capability worth dedicating an entire model to, and we're already seeing the same happen with math-specific and code-specific models.

Audio models handle speech synthesis and recognition, vision models generate and analyze images, and multimodal systems combine these capabilities in ways that didn't exist eighteen months ago.

Each new model type is another integration point, and each integration point either flexes or fractures under pressure.

What does this look like in practice? A logistics company's agentic system might need an embodied AI model to coordinate warehouse robots picking and packing orders, a reasoning model to plan delivery routes across thousands of variables, and an LLM to process shipping documents and handle customer communications. No single model can do all three. The infrastructure connecting them needs to treat each as an interchangeable component rather than a fixed dependency.

The infrastructure you build today needs to accommodate model categories that don't exist yet, and if your architecture assumes text-in, text-out LLMs, you'll need to rebuild when you integrate a world model or a robotics perception system.

This shapes how we think about our own architecture, and honestly, we don't have all the answers yet. But the abstraction layer you design now should be flexible enough to wrap any model interface, not just today's chat completion APIs. Teams that get this right won't even notice when the next model category arrives. Teams that get it wrong will be scheduling another migration.

Architecture Patterns for Model Agnosticism

I'm an infrastructure person, and I've seen every infrastructure shift follow the same pattern. You always have three pillars in compute, storage, and networking, and model-agnostic architecture is no different.

You need clean boundaries between the layers and clear separation between how you handle computation, how you persist and organize data, and how you enable systems to communicate.

Let me walk through how I think about each one.

The Unified Model Interface

A unified model interface layer abstracts provider-specific APIs behind a common interface, so your application code calls a standard set of methods and the infrastructure handles formatting requests for OpenAI, Anthropic, Google, or local models.

In practice, this layer handles three kinds of normalization. Request normalization converts your standard format into each provider's expected format, response normalization converts each provider's output into a consistent structure your code expects, and error handling normalization maps provider-specific failures like rate limits, timeouts, and auth errors into a common taxonomy your retry logic understands.

When a new provider launches, you write one adapter. Every service that uses models gets access immediately. I've seen teams go from "we need to support a new model" to production in an afternoon once this layer exists.

Model Routing and Orchestration

A model routing and orchestration layer decides which model handles each task based on cost, latency, capability, and compliance requirements. A sentiment check routes to a lightweight model, a multi-step research synthesis goes to a frontier model, and anything touching regulated data routes to an on-premise deployment.

When multiple agents work together, coordination logic shouldn't be entangled with model-specific assumptions. Task routing between agents, reliable tool use, and resilient error handling all live in this layer. This separation ensures agents can be switched or upgraded without rebuilding the entire workflow architecture, and it's where the economics of model agnosticism shift from theoretical to measurable.

Governance, Observability, and Data

A governance and observability layer audits model interactions regardless of provider. Every agent action should be traceable back to the information that informed it, and that traceability can't depend on knowing the specific model provider. Your audit logs, policy enforcement, and access controls need to work the same way whether the request goes to OpenAI, Anthropic, Google, or a model running in your own environment.

Your data layer, including connectors that feed context to agents, should also be model-agnostic. A well-designed connector layer moves data from SaaS tools, databases, and APIs into agent workflows without knowing what model sits downstream. The moment your data infrastructure is coupled to a specific model, you've traded one lock-in for another.

Open standards make all three layers practical. MCP gives you a standardized way for agents to interact with tools regardless of which model is driving the interaction. A little over a year ago, every platform had its own connection patterns. Now one standard protocol works across models, platforms, and tools. These standards reduce the cost of staying flexible to near zero, while the cost of being locked in only climbs.

The Economic Case for Flexibility

The cost of sending every request to the same model is invisible until you measure it, and this is where the conversation usually gets people's attention.

A simple classification task like routing a support ticket to the right queue doesn't need GPT-5.2. A lightweight model handles it faster and at a fraction of the cost. Complex reasoning, like analyzing a contract clause against company policy, benefits from a more capable model. Sensitive data processing might require an on-premise model regardless of performance, because compliance demands it. Sending every task to the same model means overpaying for the simple ones and under-serving the complex ones, and most teams don't realize the magnitude until they run the numbers.

Take a support ticket classifier handling 10,000 calls per day. Depending on prompt complexity, GPT-5.2 pricing puts that somewhere between $600 and $1,500 per month. Route those same calls to a fine-tuned open-source model on your own infrastructure, and that drops to $150–$300 per month. Even at the low end, that's thousands saved annually on one task alone. Multiply across every summarization, extraction, and routing task in your pipeline, and model routing pays for itself within the first quarter.

A routing layer makes this possible by evaluating each task and selecting the best model based on complexity, latency requirements, and cost constraints. A well-designed router sends the majority of requests to a cheap, fast model and reserves the expensive frontier model for the minority of tasks that actually need it.

Teams locked into a single provider pay premium prices for every task because their architecture can't route by task type. So they don't switch, and the overspend becomes permanent. I've watched teams accept this cost for months because the migration work never rises to the top of the backlog.

The gap widens every quarter, because as new models emerge with better price-performance ratios, model-agnostic teams adopt them immediately. Locked-in teams fall further behind with each release.

The Database Independence Analogy

We've seen this movie before, and I've lived through it personally.

In the early 2000s, companies built applications directly against Oracle. They embedded Oracle SQL throughout their codebases, stored business logic in Oracle-specific procedures, and wrote every query against Oracle's dialect and behavior.

When Postgres matured, when MySQL became viable for production workloads, when distributed databases emerged, those companies often couldn't adopt them. Switching databases meant rewriting queries, extracting business logic from stored procedures, and rebuilding data access layers. The migration costs ran deep, both in engineering time and organizational effort.

The companies that thrived had invested in database abstraction layers, using ORMs, connection pools, and query builders that worked across database engines. When they needed to switch from Oracle to Postgres for cost reasons, or add a Redis cache layer, they completed the migration in days rather than months.

Model lock-in is following the same script. When your codebase is built around one provider's patterns (its response formats, its error behavior, its prompting conventions) migrating to Claude or Gemini means reworking the architecture, not just swapping an import. Teams that optimized around the model du jour twelve months ago are living this right now.

The lesson from infrastructure history is clear, and it's one I come back to constantly. Value accrues to the layers that make raw technology dependable and interchangeable, not to the raw technology itself. APIs existed for years before Stripe and Twilio made them reliable. Cloud computing was available long before AWS made it accessible. The breakthroughs were the infrastructure layers that made the underlying technologies dependable at scale, and whoever builds those layers for AI models will capture the same kind of value.

Building for Tomorrow

The roadmap toward model-agnostic infrastructure starts with measurement, so audit your current codebase for model-specific dependencies. Search for provider-specific imports, API calls, and response parsing. Count how many files would need to change if you switched from OpenAI to Anthropic tomorrow. That number is your technical debt measurement. When I suggest this exercise to teams, the result usually surprises them.

Once you have that number, the next step is introducing abstraction layers between your application logic and model interactions. Start with a simple interface that defines what your application needs from a model, whether that's text generation, classification, or embedding, without specifying which model provides it. Route all model calls through this interface.

From there, adopt open standards like MCP for agent tool exposure. The Model Context Protocol gives agents a standardized interface to call tools and services, and keeping your tool layer composable and independent of your model layer matters just as much.

The abstraction layer gets you flexibility. A model routing layer gets you economics. Go beyond abstracting the interface and build logic that selects the right model for each task. Start simple by routing by task type, then over time add cost awareness, latency-based routing, and fallback chains that automatically switch providers when one is down.

Finally, separate your data infrastructure from your model infrastructure. Your connectors, governance, and context assembly should work regardless of which model consumes the data. Think of it like onboarding a new employee. You hand them access to the company's systems, documents, and tools, and they figure out how to use those resources to get the job done. Your data layer should be the last thing you worry about when swapping models.

The discipline matters most for new agent development. Make it a rule that no model-specific assumptions belong in application code. Every model interaction flows through your abstraction layer, and every new model you need to support is a configuration change rather than a code change. Teams that enforce this now won't have to learn it the expensive way later.

Where We Go From Here

The model race is visible and thrilling. Every quarter brings announcements that push capabilities forward. But the decisive work is happening where fewer people look.

It's happening in the plumbing, in the abstraction layers that let you swap providers without rewriting your stack, the routing logic that sends each task to the right model for cost and performance, and the governance layers that audit agent actions without caring which model made the decision.

LLMs are just the opening act. The technology is evolving too fast to commit to a specific model stack today. World models, embodied AI, and specialized reasoning engines are arriving now. Flexible foundations turn tomorrow's breakthroughs into marginal upgrades, while tightly coupled architectures turn them into expensive rewrites.

And those breakthroughs will arrive, probably sooner than anyone expects.

Your current model will be replaced. The only question is whether your infrastructure will make that replacement trivial or traumatic.

You already know what to do. Run the audit, and if the number is small, you're ahead of most teams. If it's large, every day you wait makes the eventual migration more expensive.

Subscribe to Agent Blueprint to learn more about agentic data infrastructure.

Limitless data movement with free Alpha and Beta connectors

Introducing: our Free Connector Program ->