Prompt

What infrastructure should I use for AI-native applications?

Technology · Developer Tools / Developer tools2 observationsLast seen Jul 15, 2026

Latest observation

Jul 15, 2026 · ClaudeWeb search: on

Here's the current picture of what infrastructure an AI-native application actually needs, layer by layer:

Model layer (the "brain")

  • Closed/API-based models (OpenAI, Anthropic, Google) — low upfront cost, scale linearly, but can get expensive fast at volume
  • Open/self-hosted models — lower marginal cost at scale, but you own the serving infrastructure
  • Most real systems in 2026 are moving from single-model prompting toward composable, swappable models — architecting so you can route between providers rather than hardcoding one

Orchestration layer (the "nervous system")

  • Where reasoning, decision-making, and multi-step coordination happen — this is your agent loop: planner, tool registry, memory, routing
  • Notably, this layer has commoditized faster than expected — a year ago, picking a runtime was the single most consequential decision in an agent project; in 2026 it mostly comes down to fit with your existing stack rather than a make-or-break choice Coding-specific harnesses (Claude Code, Cursor's agent mode, Replit Agent) now ship the whole loop pre-wired as a product, rather than requiring you to assemble LangChain/LlamaIndex primitives yourself

Tooling/integration layer (the "hands")

  • Where the agent actually acts on the world: calling APIs, pulling/pushing data, interacting with other software
  • Building to open protocols pays back over time — when a tool publishes an MCP server, every compatible harness can call it without custom integration work; when agents speak agent-to-agent protocols, handoffs between systems don't require bespoke glue code. Custom point-to-point integrations carry a long maintenance tail by comparison

Retrieval and context (what used to just be "RAG")

  • The framing has broadened: retrieval is now understood as one move inside a larger context problem — getting the agent trustworthy information in a usable shape, not just a vector search step
  • The teams making real progress here treat retrieval as an evals problem first, infrastructure problem second — the infrastructure (vector DB, embeddings, chunking) is necessary but not sufficient without systematic evaluation of what's actually being retrieved

Memory layer

  • What the agent retains across sessions/tasks — increasingly its own infrastructure concern distinct from retrieval, with teams treating memory, artifact reuse, and versioning as core engineering practice rather than an afterthought

Serving/inference infrastructure

  • Docker for packaging models with dependencies, Kubernetes for orchestrating scaling, API gateways for managing inference endpoints — this is the now-standard cloud-native baseline GPU clusters for fine-tuning, vector databases for embeddings, and specialized LLM-serving infrastructure (vLLM and similar) are the AI-specific additions beyond a normal microservices stack

  • Inference is overtaking training as the dominant compute demand — a real driver behind why serving infrastructure (not just training clusters) is getting so much fresh investment right now

Two things that cut across every layer above, not sitting in any one of them

  • Observability — needs to span models, data, and infrastructure jointly, not just traditional app performance monitoring; you need to see how changes in one layer affect the others
  • Governance and security — RBAC, audit logs, data residency/sovereignty, and guardrails need to be designed in from the start rather than bolted on, especially if you're in a regulated industry

Practical starting point depending on your situation

  • Startup/small team: lean on managed model APIs, a coding harness with the loop pre-wired (Claude Code, Cursor), MCP-compatible tools where available, and a managed vector DB — don't build your own orchestration or serving infrastructure until you have a concrete reason to
  • Enterprise with data sovereignty needs: look at AI-native platforms that run models on your own infrastructure rather than sending data to external APIs (this is the core differentiator enterprise AI-native platforms like Azure AI, Vertex AI, or Bedrock AgentCore are selling)
  • Anyone doing custom infrastructure provisioning: this is increasingly automated too — infrastructure-from-natural-language tools can generate governance-compliant environments in minutes rather than requiring hand-written Terraform and a multi-day review cycle

Observation history

See 1 earlier observation

Create a free Obsurfable account to unlock historical responses, model comparisons, and deeper brand intelligence.

How did Obsurfable measure this prompt?

Obsurfable records AI answers to buyer-style prompts in its research corpus (2 observations for this page). Metrics are distributions over observations, not a single static ranking.

Which AI systems does Obsurfable collect answers from?

OpenAI, ChatGPT, Google, Gemini, Google AI Mode, Anthropic, Claude, Perplexity, Grok, DeepSeek, Mistral, Copilot, and Meta AI.