DevOps teams do not need another chatbot that can explain what Kubernetes is. They need a controlled way for AI to inspect live infrastructure, summarize what matters, and propose changes without taking reckless action.
That is what an AIOps harness does. It wraps an AI model with real tools, provider context, credentials, routing, debug output, and approval gates.
The Clanker CLI is the free open-source version of that harness. It is a Go CLI under the MIT license. It can run from your terminal, use your local provider credentials, answer plain-English infrastructure questions, expose MCP tools for agents, and generate reviewed plans before applying changes.
For DevOps teams, that is the difference between "AI can talk about operations" and "AI can help operate safely."
What Makes a CLI an AIOps Harness?
A normal CLI runs commands. An AIOps harness coordinates a workflow.
For infrastructure, that workflow usually looks like this:
- Accept a natural-language question.
- Route it to the right provider or command set.
- Pull live data from local credentials.
- Ask the selected AI model to interpret the evidence.
- Return an answer, report, or plan.
- Require explicit approval before making changes.
Clanker CLI gives DevOps teams that loop for free.
brew tap clankercloud/tap
brew install clanker
clanker ask "what looks unhealthy in production?" | cat
That command is small, but the workflow behind it is the important part. The CLI is not guessing from training data. It is routing the question into your actual provider context.
Live Reads Beat Static Context
AI agents are strongest when they can call tools. They are weakest when they are forced to infer production state from files.
A repository might say a service should have three replicas. The cluster may currently have one healthy pod, one pending pod, and one crash-looping pod. A Terraform file might define an RDS instance. The real account may also contain manually created resources, old security groups, or cost drift from experiments.
Clanker CLI is useful because it starts from live reads:
clanker ask "which Kubernetes pods are failing right now?" | cat
clanker ask --aws "what changed in my AWS environment this week?" | cat
clanker security "review public APIs and IAM blast radius" | cat
For a DevOps engineer, this turns the model into a faster first-pass investigator. It gathers the evidence you would normally collect through kubectl, cloud consoles, logs, and billing screens.
MCP Turns the CLI into an Agent Harness
The CLI also runs as an MCP server. That is where it becomes a harness for external agents such as OpenClaw, Claude Code, Codex, Hermes, and internal tools.
clanker mcp --transport http --listen 127.0.0.1:39393 | cat
The MCP surface gives agents a controlled way to ask infrastructure questions through Clanker instead of inventing shell commands. The agent calls the tool. Clanker handles the provider context. Credentials stay local.
That is exactly the pattern that makes OpenClaw useful for always-on AIOps. OpenClaw brings the HEARTBEAT.md loop. Clanker brings the live infrastructure tools. A heartbeat item like "check for services with elevated errors" becomes a real operational check because the agent can query Clanker instead of guessing.
For Hermes-based local agents, the pattern is similar. Hermes handles tool-use reasoning locally through Ollama. Clanker exposes the tools and data that make the reasoning useful.
Review-Before-Apply Is the Control Layer
The most dangerous version of AIOps is an agent that jumps directly from diagnosis to mutation.
Clanker CLI keeps the control layer explicit. Maker mode generates a plan first:
clanker ask --aws --maker "create a small ec2 instance and postgres rds" | cat
Applying is separate:
clanker ask --aws --maker --apply --plan-file plan.json | cat
Destructive operations require an additional flag:
clanker ask --aws --maker --destroyer "delete the staging rds instance" | cat
This is harness engineering in practice. The model can help plan, but the harness defines the boundary between read, plan, apply, and destroy.
For production teams, that boundary is the whole ballgame.
Debug Traces Make the Harness Auditable
Infrastructure teams need to inspect how an AI system reached an answer. AIOps cannot be a magic box.
Clanker CLI supports debug and trace modes so engineers can see routing and agent behavior:
clanker ask --route-only "why is checkout returning 502s?" | cat
clanker ask --agent-trace "why is checkout returning 502s?" | cat
The exact flags vary by workflow, but the principle is consistent: make routing and tool selection visible enough for an engineer to verify.
That matters when the CLI is used inside CI/CD, OpenClaw heartbeats, pre-deploy checks, or incident response. If a finding looks wrong, you can inspect the route, rerun the query, and compare the raw provider evidence.
Practical DevOps Workflows
Here are concrete ways a team can use Clanker CLI as a free harness.
Incident first pass
clanker ask "what changed in production in the last 2 hours?" | cat
Kubernetes health check
clanker k8s ask "list unhealthy pods and summarize likely causes" | cat
Security drift check
clanker security "find public endpoints, missing auth, and risky IAM changes" | cat
Agent heartbeat through MCP
- [ ] Ask clanker-cloud whether any production services are degraded.
- [ ] Ask clanker-cloud for cost anomalies over the last 24 hours.
- [ ] Ask clanker-cloud whether the MCP endpoint itself is healthy.
Each one is small. Together they form an operations harness.
When the Free Harness Is Enough
The CLI may be enough if your team is terminal-first and comfortable composing tools.
Use the CLI when you want:
- Free open-source AIOps workflows.
- CI/CD or shell integration.
- Local MCP for one agent.
- Auditable terminal output.
- A lightweight way to test AI-assisted operations.
That is a solid starting point. Many teams should begin there because it forces the workflow to stay concrete: one question, one provider context, one output.
When to Graduate to Clanker Cloud
The CLI is the free harness. Clanker Cloud is the complete agent harness solution.
Graduate to Clanker Cloud when you need:
- A desktop workspace for humans, not only terminal sessions.
- Saved provider and model configuration.
- Visual topology and multi-provider context.
- Deep Research across a full estate.
- Richer review surfaces for plans and findings.
- Shared workflows for DevOps engineers, agents, and vibe coders.
The good news is that the mental model transfers. Clanker Cloud is powered by the same open-source engine. The CLI teaches the workflow; the app gives that workflow a complete operations surface.
Start with Clanker CLI. Move to Clanker Cloud when your harness needs a full cockpit.
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.
