Inside a governed software factory: Harness and Cosmos | Harness Blog

Harness: governed software delivery

Harness gets code changes into production safely and proves that they got there safely, across build, test, security, supply chain, deployment, cost, and runtime. Our 1000+ enterprise customers rely on it, with Citi cutting release times from days to seven minutes across 20,000 engineers.

Harness is organized as four governed agents for everything that happens to a code change once it exists: build, scan, deploy, verify, cost, and what production does next.

• Software Delivery takes a change to production: CI/CD, approvals, verification, and rollback if needed.
• Security Testing keeps exploitable CVEs from shipping by scanning, triaging, and proving a fix with pipeline evidence. The patch itself still comes from a coding agent.
• Cost Management keeps the spend inside the budget by acting on anomalies and shipping right-sizing as reviewed changes.
• Runtime Protection watches production signals and incidents and turns findings into new work for the factory.

Harness: four governed agents on one execution stack

The agents sit on one execution stack, designed so they are safe to run in production:

• Governed execution: Pipeline work runs on Delegates inside the customer’s own VPC or Kubernetes cluster, which connect to Harness only through outbound connections. Secrets are resolved at runtime from the customer’s vault and never stored in plaintext by Harness, and separate Delegates per environment keep dev credentials away from production. This matters because open execution models fail in predictable ways: in the March 2026 Trivy supply-chain attack, a compromised GitHub Action exposed secrets from 10,000+ CI/CD workflows by reading them from runner memory. (details)
• Zero Trust Service: A customer-operated service checks every Delegate task before it runs and fails closed, so if it is unreachable, nothing executes. Validators chain in Go: shell scripts are parsed into an AST and checked against a command allowlist, container images against a registry allowlist, and each step against the resolved pipeline YAML. Custom policy engines can plug in through a webhook. (details)
• Worker agents run as pipeline steps, so a failed build can be fixed in place instead of waiting for a human. Each runs in a non-root container with a read-only filesystem outside its workspace and network access limited to approved MCP servers. Its token is minted per run, scoped to the intersection of the agent’s permissions and the triggering user’s RBAC, and deleted on completion. The same OPA policies that gate production deployments gate the agent, so it cannot merge to main even if its prompt tells it to. (details)
• Continuous Verification checks every deployment against observability data. It captures the stable version’s behavior as a baseline when the deployment starts, uses unsupervised ML to decide whether a deviation in metrics is meaningful, and clusters logs to flag error patterns that didn’t exist before. A failed verification triggers rollback, with the anomalous metrics and log clusters attached as evidence. (details)
• The Knowledge Graph is a typed model of 80+ entity types across CI, CD, security, cost, and runtime. Schemas live as code, so the query compiler rejects invalid fields or joins before execution, and an agent’s question costs about 12K tokens compared with 250K+ through raw APIs. Records from different tools are reconciled with confidence scores; low-confidence matches go to human review, and each entity records its source and lineage. Answers are validated end-to-end against Harness APIs and the product UI, which caught issues such as ingestion lag and double-counted retries. (architecture, evaluation)

Governance in practice

A large financial institution running Harness noticed that production pipelines could still be edited by hand. It moved pipeline authoring into a separate non-production organization, required production pipelines to come from centrally approved templates enforced by OPA, and made Git the source of truth, with every template change going through a pull request approved by platform, security, and change management. Months later, an engineer tried to edit a production pipeline directly; the policy rejected it, and the change went through the approved path instead. (details)

Cosmos: The Software Factory

Since launching three months ago, Cosmos has moved dozens of engineering organizations from prompting agents to running software factories.

Cosmos accelerates engineering by enabling teams to build software factories that run continuously, with people stepping in only where their judgment is needed.

Software factories start work in response to events such as a PR opening, an alert firing, or a ticket being filed, and coordinate agents through structured workflows. Each step, run by an Expert or another agent, turns one artifact into the next (a spec into a PR, an alert into a fix), and humans approve at defined checkpoints. Factories are defined as code, so they are versioned, reviewed, and rolled back like any other change.

The factory is not finished when the pull request opens. It is assigned to a surface - a repository, a service, a class of finding - the way a team is. If verification fails, the same Experts see the evidence. If a revert fires, they pick the work back up. If the next CVE hits the same library, they already know which services matter and which tests cover them. That is different from a coding agent that opens a PR and disappears. 

The factory stays with the service

Cosmos on Cosmos: Its own software factory

Cosmos’s engineering team runs its own development on Cosmos, with specialized Experts on each transition of the lifecycle:

After the merge, a deterministic deployment pipeline ships the change. Across 17,200 merged PRs from November 2025 to July 2026, size-adjusted output per developer rose 4.5x, median time to merge fell from 11.2 to 3.1 hours, and the 14-day revert rate fell from 1.9% to 0.4%. Human touchpoints per PR dropped from 10–15 to three: reviewing the design report, inspecting the Verifier’s evidence, and making the merge decision. (Full write-up)

Lessons from production

• Automate where work piles up. Growing queues show where the next agent belongs, which is why code review was automated before anything else.
• Give agents the context engineers have. Repository access isn’t enough; agents also need CI, test environments, logs, metrics, and runbooks. As the incident management work puts it, “each input it can’t reach is a class of root cause it can’t find.” With that access, the Incident Investigator handles 81% of incidents and cuts the median time to first RCA from 30 to 6 minutes. (details)
• Use specialized Experts. “A single Expert burdened with six responsibilities will do a substandard job of each,” so the review is split across five dedicated agents.
• Make the design doc the key human artifact. Once a human has vetted the design, a single agent holding the full design produces a more coherent change than several agents with partial context, and “‘small PRs’ was always a workaround for human review bandwidth.” Project Builder shipped a 24K-line GitLab integration in 16 days with 2.5 engineers. (details)
• Expect adoption to lag deployment. Teams needed weeks to tune guardrails and learn to trust each agent.

Cosmos architecture

Agents in Cosmos are powered by a common platform:

• Event-driven cloud agents. Agents wake on triggers such as a PR, an alert, a Slack message, a schedule, or a webhook, and stay subscribed to the work they start, following a PR through CI, review, and merge. Each session runs in a fresh, isolated VM, or on a team’s own machines through self-hosted daemons, and can spawn worker Experts for subtasks. 
• Context Engine lets agents work reliably on large, real codebases. Agents without it grep files and replay broad spans into the model, and every miss costs another tool call and eventually a context reset. Generic text embeddings help little, because similar-looking code is often unrelated, while related code (a caller, a config, a test) often looks nothing alike. Context Engine uses embedding models trained on code structure and indexes in real time across 100M+ lines, including commit history and which code is still active. It is exposed over MCP, so any agent can use it. [Benchmark scores; link to Context Engine.]
• The Auggie CLI was rebuilt around a minimal tool surface (bash, read, edit, write), since every tool schema is sent on every model call, with compaction as its own subsystem. On SWE-bench Pro, it matches Claude Code’s pass rate at 53% lower cost per task. (details).
• Factory as code. Experts, environments, and workflows are defined in versioned YAML, reviewed as diffs, applied through the Auggie CLI, and rolled back by reapplying an earlier version (details).
• Memory. Experts record what they learn from human feedback, such as review comments, incident follow-ups, and triage corrections, into shared knowledge that other Experts read before they start work. The knowledge the Incident Investigator picks up during an incident becomes available to code review.
• Prism routes each turn to the model that fits the work, switching only when the expected gain outweighs the cost of losing the prompt cache. Cosmos optimizes for cost per successful outcome rather than cost per token. (details)

A factory can include prebuilt Experts, custom agents, or the four Harness agents. Cosmos writes the code. When the change needs to be built, scanned, shipped, or verified, the factory calls the Harness agent that owns that path. That handoff is how the change ships. It is not how the factory forgets the service.

Out-of-the-box Experts

Cosmos ships with Experts for the most common factory steps, and teams can customize them or build their own:

• Code review is split across specialized Experts tuned for the whole path from PR to merge, not just time to first comment. Risk Analyzer classifies each PR and routes low-risk changes to policy-gated auto-approval. Deep Reviewer checks for objective defects against the repo's AGENTS.md guidelines, and Pair Reviewer walks a human through intent and tradeoffs. PR Fixer repairs review findings, CI failures, and merge conflicts on any PR. Judgment-heavy steps run on GPT-5.6 Sol and bounded, mechanically checkable ones on GPT-5.6 Luna, because the model with the cheapest tokens often costs more per successful outcome (details).
• Verifier deploys each PR to an isolated environment, exercises the affected behavior, and attaches logs, screenshots, and Playwright traces to the PR. It reports evidence rather than a pass/fail verdict. In one case, CI was green, but the Verifier showed the fix was wired only into the /chat handler and not /chat-stream (details).
• Incident Investigator reacts to PagerDuty alerts in incident channels and posts a root-cause analysis with a recommended action: monitor, fix, roll back, or escalate. It works with the same access an on-call engineer has, including logs and metrics through gcloud, cluster state through kubectl, and runbooks kept in the codebase. It now handles 81% of incidents and cuts the median time to first RCA from 30 to 6 minutes (details).
• Project Builder turns a short feature description into a codebase-grounded design doc, gets a human's approval, and then coordinates PR Author workers until the work is merged. It shipped a 24K-line GitLab integration in 16 days with 2.5 engineers (details).

A factory can combine these Experts with custom agents and the four Harness agent loops, and it hands work to Harness whenever it needs to reach production.

One platform: a change, end to end

Coding agents understand code but don’t own the build, scan, deploy, or production signal, while Harness owns all of that without reasoning about the code. Following a single critical CVE through both systems shows how they fit together.

One critical CVE, end-to-end

1. Trigger. A security scan flags a critical CVE in a widely used library, which starts a factory workflow in Cosmos.
2. Scope. An Expert uses Context Engine to find where the vulnerable dependency is imported, which functions call it, and which tests cover it. It queries the Knowledge Graph to find which affected services run in production, which are business-critical, and how much SLO budget each has left.
3. Plan and fix. The Expert prioritizes services by risk and hands each fix to a PR Author, which opens a PR in every affected repository.
4. Review and verify. Risk Analyzer, Deep Reviewer, and Pair Reviewer review each PR. The Verifier deploys it to an isolated environment and attaches runtime evidence. Low-risk PRs can be approved through cosmos approve, and a human makes every merge.
5. Deliver. Each merge triggers a Harness pipeline. Delegates execute it inside the customer’s network, the Zero Trust Service checks each task before it runs, and OPA policy and approval gates apply based on the service’s risk tier.
6. Verify in production. Continuous Verification compares each deployment against its baseline and rolls back automatically if behavior deviates.
7. Prove. The factory’s record of decisions and the pipeline’s audit trail together give a complete trail for each service, from the CVE alert to the verified production change.

Context Engine and the Knowledge Graph give each agent both code and platform context. The factory decides what work happens, and Harness makes sure each change reaches production safely, with one governance model of OPA, RBAC, and audit across both.

The seventh step is not the last time the factory sees that service. Runtime Protection turns a production signal into new work. The same Experts who scoped the CVE are still responsible for the services they patched - the next finding in the same library is not a cold start, and a failed verification does not get dumped on a human who has to reconstruct what happened.

Context that gets better

Context Engine does not freeze the day it is indexed. It updates as the code changes, including which paths are still active. The Knowledge Graph does the same for the platform: new deploys, new findings, and new cost anomalies become queryable the next time an agent asks.

On top of both, the factory keeps a memory of what worked. Memory Manager turns review feedback into a knowledge base for each repo. Evidence from the Verifier and from Continuous Verification feeds the next run. Over time, the factory gets better at the same work - a shorter path, a clearer stop for a human - because its own outcomes accumulate. The process is still versioned, reviewed, and rolled back like any other change. Nothing here rewrites the factory in the dark. What improves is the next decision, under the same governance that already gates a deploy.

Context that stays current, and a factory that gets better

The continuous feedback loop

In a software factory, work continues after a PR merges. What happens in production feeds back into the next round of work through three loops:

• Production signals become new work. Continuous Verification, Runtime Protection, and the Incident Investigator watch the services each change touches. A regression, alert, or user report becomes a new trigger, along with its evidence. At Augment, the Incident Investigator handles 81% of incidents, and the Feedback Triager cut a two-person team's time on product feedback from about 90% to 30%.
• Outcomes become context. Review comments, incident follow-ups, and triage corrections are stored in Expert memory, and deployment results are stored in the Knowledge Graph. Each change starts with what the factory learned from the last one.
• Autonomy increases. Verification results, revert rates, and audit trails show which kinds of change the factory handles reliably. Organizations can use that record to widen auto-approval one class of change at a time, through OPA risk tiers or cosmos approve.

With each pass, the factory has better context and a stronger track record, so it can take on more of the work.

Trust is the bottleneck

Software factories make engineering work much cheaper to run, turning tickets into PRs and alerts into fixes and remediating CVEs across dozens of services. What limits broader adoption is less what agents can do than whether organizations can trust what they do in production (more on this). Our own data suggests speed and quality can rise together: after the review moved to Cosmos, weekly output tripled while bug-introducing commits per unit of output fell from 0.097 to 0.006 (details). Before deploying a factory, an organization needs to answer three questions:

• Can we control it? Harness pipelines enforce policy, RBAC, scoped credentials, and approval gates on every action, and the Zero Trust Service checks every task before it runs. Inside the factory, "cosmos approve" auto-approves a PR only when the requester owns every changed file, no review findings are open on the current commit, and the Verifier has found no contradicting evidence, and a human still makes the merge.
• Can we predict it? Agents execute through deterministic pipelines, informed by typed data from the Knowledge Graph, and Continuous Verification rolls back any deployment whose behavior deviates from its baseline. 
• Can we prove it? Every change carries a trail from its triggering event through the factory’s decisions to the pipeline’s audit log and production evidence. The Verifier adds runtime evidence that reviewers can replay locally.

Governance and autonomy are often framed as a tradeoff, yet governance is what lets an organization give agents more autonomy. The same factory can act on its own on a low-risk service and stop for approval on a high-risk one.

Harness and Cosmos together give enterprises a software factory they can deploy with confidence - one that ships a change all the way to evidence, stays with the service afterward, and gets better at the work because it remembers what happened last time. 

The bottleneck to AI in software engineering is not code generation - it is trust. By combining Cosmos’s continuous, context-aware reasoning with Harness’s zero-trust execution stack, enterprises no longer have to choose between developer velocity and production safety. Autonomous software delivery is not about generating 10× more PRs. It is about owning the outcome: shipping verified, governed software to production, learning from what happens there, and carrying that evidence into the next change.