The Five-Console Problem
On a typical incident day, a production engineer touches at least five separate tools before they have a complete picture of what is wrong. The sequence usually looks like this: AWS Console to check costs and pull CloudWatch logs, kubectl to inspect pod state, Grafana to correlate metrics against the timeline, GitHub to find what shipped in the last deployment, and Terraform to check whether any resource has drifted from expected state.
Each tool requires a different credential. Each has a different query model. Each holds a fragment of the answer, but none holds the full context. And every time you switch surfaces, you pay a cognitive cost — rebuilding mental state, re-locating the right resource, re-entering a credential that expired since you last used it.
This is not a tooling quality problem. AWS Console, Grafana, and kubectl are each well-built for what they do. The problem is that they were designed independently, and no single surface was designed to hold the investigation state across all of them.
An AI DevOps workspace for teams is the direct answer to this problem. But the word "workspace" is used loosely enough that it is worth defining precisely before examining what Clanker Cloud does with it.
What a "Workspace" Is — A Precise Definition
The DevOps tooling market in 2026 contains four distinct categories that are frequently conflated. Getting the definitions right matters because each makes different architectural choices.
Dashboard. A dashboard shows you data passively. You navigate to it; it displays pre-built views — CPU utilization, request rate, error rate — and you interpret what you see. It does not answer questions. It does not know why a metric is elevated; it only displays the metric. Grafana, CloudWatch dashboards, and Datadog dashboards are all dashboards. Valuable for monitoring known signals, but no query interface and no memory between sessions.
Copilot. A copilot suggests what to type next. It has code and configuration context — it can autocomplete a Terraform block or suggest a kubectl command — but it has no live infrastructure access. Ask a copilot "why is checkout latency spiking" and it cannot answer: it has no connection to your running services. A copilot is a code-layer assistant, not an operations-layer assistant.
CLI tool. A CLI tool runs commands. kubectl, aws, terraform, and the open-source Clanker CLI all fit here. CLI tools are composable and scriptable. But they have no persistent context between invocations, no planning layer, and no approval gate — they execute what you type immediately. Each session starts from zero.
AI DevOps workspace. A workspace combines four capabilities in a single persistent surface: (1) live infrastructure queries in plain English, (2) topology inspection across all connected providers, (3) reviewed change plans with visible intended impact before execution, and (4) explicit approval-gated action. The conversation history persists across sessions. The context from an incident investigation last Tuesday is available when you return to investigate a related symptom next week.
The workspace is not a replacement for the CLI or the dashboard. It is a layer above them that holds context, routes queries to the right provider, and gates actions behind a review step.
The Four Workspace Capabilities
Clanker Cloud's product architecture maps directly to the workspace definition above. The four-step workflow is:
ASK — live infra queries in plain English. Instead of constructing the right aws ec2 describe-instances filter, kubectl get pods -n production --field-selector=status.phase=Running, or Terraform state command, you ask in natural language. The workspace routes the question to the appropriate provider API and returns the answer. The query model is conversational, not command-based.
INSPECT — topology without console-hopping. The workspace maintains a live topology map across all connected providers: AWS, GCP, Azure, Kubernetes (EKS, GKE, AKS), Cloudflare, Hetzner, DigitalOcean, and GitHub. You can trace dependencies — which services talk to which databases, which namespaces are talking across clusters — without opening a separate console for each provider.
PLAN — reviewed change plans. Before any modification is proposed for execution, the workspace generates a plan that shows exactly what will be created, modified, or destroyed, along with the estimated cost impact and risk level. This is the terraform plan model applied universally. You see the blast radius before you approve anything.
APPLY — explicit maker mode. Changes only execute when you explicitly approve them. This is Maker Mode — the action gate that separates a workspace from an autonomous agent. The workspace gathers context and generates plans without restriction; it cannot act without your sign-off.
| Old workflow | Workspace equivalent |
|---|---|
aws ec2 describe-instances |
"show me all EC2 instances and their monthly cost" |
kubectl describe pod checkout-api-7d4b9 |
"why did pod checkout-api crash?" |
| Grafana dashboard | "show me checkout latency over the last 2 hours" |
terraform show |
"which Terraform resources have drifted from state?" |
| GitHub blame | "what changed in production in the last deployment?" |
See the live demo for a walkthrough of all four steps against a real infrastructure graph.
Context Persistence: Conversation History as Runbook
The most underexamined property of the workspace category is context persistence. Every dashboard session, every kubectl command, and every Grafana query is stateless. The session ends; the context is lost.
In an AI DevOps workspace, the conversation history accumulates. The investigation you ran on Tuesday — "why is checkout latency spiking," followed by "what changed in session-cache this week," followed by "show me the dependency graph for orders-postgres" — is available next week when a related symptom appears.
This transforms the conversation history into a living runbook. The question "what changed?" asked today answers "why did this happen?" asked in a postmortem next month.
Traditional runbooks drift out of sync with actual infrastructure and are consulted only after an incident is underway. A workspace-generated history is always current because it was produced from live state queries. For teams moving from fast vibe-coding workflows to production operations, this persistent context is the operational layer that fast shipping lacks.
Persona Modes: Same Workspace, Different Default Views
Different roles have different default information needs from the same infrastructure. A founder wants to know what the monthly bill is and whether anything is degraded. A Kubernetes engineer wants pod health, resource limits, and recent events. An AI researcher wants GPU allocation and training job status. An engineering manager wants deployment frequency and service health trends.
Clanker Cloud surfaces these as persona modes — pre-configured default views of the same workspace context:
- FOUNDER MODE — cost visibility, service health, and incident status at a glance
- KUBERNETES — cluster topology, pod health, resource utilization, and event streams
- AI RESEARCHER — GPU provider data, training runtime health, model deployment status
- ENGINEERING MANAGER — deployment history, service reliability, team-level change frequency
- VIBE CODER — production health check for engineers who build fast and need a rapid operational read
None of these modes are separate tools. They are different starting views of the same connected infrastructure context. Switching modes does not change what data is available; it changes which signals are surfaced first.
The Checkout Latency Demo: A Workspace Session
The difference between a dashboard and a workspace is most visible in a concrete incident investigation. Consider this infrastructure state:
- checkout-api: $44/mo, 3 pods, 22ms p95 latency
- session-cache: DEGRADED
- orders-postgres: $198/mo, 2.1k qps
A dashboard would show you these signals separately — cache health in one panel, latency in another, database throughput in a third. You would need to construct the causal chain yourself.
In a workspace session, you type: "Why is checkout latency spiking?"
The workspace queries live state across all three services, traces the dependency graph, and returns: "checkout-api is the hottest synchronous service in this path. Redis is degraded, so more reads are falling through to orders-postgres. orders-api and billing-worker still look healthy, so the blast radius is mostly checkout."
That is a complete root cause in one query. The workspace knew to check session-cache because it understood the service dependency topology. It knew to check orders-postgres throughput because it understood what happens when a cache layer degrades. It knew the blast radius was limited to checkout because it could see that orders-api and billing-worker had no shared degraded dependency.
This is what the workspace category produces: a complete answer from a natural language question, because the workspace holds topology context, cost signals, and health data in a single surface. See the full demo to run this query against a live environment.
Agent-Extensible: MCP Workspace for Humans and Agents
A workspace that humans use is useful. A workspace that humans and agents share is a force multiplier.
Clanker Cloud exposes a local MCP (Model Context Protocol) server. Any MCP-compatible agent can register against the workspace and use its live infrastructure context for their own reasoning. The setup for OpenClaw, which has 68,000 GitHub stars, is one command:
openclaw mcp set clanker-cloud --url http://127.0.0.1:39393
Once registered, OpenClaw can call clanker_route_question to query live infra state before deciding whether to alert, or clanker_run_command to execute infrastructure operations within Maker Mode's approval gates. The same workspace context that a human engineer queries is available to Hermes, Claude Code, and Codex via MCP.
This creates a multi-agent architecture: Claude Code writing infrastructure as code, Hermes monitoring production health, OpenClaw running deployment runbooks — all sharing the same live infrastructure context through one workspace surface. None of these agents need separate cloud credentials; they route through the workspace's local credential layer.
The MCP server runs locally at 127.0.0.1:39393. No credentials or infrastructure data leave your machine. Full documentation for agent configuration is at the for-agents reference and docs.clankercloud.ai.
Deep Research as a Workspace Capability
Point queries — "why is checkout latency spiking?" — work well when you know what to ask. But the most valuable infra problems are often the ones you do not know to look for: idle resources burning compute, single-AZ caches with no failover, public database endpoints, APIs with no rate limiting.
Deep Research is a workspace capability that fans out across every connected provider simultaneously, runs parallel analysis with multiple AI models, and returns severity-graded findings:
- CRITICAL: Public database endpoint exposed
- HIGH: Idle worker pool burning compute — worker-pool averages 3% CPU over 30 days but runs 4 replicas. Scale down or enable HPA. Save $140/mo.
- HIGH: Single-AZ cache, no failover
- MEDIUM: Uncompressed S3 backups growing fast
- MEDIUM: API gateway has no rate limiting
This is not a passive dashboard view. It is an active investigation across every connected provider, returning ranked findings with dollar impact where relevant. The difference from a monitoring alert: the workspace provides context alongside the finding — not just "idle worker pool" but the CPU data, replica count, estimated savings, and remediation path.
Clanker Cloud: Local-First, BYOK, One-Minute Setup
Clanker Cloud is an AI DevOps workspace that runs as a desktop application on macOS, Windows, and Linux. Setup takes under a minute: install the app, connect your cloud providers using existing local credentials (~/.aws/credentials, ~/.kube/config), and the workspace has live access to your infrastructure.
Credentials never leave your machine. The app queries your cloud providers directly. AI model costs are separate from the workspace subscription cost — you bring your own keys (BYOK), and your queries go directly to the provider you choose at their listed rates with no markup. Supported models include Claude Opus 4.6 and Sonnet 4.6, GPT-5.4 Thinking and Pro, Gemini 3.1 Pro, Cohere Command A, and local models via Ollama — Gemma 4 (gemma4:31b, gemma4:26b) and Hermes 3 (hermes3:70b, hermes3:8b) for fully local, free inference.
Routine queries with a local Gemma 4 model cost nothing beyond electricity. Complex incidents can be escalated to Claude Opus 4.6 or GPT-5.4 Thinking for deeper reasoning, then switched back to a lighter model when resolved. Model choice is decoupled from tool pricing.
The workspace is in free beta. The Pro tier is $20/month. The AI costs are billed separately, directly by the provider you choose.
Get started at clankercloud.ai/account. Full documentation is at docs.clankercloud.ai.
FAQ
What is an AI DevOps workspace? An AI DevOps workspace is a persistent surface that combines live infrastructure queries, topology inspection, reviewed change plans, and approval-gated action in one interface. Unlike a dashboard, it answers questions. Unlike a copilot, it has live infra access. Unlike a CLI tool, it maintains conversation history across sessions. The defining properties are: natural language query interface, persistent context, and an explicit action gate (Maker Mode) that requires operator approval before any change executes.
How is a workspace different from a dashboard like Grafana? A dashboard displays pre-built views of data passively. You navigate to it and interpret what you see. It does not answer questions, has no topology context, and has no memory between sessions. A workspace accepts natural language questions — "why is checkout latency spiking?" — queries live state across all connected providers to construct an answer, and retains that conversation history for future sessions. The same question a dashboard cannot answer, a workspace resolves in one query. See the full FAQ for more comparisons.
What is BYOK in an AI DevOps workspace? BYOK (bring your own keys) means your AI model API keys — from Anthropic, OpenAI, Google, Cohere, or a local Ollama instance — are configured on your machine and used directly. Your queries go from your machine to the AI provider, not through the workspace vendor's infrastructure. You pay the AI provider at their listed rates with no markup. You can switch models — Gemma 4 locally for routine queries, Claude Opus 4.6 for complex investigations — without changing your workspace plan. Clanker Cloud requires BYOK; no AI costs are bundled into the subscription.
Can AI agents use the workspace?
Yes. Clanker Cloud exposes a local MCP server at 127.0.0.1:39393. Any MCP-compatible agent — OpenClaw, Hermes, Claude Code, Codex — can register against the workspace and use its live infrastructure context for their reasoning and actions. Agents call clanker_route_question to query infra state and clanker_run_command to execute operations, subject to Maker Mode approval gates. The workspace becomes a shared infrastructure context layer for both human engineers and AI agents. Details at for-ai-agents.md.
Start Using the Workspace
The five-console problem is structural. Each tool holds a fragment of the context your investigation needs, and no single tool was designed to hold all of it. An AI DevOps workspace — persistent context, live queries, reviewed plans, explicit action gates — is the architectural answer.
Clanker Cloud is the workspace. One-minute setup. Local credentials. BYOK. Download and connect at clankercloud.ai/account.
Need the product-level answer?
Use the canonical category page for the stable definition, comparison set, and product fit.