Declarative. Deterministic. Production-grade AI on Kubernetes. Today, we’re excited to open-source OttoFlow. Below, we break down what OttoFlow is, the engineering friction that forced us to build it, and where it fits into the modern AI native stack.
For the better part of a decade, the runbook was how our industry automated operations. Not always a literal runbook but through pipelines, cron jobs, operators, shell scripts in a trench coat. The shape was the same everywhere. Anticipate a failure, codify the response, review it, version it, run it on repeat. It became the norm for good reason. It gave us automation that was deterministic, reviewable, and GitOps-friendly, and an entire generation of platform engineering was built on the idea that good operations means operations with the surprises removed.
Then AI entered the picture, and the norm aged a decade in about two years. A runbook’s defining strength, its determinism, is also its ceiling. It handles exactly the situations its author anticipated, and nothing else. This creates a critical Platform Engineering bottleneck: as application velocity increases, static reviews and manual updates can’t keep pace. A pipeline can count crash-looping pods, but it cannot look at twelve restarts, an OOM kill, and this morning’s rollout, and tell you which one matters first. Every threshold is hardcoded and every remediation predetermined, so when a problem arrives in a shape nobody wrote down, the runbook shrugs. Next to a model that can read the same evidence and reason about it, that rigidity stopped looking like discipline and started looking like the primary constraint on scaling operations.
So the pendulum swung hard the other way. Hand an LLM agent your kubeconfig and let it explore. The demos are spectacular, and the problems show up in production. Every run is different, so there is nothing to code-review and nothing to diff when it goes wrong, only a transcript. The agent burns tokens re-deriving facts a single API call already knew and it sees everything, from full pod specs to annotations to environment variables, when the task needed a dozen fields. Plenty of platform teams have tried this over the past two years and reached the same quiet conclusion, that autonomy without structure does not survive contact with prod.
We think the choice between those two is a false one. OttoFlow is our answer to it.
Judgement is a single step, not the system itself
Look closely at a real operations loop. A triage, a cost review, or a hygiene sweep, and most of it was never a judgement problem. Listing pods is a query and “more than three restarts” is an expression, and posting a report is an API call. The judgement lives in one narrow slice, the moment where someone looks at the evidence and decides what matters most. That slice is where a model earns its tokens. Everywhere else, determinism is not a limitation. It is the property you have spent a decade building your platform on.
OttoFlow is a Kubernetes-native workflow engine built on that observation. A workflow is a custom resource, a DAG of typed steps with explicit dependencies. Deterministic steps (CEL expressions, live Kubernetes resource queries, Prometheus queries, resource mutations) do the collecting and the acting, and an AI agent step is deployed only where interpretation is required. The engine resolves the graph, runs independent steps concurrently, retries what fails, gates steps on conditions, and enforces cost budgets on expression evaluation.
The pattern that keeps recurring is collect, analyze, publish. Consider a CVE triage workflow: OttoFlow queries the cluster for running images, triggers Trivy to generate attestations, and uses an AI agent only to categorize the vulnerabilities and prioritize remediation. The expensive ‘judgement’ happens once, bracketed by deterministic data collection and report publication.
Governed by construction
The agent in that workflow never receives a pod spec, because the workflow never passes it one. Data flowing into an agent step is declared in the workflow definition, so what the model can see is decided by you, in YAML, in code review and not by the model at runtime. The model gets evidence, not access.
- Sandboxed CEL execution: Fast and powerful expressions to collect and analyze data.
- Per-step RBAC: Granular access controls over what each step can access for least privileged execution.
- mTLS for agent communication: Encrypted and authenticated traffic between components.
- Scoped MCP tool access: Restricting the tools available to the model based on workflow context.
- Integrations: integrated with Prometheus, Kagent, Kyverno, and other CNCF tools.
This is what we mean by autonomous AI workflows. The autonomy is real, and it is bounded on purpose. Not a copilot waiting for a human to prompt it, and not a free agent improvising against your API server, but a declared process that runs on schedules and cluster events, exercises judgement where you placed it, and leaves an audit trail everywhere.
Where OttoFlow fits in
Step back from Kubernetes for a moment, because this is really a story about where the industry is in the AI-automation cycle.
Technical Architecture
The OttoFlow engine is built on three core pillars:
- Controller: Manages the lifecycle of Workflow custom resources and watches cluster events.
- Workflow Runner: Orchestrates the DAG execution, resolving dependencies and handling retries.
- Agent Executor: Provides a sandboxed environment for LLM interpretation with strict data boundaries.
| Category | Primary Focus | AI Integration |
|---|---|---|
| Agent Frameworks (e.g., LangGraph, CrewAI) | Exploration & Open-ended Reasoning | Code-first loops; model-driven control |
| Workflow Engines (e.g., Argo, Tekton, Temporal) | Reliability & Deterministic Tasks | Treats LLM as an opaque container |
| OttoFlow | Agentic Workflows & Governance | Declarative; native AI/LLM primitives |
OttoFlow occupies a unique middle ground as it provides the reliability of a deterministic workflow engine (like Argo or Tekton) with the intelligent synthesis of an agent framework while integrating directly with the open agent stack: From supporting Model Context Protocol (MCP) tools, A2A protocols for external agents, and multiple LLM provider, without forcing you to treat AI as the runtime itself.
Real-World Example: CVE-to-PR Triage. Instead of a human manually reviewing vulnerability scans, OttoFlow queries your registry, triggers a scan, and passes the CVE data to an Agent Step. The agent filters out false positives based on runtime context and automatically opens a Pull Request to bump the image version, reducing triage time from hours to seconds.
OttoFlow inherits its architectural DNA from Kyverno. This isn’t just about a familiar YAML syntax but rather a battle-tested architectural philosophy applied to the AI agent space. By utilizing shared governance primitives like per-step RBAC and admission webhooks, OttoFlow ensures that AI operations are as declarative, native, and reviewable as the policies you already trust to secure your clusters.
The product today
OttoFlow v0.1 is a complete engine that is used by Nirmata Control Hub customers in production as part of its cloud agents suite. Its step vocabulary covers the deterministic side (CEL expressions, Kubernetes resource queries, Prometheus queries, Kyverno-style mutations), the AI side (agent steps with MCP tool access, direct MCP tool calls, A2A calls to external agents), and composition (parallel iteration, sub-workflows, reusable step templates, wait-for-callback for external signals, and report publication via OpenReports). Workflows fire on cron schedules or Kubernetes events, retry with configurable backoff, branch on conditions, and run across clusters. The automations it is built for are the ones platform teams actually run, from cost review and optimization to resource hygiene, pod and workload triage, and policy recommendations.
It also respects how platform teams evaluate software. The CLI can execute a workflow entirely in-process against your current kubecontext, with no controller, no CRDs installed, and nothing to clean up, so you can see real output from your own cluster before OttoFlow touches it in any persistent way. Also, the supply chain is treated as part of the product, with cosign-signed releases, SBOMs, and SLSA provenance.
Equally important is what OttoFlow is not. It is not a general-purpose agent framework. If you want free-form agents, use one of those instead. It does not write your automation for you. And it does not promise hands-off remediation out of the box. Mutation steps exist, and putting them behind judgement and explicit conditions is a decision we leave deliberately in your hands.
Structure by default and judgement where it counts
The interesting question in 2026 is no longer whether AI can operate infrastructure. It is how much of your infrastructure you should have to hand over for it to be useful. Our answer is far less than the current generation of agents demands. Give the model a well-framed decision instead of a kubeconfig, and you get automation you can trust with the boring parts and credit for the smart ones.
OttoFlow is public today at github.com/nirmata/ottoflow . Start today with helm install ottoflow or explore our samples.
