Why AI Coding Agents Lose Context After the PR, and How to Keep It | Harness Blog

The Context Cliff: What Happens After an AI Agent Opens a PR

An AI coding agent can read a repository, trace its dependencies, edit a dozen files, and open a pull request that passes its own tests. Then the PR enters the delivery pipeline, and much of what the agent learned stays behind.

The pipeline produces evidence the agent never sees: a failed build, a vulnerable dependency flagged by a scan, a latency regression after deployment, an incident traced to a change that looked safe. That evidence could improve the original change and prevent the next failure, but only if something carries it back into the engineering workflow.

Writing code is often no longer the slow part. Moving a change through build, test, security, deployment, and runtime is, and each of those stages is a question of risk. Context engineering across the SDLC is the work of connecting them.

This post covers what context an agent needs, how the Code Context Engine and the Software Delivery Knowledge Graph supply two halves of it, and what works today and what Harness has said is planned.

Context Engineering: The Right Information at the Right Time

Context engineering is the work of selecting, organizing, retrieving, and maintaining what an AI agent knows while it works on a task. It covers more than prompt wording. An agent may need architectural decisions, dependency relationships, repository conventions, test results, security findings, deployment history, and operating constraints.

Agent memory and context engineering do different jobs. Memory stores what might be useful across sessions. Context engineering decides what goes in front of the agent for the current task. A large memory store does not help when the retrieved material is outdated, contradictory, or irrelevant.

Augment Code measured the effect of retrieval quality in its February 2026 Context Engine MCP benchmark. Its most useful finding concerns model choice: a weaker model with great context (Sonnet with the MCP) can outperform a stronger model with poor context (Opus without it). MCP-enabled runs also needed fewer tool calls and conversation turns.

The test ran 300 Elasticsearch pull requests with three prompts each, 900 attempts in total, scored on correctness, completeness, best practices, code reuse, and unsolicited documentation. Adding the Code Context Engine improved results by 80% for Claude Code, 71% for Cursor, and 30% for Cursor with Composer-1. The original post ran these against Opus 4.5, and Augment's product page now lists the same figures under Opus 4.6.

These are Augment's own results on one codebase. They show that retrieval quality moves agent output, and they do not predict the gain on your repository.

Two Halves of the Problem: Code Context and Delivery Context

A repository shows how code works. It does not show which services are business-critical, which environments receive a change, or what the last deployment did. Agents need both kinds of context.

Code context comes from the Code Context Engine, which Harness brought in with the Augment Code assets it acquired. It indexes a codebase so an agent can find relevant code and its relationships instead of grepping files. Harness's governed software factory post describes it as indexing in real time across 100M+ lines, including commit history and which code is still active. The factory post says generic text embeddings help little on code, because similar-looking code is often unrelated, so the Code Context Engine uses embedding models trained on code structure. It is exposed over MCP, so any compatible agent can use it.

Delivery context comes from the Software Delivery Knowledge Graph, a typed model of how software is built, tested, secured, deployed, and operated. Harness's governed software factory post reports 80+ entity types across CI, CD, security, cost, and runtime, and says an agent question costs about 12K tokens through the graph against 250K+ through raw APIs. 

The underlying estimate is in Harness's earlier knowledge graph post. For one question, which pipelines have the highest failure rate across services and vulnerabilities, it gives about 250,000 to 350,000 input tokens and 5+ LLM calls through raw MCP API calls, against about 12,000 tokens and 2 to 3 calls through the graph. It labels the source internal benchmarking and does not describe the method, so read the figures as an order-of-magnitude illustration for one query, not a benchmark.

For how Harness checks the graph's answers, see the validation write-up, which reports 22 of 27 scenarios validated, about 81% coverage. The architecture write-up explains how schemas, synchronization, and declarative queries make those answers repeatable.

Code context explains the change. Delivery context explains its consequences.

What Works Today and What Is Planned

On October 8, 2026, Harness announced the acquisition of Cosmos, the Code Context Engine, and related technology. Cosmos is now the Harness Cosmos Software Factory Agent, which automates engineering work from idea to code.. It joins the Harness Autonomous SDLC Platform, where the Software Delivery, Security Testing, Runtime Protection, and Cost Management agents take that code to production and beyond.

What the factory post describes today (published October 13, updated October 19):

• A scan flags a critical CVE and starts a Cosmos workflow
• An Expert uses the Code Context Engine to find where the vulnerable dependency is imported, then queries the Knowledge Graph for the affected services running in production, their business criticality, and remaining SLO budget
• Fixes open as PRs, and reviewers and the Verifier check them
• Each merge triggers a pipeline, with OPA policy and approval gates set by the service's risk tier
• Continuous Verification watches each deployment, and an audit trail records the path

Connecting the Code Context Engine to the Software Delivery Knowledge Graph is described in the announcement as planned work, so read that two-way link as direction and not as a shipped feature. Harness plans three flows:

• Delivery context flows into coding, so testing expectations, security requirements, and deployment constraints inform a change before it is written
• Codebase understanding flows into delivery, so the Harness agents can make better decisions about dependencies, risk, and the validation a change needs

Findings from review, testing, security checks, and deployment verification flow back to the engineering workflow with the evidence needed to correct and revalidate the change

The practical reading: an agent can use both kinds of context in one workflow today, and the tighter two-way connection between them is the part still being built.

The Agent Harness: Context, Execution, Governance

In this post, the agent harness is the architecture around a coding agent that makes autonomous work dependable. It has three layers:

• Context gives agents the codebase, delivery, and runtime information they need to understand the task
• Execution coordinates agents and tools to plan, implement, review, test, and deliver a change through repeatable workflows

Governance enforces access controls, security policies, approvals, and audit trails so autonomous work stays inside agreed limits

The Harness agents supply the governance layer. An agent's recommendation grants no permission to deploy: policy as code, RBAC, approval gates, continuous verification, and rollback decide what proceeds. In the governed software factory design, pipeline work runs on Delegates inside the customer's own network, and a Zero Trust Service checks every task before it runs. 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. The service fails to close, so nothing executes if it is unreachable.

AI code review and governed pipelines answer different questions. Review tells you whether a diff looks correct. A governed pipeline decides whether the change may ship and checks how it behaved once it did.

One CVE, One Context Loop

A critical CVE in a shared library shows how the two kinds of context combine. The steps follow the flow Harness describes in its governed software factory post.

The diagram shows four stages, and steps 5 and 6 below are the return path through the Knowledge Graph. Solid arrows show a change moving to production and its results landing in the Software Delivery Knowledge Graph. The dashed arrow is the planned link that lets delivery context inform the next change.

1. Scope in code. The Security Testing Agent's scan names the dependency and the vulnerable version. An Expert uses the Code Context Engine to find where the dependency is imported, which functions call it, and which tests cover it.
2. Scope in production. The Software Delivery Knowledge Graph shows which affected services run in production, which are business-critical, and how much SLO budget each has left. The same library in an internal utility and in a customer-facing authentication service gets different priority.
3. Fix and review. Agents propose the upgrade, update code and tests, and open a pull request in each affected repository. Reviewers and the Verifier check correctness, security, and maintainability.
4. Gate. The Software Delivery Agent's pipeline applies policy and approval gates by the service's risk tier. A change that fails a mandatory check does not proceed.
5. Verify in production. Continuous Verification compares each deployment with a baseline captured when the deployment starts. If behavior deviates, the pipeline rolls the deployment back with the anomalous metrics and logs attached as evidence.
6. Learn (planned). Failed checks, deployment results, and runtime findings should become inputs to the next change. Harness's announcement names returning that evidence directly to the engineering workflow as its next step.

The loop reads detect, understand, fix, verify, deliver, learn. Governance decides which steps run without a person. The same pattern applies to a failed deployment, a regression, or a recurring incident.

What the Pieces Look Like in Practice

One small example per layer. The first two come from the vendors' docs. The third was tested locally.

Add the Context Engine to Claude Code over MCP in local mode (Augment's quickstart):

npm install -g @augmentcode/auggie@latest

auggie login

claude mcp add-json auggie --scope user '{"type":"stdio","command":"auggie","args":["--mcp","--mcp-auto-workspace"]}'

For CI and other non-interactive environments, the quickstart adds an env block with `AUGMENT_SESSION_AUTH`, set from the output of auggie token print.

Delivery context. The Knowledge Graph takes questions in plain language. Harness's docs give examples such as "Which production deployments of payment-api failed policy evaluation during the last seven days?" For structured queries, the Harness CLI runs HQL:

harness execute hql:run --query 'find entity "platform:project" | select { * } | limit 10'

Entity names for deployments and policy evaluations come from hql:grammar.

Governance. This policy denies any deployment stage that has no approval step, so a change an agent wrote cannot reach an environment without a person signing off. It follows the pattern in Harness's Policy as Code quickstart:

package pipeline

deny[msg] {
  input.pipeline.stages[i].stage.type == "Deployment"
  not stages_with_approval[i]
  msg := sprintf("Deployment stage '%s' has no HarnessApproval step", [input.pipeline.stages[i].stage.name])
}

stages_with_approval[i] {
  input.pipeline.stages[i].stage.spec.execution.steps[_].step.type == "HarnessApproval"
}

Add it to a Policy Set on the Pipeline entity, evaluated On Run, with Error and exit as the failure behavior. Against a pipeline whose deployment stage has only a ShellScript step, it returns the deny message. With a HarnessApproval step added to that stage, it returns an empty list. We checked both cases with OPA 0.70.

What Teams Should Evaluate Before Trusting an Agent

A coding agent can produce a plausible patch without understanding production risk. A pipeline can report success without proving the application meets its operating goals. An incident agent can propose a root cause from a correlation. Each gap comes from missing context or missing verification, and a stronger model alone closes neither.

A dependable autonomous workflow answers three questions:

1. Can the agent understand the situation? It needs current code and delivery context.
2. Can it act within boundaries? Permissions, policies, and approval rules limit what it may do.
3. Can the organization verify the outcome? Tests, deployment checks, runtime signals, and audit trails supply the evidence.

The risk tier decides how much autonomy a change gets. In the Cosmos design, a low-risk PR can be routed to policy-gated auto-approval, and a higher-risk one waits for a person. Auto-approval can be widened one class of change at a time.

The factory post has the exact auto-approval rules and the Cosmos team's own merge and revert numbers. Those are internal, vendor-reported figures, so read them with that in mind. Judge an AI coding agent by more than how fast it produces a patch. Ask whether it can:

• Retrieve the architectural and repository context a change touches
• Identify the services and dependencies a change affects
• Use security and delivery evidence to prioritize work
• Operate inside explicit permissions and policy boundaries
• Produce changes that can be tested, reviewed, and traced
• Use verification outcomes to improve later work

A strong model, a large context window, and specialized agents cover only part of the problem. The rest is an architecture that connects context, execution, governance, and evidence across the SDLC.

Where to Start

Cosmos is available now. Pick one workflow, such as turning a ticket into a reviewed pull request, and run it against the delivery pipeline you already have. The Harness agents take a change to production, whichever coding tools wrote it, and the Harness Developer Hub covers the delivery side.

To try the Context Engine with your own agent, Augment's February 2026 post describes two MCP modes. Local mode runs the Auggie CLI as an MCP server and suits active development. Remote mode connects to a hosted MCP for context across all your repositories. Setup is in Augment's MCP docs.