An agent that works on your laptop is borrowing three things it doesn’t own: your identity, your attention, and your judgment.
It runs with your credentials and your access. It runs when you trigger it. And when it gets something wrong, you notice and tell it, which is the only evaluation it ever gets. Deploy the same skill to the cloud, unattended and pointed at production, and all three disappear at once.
This post is a technical teardown of how the Komodor Agentic Operations Platform replaces them. It draws on our launch session, where Komodor Co-Founder and CTO Itiel Shwartz walked through the architecture and a live demo, and on the platform’s design documentation.
We’ll look at the two layers the platform is built from, follow a single run from trigger to verdict, and then cover the parts that make agents trustworthy over time: guardrails, workflows, and evaluation.
What a laptop gives an agent for free
Most conversations about production agents focus on two decisions: the harness (Claude Agent SDK, LangChain, Google ADK, Agno, and others) and the model. Those decisions matter, but they’re the easy part. What you think you’re shipping is a prompt, a model, some tools, and some skills. What production needs is everything a human was quietly providing around them.
| Concern | On a laptop | In production | Where the platform handles it |
|---|---|---|---|
| Identity | Your user, your credentials | Its own identity with scoped access | RBAC, brokered credentials |
| Trigger | You, typing | Alerts, schedules, PRs, chat, other agents | Triggers and channels |
| Safety | You read the plan before it runs | Something outside the agent has to stop bad actions | Guardrail gates, human approval |
| Evaluation | You are the judge | Nobody is watching | Datasets, judges, shadow and A/B experiments |
| Cost | Your own token bill | A retry loop at 03:00 UTC with no ceiling | Spend budgets, rate limits |
| Context | What’s in your head | Shared history of services, incidents, and fixes | Memory and knowledge graph |
The cost row is not hypothetical. There are customers whose first production agent cost them around $100K in its first year while delivering almost no value.
The pressure to solve this is coming from the build side. Coding agents have made it much faster to ship changes, good and bad, and every change that reaches production can become an incident, a ticket, or a cost line. By my estimate, around 90% of companies are still at the local-skills stage: skills for triage, support, and observability queries, running on developers’ machines. The next step, one agent running on its own, is where the table above starts to bite.
The architecture: workers and a control plane
The platform has two layers. Workers are where agents execute. The control plane is where identity, policy, routing, records, and evaluation live.
The split is deliberate. Your choice of harness stays independent of how the agent is governed, and agents can run close to the systems and data they work on while policy and records stay in one place.
Layer 1: the worker
The entry point is a deliberately slim SDK. You take an existing agent, or even a single skill, install the SDK (for Python agents, a pip install), and the agent joins the platform as a worker.
The SDK wraps the harness rather than replacing it. Your prompts, tool logic, and framework stay as they are; you wrap and import, you don’t migrate. What changes is that every invocation now passes through the wrapper, and the wrapper is where the platform attaches:
- Identity and credentials for the run, resolved by the control plane
- Triggers, so the agent starts on an alert or a schedule instead of a keystroke
- Gateways, so model calls and tool calls go through the control plane, where they can be checked
- Telemetry, so every step lands in run history without the agent having to log it
Workers run anywhere there’s compute. Agents ship with a Dockerfile and a Helm chart as the default recipe, but a worker can just as well run on a VM, in a sandbox, on-prem, or on a mainframe. Workers autoscale with load.
platform doesn’t make agents deterministic. It doesn’t try to. You can make an agent deterministic, but that mostly removes the reason to use an LLM. Control comes from the wrapper and the gates around it, not from taking away the model’s judgment.
Anatomy of an agent definition
These are the steps for creating a “research brief” agent from scratch on the platform. The creation flow is a good map of what the platform treats as an agent’s full definition:
- Agent MD: the agent’s instructions.
- Provider and model: Komodor-provided inference out of the box, or your own provider.
- Skills, tools, and connected agents the agent may call.
- Triggers: what starts a run.
- RBAC: who in the organization can invoke, configure, or approve it.
- Guardrails: budget and time limits, layered under company-wide guardrails the agent owner can’t override.
- Evaluators: LLM-as-judge graders that score each run. Optional, but recommended.
- Memory: what the agent should retain and how to reuse it.
- Deployment target: your cloud, another provider, or any Helm chart.
None of this requires the UI. Every screen is exposed over Komodor’s MCP server, with skills for driving the platform from Claude Code or Cursor, and agents can also be managed through the API, IaC definitions, or Kubernetes CRDs. Each change to a definition creates a revision, so you can compare versions after an experiment and roll back if a change makes things worse. New skills and agents go through publish-and-approve before they’re live, and any agent can be paused, retired, or reassigned.
Layer 2: the control plane
I like to describe the control plane as “an agent runtime layer with batteries already included.” Here is what each battery does.
| Component | What it does |
|---|---|
| LLM gateway | One path to every model provider. Where model choice, per-workflow model overrides, allowed-model standards, and token limits are enforced, and where prompts and completions are checked. |
| MCP gateway | One path to every tool. Integrations are connected once and shared across agents. Per-integration scope (read vs. write, per environment) is enforced here, and tool calls and tool results are checked. |
| Skill registry | The catalog of skills, tools, and agents, including 50+ battle-tested specialist agents, with publish-and-approve on changes. |
| RBAC and credential broker | One permission model for humans and agents. Credentials are brokered at run time, so agents never hold a standing key. |
| Guardrails | A gate on every boundary a run crosses, with four possible verdicts. Covered in detail below. |
| Run history | Full evidence for every run: trigger, trace timeline, logs, messages, outputs, artifacts, model, tokens, and cost. |
| Evaluation | Datasets, judges, experiments, and optimization recommendations. |
| Memory and knowledge graph | A shared layer every agent reads from: an automatically maintained map of services, owners, dependencies, deploys, and data stores, plus past runs, RCAs, and fixes as cited memory. |
The last row is the one most teams don’t plan for. An agent that starts every investigation from zero repeats work a previous run already did. With a shared context layer, a fix one agent found last month becomes evidence the next agent can cite.
Following one run end-to-end
Here is what happens when an alert fires and an agent picks it up.
- Trigger. A run starts from one of the agent’s channels: UI, API, webhook, schedule, Slack, or another agent. Per-channel rate limits (runs per window, concurrency) apply before anything else.
- Routing. The control plane routes the request to the right agent. The run moves through a lifecycle of queued, claimed, running, and succeeded or failed, with a worker claiming it.
- Identity. The agent’s roles and policies are resolved. Access is deny-by-default: the agent can only do what it has explicitly been scoped to do.
- Input gate. The trigger payload is checked before the agent sees it.
- Reasoning. Each model call leaves through the LLM gateway (prompt gate) and returns through it (completion gate).
- Action. Each tool call goes out through the MCP gateway (tool-call gate) with a credential brokered for that call, and the result comes back through the tool-result gate.
- Approval. If an action is flagged as higher risk, the run holds and the request is routed to the right person, with the agent’s reasoning and intent attached.
- Record. Every step, decision, and cost is written to run history as it happens, so nothing has to be reconstructed from scattered logs.
- Grade. After the run, judges score it against the agent’s rubric. A good run can be added to a dataset with one click, where it becomes a regression case for future changes.
In the demo, a support triage agent’s page showed exactly this: runs, cost, latency, errors, and trends, with each run’s full transcript and a record of which company-policy guardrails were checked and how each was enforced.
Guardrails: a gate on every boundary
A system prompt is a request, not a control. Instructions baked into an agent drift, and they can be overridden by whatever the agent reads next. So the platform puts its checks outside the agent, at every boundary a run crosses, from the input coming in, through the agent and its MCP tools, out to the LLM providers.
| Gate | Direction | Examples of what it catches |
|---|---|---|
| Input | Trigger or user → agent | Prompt injection in an alert or ticket body |
| Tool call | Agent → tool | Destructive or out-of-scope actions, like deleting a database or removing pods it shouldn’t |
| Tool result | Tool → agent | Instructions hidden in log lines or documents, secrets in returned data |
| Prompt | Agent → model | PII or secrets about to leave for an inference provider |
| Completion | Model → agent | Hallucinated actions, dangerous intent |
The five gates share one mechanism, configured once and enforced the same way at every crossing. Checks run cheapest first: exact-match rules catch the obvious cases, predefined detectors catch PII and secrets, and an LLM judge steps in only for what patterns can’t catch, such as hijacks or hallucinated actions. Each check returns one of four verdicts:
- Allow and log
- Redact in flight
- Block outright
- Hold for human approval
The agent never decides its own consequences, and every verdict is recorded per agent and per run.
Guardrail policy is layered. Company-wide guardrails apply to every agent and can’t be overridden by the agent’s owner; agent-specific guardrails add to them. On top of that, organizational standards act as admission checks before anything goes live: only approved model versions, an explicit spend ceiling on every workflow, an assigned guardrail configuration, and a minimum sampled eval coverage before production traffic runs unattended.
Cost is governed the same way. Spend caps apply per agent, team, or label, with utilization tracked in real time, alerts before a budget runs out, and a configurable action when it does: notify, block, throttle, require approval, or pause experiments.
Workflows: a deterministic blueprint with LLMs at each step
For complex operational work, one agent isn’t enough. By Komodor’s numbers, a typical incident investigation takes six to eight iterations and 20 to 30 tool calls to reach root cause. A single prompt rarely gets there, and a single agent juggling every specialty tends to lose the thread.
The platform’s answer is workflows: a predefined, mostly deterministic blueprint of steps, where each step is handled by one or more LLM-driven agents and each step’s output feeds the next. The blueprint fixes the order of operations. The agents handle the parts that can’t be scripted.
In the demo, alerts from Splunk Observability Cloud were arriving with no agent handling them. So, I built a workflow for them in five steps:
- Trigger: all Splunk Observability alerts, with deduplication and grouping of related alerts into a single incident.
- Investigation team: an investigation orchestrator acting as incident commander, plus specialist agents. The team can mix Komodor’s built-in agents with agents the customer built.
- Remediation strategy: set to human-in-the-loop. The workflow proposes a fix; a person decides whether it ships. Fully autonomous remediation is available, but as Itiel put it, most teams don’t yet trust agents to act alone in production, and the platform doesn’t ask them to.
- Validation and post-resolution actions: confirm the fix worked, then open a ServiceNow incident or post to Slack.
- Access and limits: RBAC, model overrides, and spend limits for this workflow.
The resulting graph had dozens of agents. It looks intimidating, but that’s what real customer production workflows look like. A completed run shows a timeline of what happened and why, the full investigation, and the remediation. Workflows get the same cost, latency, error-rate, evaluation, and experiment tooling as individual agents.
This is also how the Solution Modules are built. The AI SRE, Cost Optimization, and AI Software Operations modules are ready-to-run workflows on the same platform, using the same gateways, gates, and evaluators described above. Komodor AI SRE was the first product built on the platform; the platform itself is now open to your own agents, which can be added as steps in those modules or run on their own.
Evaluation: the Swiss cheese model
Evaluation is the “the biggest problem of our time” for agents. You need to keep trusting an agent while you change its prompt, model, and tools, and while the environment it works in changes underneath it.
The approach, shaped by three years of running AI SRE agents in production, follows the Swiss cheese model. No single layer catches everything, so you stack layers whose holes don’t line up.
| Layer | What it catches | When it runs |
|---|---|---|
| Datasets and benchmarks | Regressions on known scenarios, built from captured runs | Before a revision ships |
| Manual validation | Failures automated judges miss or misjudge | On sampled runs |
| LLM-as-judge | Quality problems on each run, scored against a rubric | After runs, at a configured coverage |
| Shadow testing | Behavior of a new revision on live traffic, without acting on it | Before promotion |
| A/B testing | Real-world differences between two revisions | During rollout |
In the product, these live under an agent’s “Improve” section: Datasets (the agent’s unit tests), Evals (judges and rubrics), Experiments (two revisions side by side, in shadow mode or A/B), and Optimizations (platform recommendations for cost, accuracy, and speed). You can add your own judges, benchmarks, and datasets alongside the built-in ones.
The longer-term goal is a continual learning loop: approvals, grades, and outcomes from past runs feed back into the next ones, through memory and through revisions that win experiments. That loop is the replacement for the human judge the agent lost when it left the laptop. The platform supports it today. After all, nobody cares about agents, models, or harnesses for their own sake; they care about outcomes.
Where it runs and where you use it
Both layers are deployment-flexible:
- Control plane: Komodor Managed Cloud, your own cloud, on-prem, or air-gapped.
- Workers: anywhere there’s compute, from Kubernetes on any cloud to VMs and on-prem hardware.
- Models: Komodor-provided inference, or your own provider and model.
When self-hosted, data stays in your environment.
Most usage isn’t expected to happen in the platform’s UI. Agents and workflows can be added as teammates in Slack, Microsoft Teams, or Webex, or reached from Claude Code and Codex through MCP. Komodor runs it this way internally. The goal is to fit into the tools engineers already have open, not to add another dashboard.
The two things teams overlook
Asked to name the one thing teams overlook when they start with agents, Itiel couldn’t pick between two.
Evaluation. Ask a team running agents in production how they know the agents work, and the usual answer is “Good question. We hope they do.”
Safety. Ask how they make sure an agent won’t delete production, and the answer is often crossed fingers.
Both are architecture problems, not prompt problems. That’s why the platform puts identity, gates, and judges outside the agent, in a layer every agent shares, whoever built it and wherever it runs.
Explore the Komodor Agentic Operations Platform
Watch a full breakdown of the platform in our announcement webinar, available on demand. To try the platform, start a free trial or book time with one of our deployed engineers.
