The Harness

The harness is everything around the AI model that lets CloudThinker work on your real system: orchestration that plans and splits the work, context from your code, infrastructure, alerts, tools, and team knowledge, and a learning loop that keeps what each run discovers. A frontier model on its own knows the internet; the harness is what makes it know your system.

​

Why a harness

• Hard problems cross boundaries. A slow checkout can trace through a code change, a Kubernetes rollout, a database limit, and a noisy alert at once. Solving it means seeing all of them together.
• Evidence beats best practices. CloudThinker queries your actual systems, so its answer names your services and your resources — not generic advice.
• Parallel investigation. Several hypotheses get checked at the same time instead of one after another.
• Guardrails stay on. Everything the harness does runs inside your workspace’s Manual or Auto setting.
• It compounds. Every module leaves something behind that the next run starts with.

​

Orchestration

CloudThinker, the built-in assistant, plans each task. For a hard problem it spawns temporary subagents, each checking one focused hypothesis — read-only during an investigation — and then combines what they found into one verdict with its evidence. See how this runs in Investigation and RCA.

​

Context from every surface

The harness can only reason about what it can reach. Each connection adds one surface: The more surfaces a workspace connects, the more of a problem CloudThinker can see in one pass.

​

Every module makes it smarter

Each module keeps something from its work and feeds it back, so CloudThinker knows your environment a little better every day. You stay in control of what it keeps: you can correct or remove a memory, and turn skill learning off per custom agent.

​

A hard problem, end to end

1. An alert arrives. Pulse strips the noise and routes the real problem into an Incident.
2. CloudThinker plans. It reads incident memory for similar past problems and splits the work into hypotheses — a recent deploy, a pod rollout, a database limit.
3. Subagents gather evidence in parallel from code, infrastructure, and tooling connections.
4. You get one answer: the root cause, the evidence behind it, and a proposed fix to approve.
5. The harness keeps the lesson, so the next similar incident starts further ahead.

​

Related