The Harness: Why a Frontier Model Needs Context From Every Surface
Paste a stack trace into a chat window and a frontier model will give you a good answer. It will name the likely class of bug, suggest where to look, and list three things to check.
Then you go and check them. You open the deploy history, the cluster, the dashboards, the runbook wiki. The model was right about the shape of the problem and knew nothing about your system, because nobody showed it your system.
That gap is what we call the harness. It's the part of Frontier Investigation Agents that turns a model's reasoning into an answer about your production.
What the model doesn't know
A frontier model knows the internet. It knows how Kubernetes schedules pods, what a connection pool is, how a Helm chart renders. It doesn't know that your checkout service shares a database with billing, that someone halved a CPU request yesterday, or that your team never restarts the payment workers during business hours.
Those facts decide the answer. Without them, the best the model can offer is best practice. Best practice is a list of places to look, and the hour goes into looking.
Why one surface isn't enough
A lot of AI in operations lives on one surface. The observability vendor's assistant reads metrics. The code assistant reads the repo. The cloud console's assistant reads the account.
Hard problems don't stay on one surface. A slow checkout can trace through a code change, a Kubernetes rollout, a database limit and a noisy alert at the same time. An assistant that sees only one of them will find a symptom and stop there, because the cause is on a surface it can't reach.
So the harness is built around a simple rule: it can only reason about what it can reach, and it should reach everything that matters.
Context from every surface
Each connection adds one surface.
01Code
What changed
Where and when, from GitHub, GitLab or Bitbucket.
02Infrastructure
Current state
Configuration and topology from AWS, Azure, Google Cloud or Kubernetes.
03Alerts
What is breaking
Alerts and incidents arriving through Pulse.
04Tooling
The evidence
Metrics, logs and traces from Prometheus, Grafana or Datadog.
05Team knowledge
How you work
Runbooks and policies from knowledge bases, Atlassian or Notion.
Code (GitHub, GitLab, Bitbucket) tells CloudThinker what changed, where and when. Infrastructure (AWS, Azure, Google Cloud, Kubernetes) gives current state, configuration and topology. Alerts and incidents, through Pulse, say what's breaking right now. Tooling (Prometheus, Grafana, Datadog) supplies the metrics, logs and traces used as evidence. Team knowledge (knowledge bases, Atlassian, Notion) carries your runbooks, policies and how your team works.
The more surfaces a workspace connects, the more of a problem CloudThinker can see in one pass. That's the most practical thing to know about the harness: an investigation is bounded by what you've connected.
Three kinds of context, three sources
Connections let the agent query your systems. Context is what it knows before you say anything, and it comes from three places with different owners.
- Memory: notes about your environment, preferences and recent events. Agents write it as they work, and you can correct it. See Memory That Can Be Wrong.
- Knowledge: your runbooks, policies and documentation. You add it by uploading files or crawling a site, and agents search it by meaning.
- Skills: step-by-step instructions for a specific kind of task. You write them, or agents save them when skill learning is on.
Splitting them matters. A runbook you uploaded is your team's word. A memory note is the agent's inference. They shouldn't carry the same authority, so they don't live in the same place.
Orchestration
Context is half the harness. The other half is how the work is split.
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. Then it combines what they found into one verdict with its evidence. The details are in Inside an Investigation.
Parallel subagents are how breadth stays affordable. Several hypotheses get checked at the same time instead of one after another, and each subagent's context stays focused on one question.
01Alert
Pulse routes it
Noise is stripped and the real problem becomes an incident.
02Plan
Memory, then hypotheses
CloudThinker reads past lessons and splits the work.
03Evidence
Subagents in parallel
Read-only checks across code, infrastructure and tooling.
04Answer
One verdict
Root cause, the evidence behind it and a fix to approve.
05Keep
The lesson
The next similar incident starts further ahead.
Same model, different harness
We measured how much this matters. On SREGym, a live benchmark of Kubernetes faults, the same model, Claude Opus 5, closed 16 of 21 faults inside a general coding agent (the public leaderboard row) and 18 of 20 inside CloudThinker Resolve. Same weights, different harness. Our run voids one fault whose mitigation check can't pass, which is why the denominators differ. The full evaluation explains that and every other caveat.
The difference wasn't speed. It was coupling. When Resolve named the faulty resource correctly, it fixed that resource. It had zero runs where it restored the service while naming the wrong component.
That's a harness property. The verification pass, the tools and the prompt decide whether a diagnosis and a fix stay tied to each other.
The model still matters. Inside one harness, model choice moved the resolution rate from 40% to 100% across seven models. Our shorthand: the harness sets the ceiling, the model decides how close you get to it.
Every module makes it smarter
The last part of the harness is what it keeps. Each module leaves something behind that the next run starts with.
01Resolve
Incident memory
Read at the start of a later investigation.
02Review
Learnings
Rules from findings your team fixed, used on future reviews.
03Cyber
Attack surface
The next scan re-checks old findings and verifies fixes.
04Optimize
Spend picture
Refreshed daily, queried whenever cost comes up.
05Every chat
Memory and skills
Carried into the next conversation without re-explaining.
Resolve keeps incident memory. Review keeps Learnings, rules derived from findings your team fixed. Cyber keeps each app's attack surface and findings, and re-checks old findings on the next scan. Optimize keeps a daily-refreshed picture of your spend. Every chat leaves workspace memory and saved skills.
These add up across modules. An investigation into a cost spike can draw on Optimize's spend picture. An incident investigation starts from lessons Resolve kept last month.
The design decisions
Query, don't recall. CloudThinker queries your actual systems during an investigation, so its answer names your services and resources. Training data can't do that.
Connections are the outer limit. Agents can only see and act on what a workspace's connections allow. The harness widens what the agent can see, never what it may do beyond those permissions. More in The Agent Never Holds Your Keys.
Guardrails cover the whole harness. The workspace's Manual or Auto setting applies to subagents and automations too. See Auto Mode.
You control what it keeps. You can correct or remove a memory, and turn skill learning off per custom agent.
Honest limits
- The harness can't see a surface you haven't connected. If deploys live in a system with no connection, a deploy-caused incident will be harder to explain.
- Knowledge bases can't tell which copy of a document is newer. Remove outdated documents and upload the current version.
- Only documents with a Completed status are searchable, and password-protected files can't be indexed.
- Knowledge bases and memory are workspace-scoped. Agents in one workspace can't use another workspace's context.
- The SREGym numbers are self-run, single runs, and not official leaderboard submissions.
Try it
Connect your repo and one cloud or cluster connection, then upload the runbook your team uses most. Ask:
"Checkout latency went up an hour ago. Check recent deploys, the cluster and the database, and tell me what changed."
"Which surfaces can you see in this workspace, and what would you need to investigate a deploy-related incident end to end?"
"Using our runbooks, what's the escalation path for a payment outage?"