A coding agent knows one repository intimately. An operator has never had the luxury of one repository.
The knowledge problem in software operations is breadth across repos and time, not depth in a single codebase.
A drilling rig sinks a mile down into one spot and learns everything about that single column of rock. A surveyor's map covers the whole county. The map is thin at any individual point, but it becomes more valuable every time someone walks the land and records a fence line, a dry well, or a dirt road that was not there last year.
The drill is finished when it hits what it was looking for. The map is never finished, and that continuity is what makes it valuable.
Every AI coding tool on the market today is a drill. The operator needs a map.
What Does an Operator Actually Get Asked?
Software engineering tools assume that problems arrive neatly packaged. An issue gets filed, someone writes a ticket, a branch gets created, and an engineer opens an editor to change twenty lines of code inside a single directory.
Operators live in a completely different world. They rarely receive a curated task with clean boundaries. They receive open-ended problems that pull on invisible threads across the entire company:
"Set up a CI pipeline for staging."
On paper, this sounds like a weekend project. In practice, it touches twenty different repositories. Each service has its own build quirks, its own test suites, its own unwritten deploy dependencies, and its own base container images.
Making this work does not mean writing one workflow file. It means figuring out which service has to build first, which database migrations have to run before the web tier can start, and which three services nobody has touched in fourteen months because the original authors moved on.
"Rotate this database credential."
A junior engineer thinks rotating a secret in Vault takes ten seconds: you issue a new password and update the secret engine. A senior operator knows that doing that without checking the estate will bring down half the product by lunchtime.
You have to survey the entire landscape to find everything that quietly depends on that credential. The primary API service reads it through an environment variable injected by Kubernetes. A nightly accounting job reads it straight from a cron pod. A forgotten Grafana datasource was configured by hand two years ago to query read-replicas directly. And a Terraform module in an infrastructure repo baked the old connection string into an auto-scaling launch template three quarters ago.
None of those files are individually complicated. The danger is not understanding the syntax; the danger is missing the fourth place where the secret was copied.
"Why is Kafka consumer lag climbing?"
The producer code lives in a backend repository maintained by the application team. The consumer lives in a separate streaming repo maintained by data engineering. Its JVM heap settings and thread pools sit in a Helm values file in an infrastructure repository. The Kafka broker configuration itself is managed by Terraform in a fourth repository, and the cloud networking rules that govern partition rebalancing sit in a fifth.
To make matters worse, the engineer who originally tuned the batch sizes left the company six months ago.
No single one of these configuration files is hard to read. Reading a YAML file or an environment variable takes thirty seconds. The real work of an operations engineer is knowing which forty things to read, in what order to read them, and how they interact when traffic spikes on a Friday afternoon.
Why Repository-Centric Agents Hit a Wall
The current wave of AI developer tools (Cursor, Claude Code, GitHub Copilot, and their peers) are built around a single foundational assumption: the open project folder.
Their entire world begins and ends at the root of that local directory. Inside that perimeter, they are remarkably capable. They can refactor functions, trace type signatures, rewrite test suites, and explain complicated algorithms. They drill straight down.
The moment you bring them into an operational incident, however, the model falls apart.
1. The Silo Problem
If you open an agent inside the repository for the consumer service and ask why lag is increasing, it will analyze the consumer loop. It will tell you the code looks fine, suggest tweaking a local loop interval, or propose a minor refactor.
What it cannot tell you is that a producer deployment three hours ago in another repository doubled the message payload size, or that someone throttled the broker network bandwidth in a completely different cloud account. The agent cannot see those systems because they do not exist inside its project tree.
2. The Amnesia Problem
Coding agents treat every session as day one. When you close the terminal or clear the window, the context vanishes.
If you spend four hours on a Tuesday working through a messy networking bug caused by an edge case in your service mesh, that hard-won knowledge evaporates the moment the thread ends. When a related issue happens the following month, the agent starts from zero. It asks the same preliminary questions, suggests the same dead ends, and makes the same incorrect assumptions.
3. The Turnover Reality
Consider what happens when the staff engineer who built your deployment architecture leaves the company.
The code does not disappear. The repositories still sit in your git provider. The Dockerfiles and Helm charts are right where they were left. Yet the team is suddenly terrified to touch anything.
Why? Because what walked out the door was not the code. What walked out the door was the map.
That engineer knew which twenty services actually mattered, which alerts were safe to ignore during a deploy, which cron jobs could be killed without hurting revenue, and which database replicas were flaky under heavy writes. Code without operational context is an unmapped minefield.
Depth without breadth is just a drill sunk in the wrong field. Depth without memory is a drill that has to start over from the grass every single morning.
The Trap of the Infinite Context Window
The common response from the tooling industry is simple: make the context window larger. If an agent cannot see across twenty repositories, just dump twenty repositories into a two-million-token window and let the model sort it out.
This misunderstands the fundamental nature of operations.
Stuffing dozens of repositories, Terraform state files, and Kubernetes manifests into an enormous prompt does not create understanding. It creates noise. It slows down reasoning, drives up latency to unacceptable levels during live outages, and inflates costs.
More importantly, raw text is not comprehension. A senior operator does not keep forty complete codebases memorized character by character in their head. What they possess is an internal index: a working model of relationships, constraints, and operational history.
A bigger context window is just a bigger drill. It can dig a wider hole, but it still does not know where the town borders are, and it still does not draw the map.
What Does It Actually Mean to Know an Estate?
If we want to build AI that genuinely helps operators, we have to ask a different question. Not "how do we stuff more text into the prompt," but "what does an experienced operator know that a newcomer does not?"
Knowing an infrastructure estate is never about having read every line of code. Nobody has done that, and nobody needs to. Senior operators navigate production environments by holding four critical dimensions in their heads simultaneously:
1. The Entities
The living inventory of the system. This includes the obvious components like microservices, database clusters, caches, message queues, and load balancers.
It also includes the social and organizational realities that govern them: which team owns which service, who the on-call escalation contact is, and what the unwritten team habits are. Team A always pins container images by explicit digest, while Team B deploys directly from their default branch. Knowing these quirks is often the difference between a ten-minute fix and a three-hour incident.
2. The Relations
How those entities talk to one another in reality, rather than on an outdated architecture slide.
Which service reads from which database? Which background worker depends on which message topic? Which deploy has to complete and pass its health checks before the next service in line can be restarted? Infrastructure is defined by its edges, not its nodes.
3. What Actually Worked
The empirical history of past interventions. The official internal wiki almost always documents how an incident response was supposed to go. The operator's memory holds what actually worked when things went sideways at two in the morning.
They remember that restarting the ingest pod cleared the lock contention, that setting a specific worker count stabilized the memory leak, and that running a particular manual script was the only way to re-sync state safely. They care about proven remediation, not theoretical documentation.
4. Time and Drift
Infrastructure is not static; it is a historical record of compromises, migrations, and quick fixes.
The state of a system three months ago is often the only thing that explains an error happening right now. An experienced engineer is valuable because they remember that the database migration stalled halfway through last November, leaving an unindexed column behind. They remember that the third replica was provisioned as a temporary workaround during Black Friday and was never torn down.
To know an estate is to maintain an active, evolving world model that gets wider and more accurate with every shift. It cannot be a throwaway snapshot that gets wiped clean after every prompt.
The Principles Behind Kepler
At RubixKube, we built Kepler around accumulation rather than transient context.
Instead of treating operations as an isolated code-editing problem, Kepler treats it as an ongoing mapping problem. The platform is live today at trykepler.rubixkube.ai, designed around four straightforward principles:
Compounding Local Memory
Every operational session should make the next session smarter. Rather than starting with a blank canvas every time you launch a task, Kepler operates alongside a persistent memory engine that lives directly on the operator's machine.
As routine work happens (investigating alerts, reviewing configurations, checking logs), the system records entities, dependencies, operational preferences, and past troubleshooting steps. When an operator opens a new investigation about consumer lag, the agent does not ask what Kafka is or where the consumers live. It already holds the map of the services involved and recalls what resolved the issue the last time it occurred.
Total Human Ownership and Visibility
A map you cannot see, audit, or change is not your map. Black-box memory systems that hide what an AI has recorded inevitably lead to confusion and distrust.
Kepler makes its working understanding of your estate completely transparent. Operators can open their operational notes at any time to see exactly what the agent believes about their services, delete outdated assumptions, or manually add institutional knowledge that code scans would never catch. Human notes are treated as authoritative; the agent records its own observations within strictly managed boundaries and never overwrites what an engineer wrote by hand.
Provenance Over Hallucination
In production operations, a plausible-sounding command that fails silently is worse than no answer at all. A single incorrect flag passed to a cloud CLI or an untested cleanup script can wipe out production data.
Kepler treats runbooks and operational procedures as strict empirical records. The system does not promote a sequence of steps into persistent memory simply because an AI thought it sounded reasonable in conversation. A procedure enters operational memory only when it has been observed executing successfully in real terminal sessions and producing verifiable results. The system demands proof: this command ran, on this target, and it solved the problem.
Working Across Operational Boundaries
An operator does not live inside a single window. Diagnosing modern infrastructure requires jumping between terminal windows, web consoles, secret vaults, monitoring dashboards, and multiple code repositories.
An effective agent must work the same way. When an investigation requires broad visibility, Kepler operates across these surfaces naturally. When a task becomes too sprawling for a single context to handle cleanly, the system delegates focused sub-tasks to independent subagents. One checks repository configurations, another verifies cluster state, and a third inspects pipeline runs. They return their distilled findings back to the primary session, keeping the main map clean, accurate, and free of noise.
Draw the Map, Do Not Sink Another Drill
A drill is an indispensable tool when you know exactly where to strike. If you have a single bug inside an isolated function, an in-editor coding agent is the right machine for the job.
However, a drill is the wrong tool for exploring an entire county.
For the past several years, operations engineers, SREs, and platform teams have been handed drills and told to manage their cloud infrastructure with them. The predictable result has been deep, confident answers about the wrong codebase, endless repetitive onboarding of AI tools, and a blank slate waiting for them every Monday morning.
An operational agent must be wide. It must accumulate knowledge across time. And above all, the map it draws must belong to the operator walking the land.
You can try Kepler right now at trykepler.rubixkube.ai to see how an agent built for operations handles cross-repository infrastructure.
Frequently Asked Questions
What is the difference between an AI coding agent and an AI operations agent?
An AI coding agent (like Cursor or GitHub Copilot) operates with depth inside a single project repository, focusing on syntax, refactoring, and local tests. An AI operations agent (like Kepler) operates with breadth across multiple repositories, cloud infrastructure, Kubernetes clusters, and observability tools. While coding agents forget everything when a session ends, an operations agent compounds knowledge over time, remembering inter-service dependencies, unwritten conventions, and proven incident remediation steps.
Can AI agents solve problems across multiple repositories at the same time?
Yes, provided the agent is designed specifically for multi-repo architecture. Traditional developer agents lock their execution context to a single working directory on disk. Kepler, built by RubixKube, handles cross-repo operations by delegating tasks to lightweight subagents. These subagents inspect separate repositories, pull configuration values, and return distilled findings to the primary session without choking the context window with megabytes of unrelated source code.
How do AI agents for SRE retain infrastructure knowledge across sessions?
Most AI tools suffer from session amnesia, requiring engineers to re-explain their architecture every time they open a prompt. Kepler solves this by maintaining persistent local memory on the engineer's workstation. It records an evolving graph of entities (services, queues, databases), relations (which app reads from which database), and validated runbooks. The next time an incident occurs, the agent automatically retrieves relevant background context before suggesting actions.
Why do large context windows fail for cloud infrastructure management?
Expanding a context window allows a model to ingest more tokens, but dumping twenty repositories and thousands of lines of Terraform into a prompt creates noise, introduces hallucination risks, and causes high latency during production outages. Real-world SRE work requires an active operational index: understanding how services link together and what remediations worked in the past, rather than brute-forcing raw code into a massive prompt.
How does Kepler verify that AI-generated operational commands are safe?
Kepler follows a strict provenance rule: it distinguishes between theoretical documentation and verified execution. Operational procedures and runbooks are only promoted into long-term memory after they have been executed successfully in real sessions with verifiable outcomes. Furthermore, the operator retains complete visibility and control over memory notes at all times, preventing hallucinated or obsolete steps from becoming standard procedure.
