This topic now lives on one canonical page
This earlier agent-context article was merged into the canonical 2026 live-infrastructure context guide.
Read the canonical articleYou ran a migration script that Claude Code generated for you. It looked right. The logic was sound, the SQL was clean, and you'd been working with that agent for hours. Then it hit production and broke things.
Or maybe Codex wrote you a Kubernetes manifest with a hardcoded namespace. You deployed it. The namespace didn't exist in your cluster. The error message was cryptic. The fix was obvious in retrospect — but you lost an hour.
These aren't model quality issues. Claude Code and Codex are capable agents. The problem is that they were guessing about your infrastructure, because no one told them what was actually running. This is an AI agent infrastructure context problem, and it's extremely common among teams who've started using AI agents for real production work.
The good news is that it's fixable at the tooling level. Here's what's happening and how to address it.
What AI Agents Actually Know
When you open a Claude Code session or spin up Codex CLI, the agent has access to a few specific things:
- Your codebase, if you've added it to context
- Your current prompt and conversation history
- Its training data — a snapshot of the world up to some cutoff date
- Whatever you've pasted in manually
That's it.
The agent has no idea what's running in your production environment right now. It doesn't know your current Kubernetes pod count, which services are healthy, what environment variables are set in prod, whether your last deployment changed the DB schema, or what your actual resource utilization looks like. It has never seen your infrastructure. It's working from a model of what infrastructure generally looks like, combined with whatever fragments you happened to include in your prompt.
This is the gap that causes production surprises. Not hallucination in the classic sense — the agent isn't making things up arbitrarily. It's doing something more subtle and harder to catch: it's making reasonable inferences from incomplete information, and those inferences are sometimes wrong.
What Happens When Agents Guess
Let's make this concrete.
The drifted schema. Your prod database has been running for 18 months. Migrations have been applied incrementally. A few columns were renamed. One table was split. The schema in your codebase is close to current, but not exactly current. You ask Claude Code to write a migration to add a new feature. Claude Code reads your codebase schema, infers what prod looks like, and writes the migration. The migration assumes a column name that was actually renamed six months ago. You run it in prod. It fails — and depending on the migration, it may leave your DB in a partially-applied state.
The wrong namespace. You ask Codex CLI to generate a Kubernetes manifest for a new service. Codex has your repo for context but not your cluster state. It makes a reasonable assumption about your namespace structure based on what it sees in other manifests. That namespace is a staging namespace that doesn't exist in your prod cluster. You run kubectl apply. The error is not immediately obvious. You spend time debugging a deploy that failed for a trivially fixable reason that the agent simply didn't know about.
The stale health check. You're using an OpenClaw agent to help monitor your services. Earlier in the session, you pasted in a status summary of your running services. That was two hours ago. Since then, your payment service has started returning elevated error rates — not enough to trigger your alerting threshold, but a real signal. You ask the agent whether the payment service looks healthy. The agent answers based on the context you gave it two hours ago: yes, looks fine. You move on. An hour later the issue escalates.
The already-done optimization. A Hermes agent is helping you with cost optimization across your cloud spend. You gave it a snapshot of your resource allocations from last week's infra review. Since then, your team already right-sized three of the largest instances. The agent recommends those same optimizations — work that's already done. Smaller issue, but it erodes trust in the agent's outputs and wastes time re-checking its recommendations against reality.
All of these share the same root cause: the agent didn't have live infrastructure context. It was working from stale or absent information about your actual environment.
The Fix Is Live Context, Not Better Prompts
The instinct most people reach for first is to paste more into the prompt. Add the current schema. Add the kubectl output. Add the cost report. This works — until it doesn't.
Manually injecting context has real limits. It's stale the moment you paste it. It's incomplete because you don't always know what context the agent will need. It's tedious because you're doing a lot of copy-paste work that should be automated. And it doesn't scale: if you're running an agent autonomously on a task that touches multiple services, manually supplying context at each step isn't realistic.
You're patching a structural problem with duct tape.
The structural fix is giving the agent a live, machine-readable connection to your actual infrastructure state — one that the agent can query as it works, rather than one you have to supply upfront. That's what the Model Context Protocol enables.
What MCP Is (In One Minute)
MCP — Model Context Protocol — is an open standard for letting AI agents call external tools in a structured way. Think of it as a bridge between an AI agent and an external data source.
Without MCP, you're the bridge. You read your infra, you summarize it, you paste it in. With MCP, the agent calls a tool directly. It asks "what namespaces exist in this cluster?" and gets a live answer. It asks "what is the current schema for the payments table?" and gets the actual current schema. It asks "is the payment service healthy?" and gets a real-time response — not whatever you happened to paste in two hours ago.
MCP is already supported by Claude Code, Codex CLI, OpenClaw, and LangChain-based agents like Hermes. The protocol is open, so any agent that implements MCP tooling can connect to any MCP server. The infrastructure side just needs to expose a compliant endpoint.
What Clanker Cloud Exposes via MCP
Clanker Cloud is a local-first desktop app that connects to your cloud infrastructure and exposes it as a standards-compliant MCP server. When your agent connects to it, the agent gains access to a set of live tools:
- List running services — across AWS, GCP, Azure, Kubernetes, Cloudflare, Hetzner, DigitalOcean
- Check pod and container health — real-time status, not a snapshot
- Read environment variable names (scoped — never raw credentials or secret values)
- See recent deployments — what changed, when, and from which commit
- Query costs — current spend by service, resource, or time window
- Check network topology — which services can reach which, what's exposed
- Scan for misconfigs — common issues surfaced as structured data the agent can reason over
All of these are read-only by default. The agent can look, not touch. If you want the agent to take write actions — applying a manifest, scaling a deployment, triggering a rollback — that requires Maker Mode, which prompts you for explicit approval before anything changes in your infrastructure.
Clanker Cloud is local-first: the MCP server runs on your machine, not in a third-party cloud. Your cloud credentials stay local. You bring your own API keys. The agent's tool calls go from your machine to your cloud, not through an intermediary.
How to Connect Your Agent
Setup takes about five minutes:
1. Install Clanker Cloud desktop. Download from clankercloud.ai/account. Connect your cloud providers (AWS, GCP, Azure, Kubernetes, etc.) and generate an API key. The app starts your local MCP endpoint.
2. Configure your agent.
Claude Code — Add to ~/.claude/claude_desktop_config.json:
{
"mcpServers": {
"clanker-cloud": {
"url": "http://localhost:PORT/mcp",
"apiKey": "your-api-key"
}
}
}
Codex CLI — Add equivalent JSON config to your Codex config file. The structure mirrors Claude Code's MCP server configuration.
OpenClaw — Run:
openclaw mcp set clanker-cloud --url http://localhost:PORT/mcp --key your-api-key
Hermes / LangChain — Add the MCP tool adapter to your agent's tool list. Clanker Cloud's endpoint is compatible with standard MCP tool adapters for LangChain.
Full setup docs are at docs.clankercloud.ai.
3. Start a session. Once configured, your agent can call Clanker Cloud tools the same way it calls any other tool — automatically, as part of reasoning through a task.
What Changes Immediately
Before connecting live context, your agent operates in a local, static world. It knows your code. It doesn't know your infrastructure. Every time it needs to reason about what's running in prod, it guesses.
After connecting Clanker Cloud, the agent has a tool it can call to get real answers. When Claude Code is writing that migration, it can query the live schema before generating SQL. When Codex is writing a Kubernetes manifest, it can list your actual namespaces. When OpenClaw answers a health question, it pulls current data, not session history.
The agent is the same. The model is the same. The difference is the information it's working from. Same codebase, same agent, dramatically fewer production surprises.
This is what AI agent production awareness looks like in practice — not a smarter model, but a model that has access to the current state of the system it's working on.
For teams using AI agents across multiple services and environments, the leverage is even higher. An AI devops workflow where agents can query live state before taking action is categorically different from one where agents are pattern-matching against static context.
FAQ
Why does Claude Code sometimes give wrong answers about my infrastructure?
Claude Code doesn't have access to your live infrastructure by default. It can only reason from your codebase, your prompt, and its training data. When it needs to make assumptions about what's actually running in production — pod counts, schema state, environment config — it infers from what it has. Those inferences are often right but sometimes wrong, especially when your production environment has drifted from what the code suggests. This is an infrastructure context problem, not a model capability problem.
What is MCP and how does it help AI agents?
MCP (Model Context Protocol) is an open standard that lets AI agents call external tools in a structured way. Instead of you manually pasting infrastructure state into a prompt, an MCP-connected agent can query your infrastructure directly and get live data. The agent asks structured questions and gets structured answers — current pod health, real schema state, live cost data. It removes the manual context-injection step and ensures the agent is working from current information.
How do I give my AI agent access to live cloud data?
The practical path is to run a local MCP server that connects to your cloud providers and exposes their state as queryable tools. Clanker Cloud does this: install the desktop app, connect your cloud accounts, get an API key, and add a few lines of JSON config to your agent's configuration file. Claude Code, Codex CLI, OpenClaw, and LangChain-based agents all support MCP natively.
Is it safe to let my AI agent read my infrastructure?
Read access with proper scoping is low risk. Clanker Cloud's MCP endpoint returns environment variable names but never secret values or credentials. All connections use your own API keys stored locally — nothing routes through a third-party cloud. Write operations require explicit Maker Mode approval, so the agent can't make changes without you confirming them. If you're already giving agents access to your codebase, giving them read access to your running infrastructure via MCP is a comparable trust level with meaningful guardrails.
Give Your Agent Real Context
Your agent is only as good as the information it has to work with. Giving it live, structured access to your actual infrastructure state is the most direct way to reduce the gap between what it confidently produces and what's actually true in production.
Beta access is free. Lite starts at $5/month. If you're running production workloads with AI agents, it's worth the five minutes to connect.
Give your agent live infrastructure context
Download Clanker Cloud, expose the local MCP surface, and let coding agents work from current cloud, Kubernetes, GitHub, and cost state instead of guesses.