A harness can stop unsafe code from shipping, but it cannot tell an agent that an integration already exists, which domain rule applies, or why an architecture decision was made. Context engineering makes that knowledge available when the agent needs it.

Context engineering: the missing layer in a governed AI SDLC

An agent can follow a specification, use approved tools, and pass a pipeline while making the wrong enterprise decision. It may build an integration that already exists, introduce a pattern that conflicts with an earlier architecture decision, or miss a constraint absent from its task. The model, specification, and quality gate may each have worked as intended. The agent lacked the context required for the decision.

Context engineering makes relevant enterprise knowledge, rules, history, and current state available to people and agents in a usable, governed form. For organisations adopting AI in the SDLC, it is delivery infrastructure.

Earlier articles in this series argued that specifications express intent, harnesses guide agents and verify their work, and risk-based governance focuses human judgment on consequential decisions. Context gives those mechanisms meaning for a specific change. Without it, an agent can satisfy generic controls and still introduce local inconsistency.

A harness needs something meaningful to enforce

Harness engineering and context engineering address different parts of the problem.

The harness is the environment in which an agent works: its instructions, available tools, sandboxes, orchestration, checks, and feedback. Guides influence the agent before it acts. Sensors detect problems afterwards and support correction. Tests, type checks, dependency scanning, policy controls, and review workflows can all be part of a harness [1].

Context supplies the material those components use. It tells the agent which domain model applies, who owns a service, whether a capability already exists, which interface is approved, what data constraints apply, and why an architectural boundary matters. Böckeler describes harness engineering as a specific form of context engineering because context is how guides and sensors reach the agent [1].

A retrieval system can find an old architecture decision without making an agent follow it. A guardrail can block a dependency without explaining the approved alternative or the business reason for the restriction. Agentic delivery requires both context and a harness.

A loop makes the harness repeatable

Loop engineering covers the recurring cycle around a task: finding or receiving work, assembling task context, assigning execution, verifying the result, retaining state, and deciding what happens next. A loop can run on a schedule, coordinate specialist agents, and use earlier results as input to later runs [5]. A harness governs the working environment for one task; a loop governs the work across tasks.

The following approach shows the path from an immediate request to repeatable delivery. It is not a technical hierarchy. Context can be delivered through the harness, and harness instructions are themselves context.

Prompt → task context → harnessed execution → delivery loop

The prompt is the immediate request. Task context gives it enterprise meaning. The harness supplies the tools, constraints, and feedback for safe execution. The loop makes work repeatable, observable, and improvable over time. A context service can contribute at several points; the harness applies selected context through instructions, tools, and checks.

A maintenance loop, for example, may examine overnight CI failures and dependency alerts, retrieve the affected service’s ownership and architecture context, create an isolated workspace, and assign an agent to propose a repair. A separate verifier checks the proposal against the specification, relevant skills, and existing tests. The loop opens a pull request for routine work, escalates uncertain cases to an accountable owner, and records the outcome. If the same failure recurs, the team should improve either the context, skill, check, or workflow instead of repeatedly correcting generated changes.

Important, unattended delivery still needs explicit safeguards. Parallel agents increase the need for stopping conditions, evidence, and review capacity. A loop can remove manual coordination, but accountability remains with the people responsible for the system being changed.

The context problem is organisational before it is technical

Most enterprises already have much of the knowledge an agent needs, but it is spread across source code repositories, Confluence spaces, APIs, architecture decision records, collaboration systems, and the experience of long-serving staff. These sources are often inconsistent, hard to find, and disconnected from the work where a decision is made. They are rarely available in a standardised, machine-readable form.

Consider an agent asked to add payment processing to an order service. It needs to establish whether an integration already exists, what data classification applies, which team owns the payment boundary, the approved failure-handling pattern, and the decision record that explains it. A generic coding instruction cannot supply this reliably. Loading every document into every session would consume tokens without improving the decision.

The design trade-off is relevance against completeness. Google’s SDLC guidance distinguishes static context, which is always loaded, from dynamic context retrieved for a task. Excessive always-on material uses tokens and important signals; too little material can omit critical rules. The guidance recommends treating that boundary as an architectural decision that is reviewed and versioned [2]. That principle applies even where teams use different tools.

In addition, access control belongs in the context design. An agent querying related information must not automatically see sensitive design discussions or customer data. The context service should scope each task to the caller’s verified permissions, return only approved material, and log retrieved data and access denials. When an agent acts for a person or team, the delegation needs an explicit, bounded policy. It does not grant a general right to search enterprise knowledge. Teams must design and validate these controls. In accordance with the principle of least privilege, this also applies to AI agents.

Build a managed context product

Start with a small context product for a bounded delivery domain: a topic such as “AI in SDLC”, a business domain, a process workflow, or a recurring class of changes where inconsistent decisions already create rework or risk.

For the chosen domain, make the minimum useful context explicit:

• business concepts, invariants, and acceptance criteria
• approved integration and implementation patterns, including examples that remain valid
• architectural decisions, their rationale, and the boundaries they govern
• ownership, dependencies, and escalation paths
• applicable security, privacy, and regulatory constraints
• the current state, including known capabilities, open migrations, incidents, and decisions in flight

This is the same discipline that supports sound architecture and documentation across a system landscape.

Each item needs an accountable owner, with source of truth, access classification, and review trigger. The product also needs a way to report material that is missing, contradictory, or stale. Its purpose is to provide dependable, bounded answers to recurring delivery decisions, not to become a comprehensive document store.

Operate context as a shared capability

Context engineering is a shared capability across the product development lifecycle. Product and domain owners maintain business meaning, priorities, and acceptance criteria. Architects curate boundaries, principles, patterns, and decision rationale. Security, privacy, and risk functions define constraints and required evidence. Platform teams operate retrieval, policy enforcement, observability, and harness capabilities. Delivery teams expose gaps during their work and keep implementation knowledge current. The same model can apply to any group or subject area.

This division of responsibility makes a decision usable outside the meeting in which it was made. People and agents must be able to discover, understand, and apply an architecture decision. After a production incident, teams should ask whether it revealed a missing context item, an inadequate guide, or a sensor that failed to detect a known risk.

Teams also need clear interfaces between these responsibilities. They need to know where an authoritative pattern lives, who can change it, when a local exception is permitted, and how the decision reaches the agent workflow. IBM IBV frames this as an operating-model change in which people, agents, data, KPIs, ethics, and workflows learn from outcomes [6]. Its survey findings are directional rather than a blueprint for an individual enterprise. They support the need to redesign the work system around agents instead of inserting them just into existing handoffs.

Connect context to the flow of work

Context should accompany delivery work rather than sit in a separate “knowledge-management” programme. In planning, agents can retrieve relevant architectural and technical constraints, along with existing capabilities, before a specification is created. During implementation, they can load task-specific skills, patterns, and interface contracts. In review, reviewers should see the context that informed a change, sources that were unavailable or contradictory, and the controls that assessed the result. Incidents and observed production behaviour should identify candidates for improving the context and harness.

Each delivery activity produces useful evidence: metadata, decisions, and outcomes that can improve the context available for the next task. To make use of it, the context layer must connect to the systems where work, code, architectural decisions, and operational data are recorded. Those connections must preserve the permissions and access rules of each source.

Governance defines authority, access, and escalation

Governance establishes whether context and controls can be trusted at scale. It determines which sources are authoritative, who may change shared instructions and patterns, how task-scoped access is approved, what evidence must be retained, and when ambiguity requires human judgment. An approval queue after an agent has completed its work cannot provide these controls.

Context can conflict. A three-year-old decision record may prescribe one approach while a current service contract or security policy requires another. Teams should expose the conflict, involve the affected decision owner, and record the resolution where later work can use it. An agent should not choose the document that merely appears most plausible.

The same discipline applies to harnesses and loops. A change to a shared skill, retrieval policy, guardrail, or escalation rule can affect hundreds of later changes. These are controlled delivery assets: version them, assign owners, test their effects, and review them in proportion to their reach. The relevant governance question extends beyond whether a pull request was approved. It includes who designed, tested, and is accountable for the system that generated and judged the change.

Human attention belongs on unresolved trade-offs, material risk, and changes to approved boundaries. Routine work can proceed within a well-understood pattern. People remain responsible for decisions that cannot be reduced to an (automatic) check, and for improving the conditions in which agents work.

Measure freshness, decision quality, and value

Incorrect context can create more confidence than no context at all. Freshness therefore needs operational treatment. Link updates to events that change reality, such as interface releases, policy changes, architecture decisions, ownership transfers, incidents, and retired services. Flag material with no owner or review date, and material that refers to an obsolete dependency.

Start with a delivery outcome rather than the number of documents ingested. DORA recommends mapping workflow, wait times, and handoffs to focus improvement efforts [3].

DORA’s AI ROI guidance cautions that AI amplifies the delivery environment it enters. Faster code generation can increase local productivity while adding verification effort, review queues, instability, and technical debt downstream. DORA describes this early adaptation as a J-curve: teams invest in learning, verification, and pipeline changes before reliable value is realised [7].

Measure throughput and stability together. Lead time, deployment frequency, change failure rate, and recovery time show whether faster agent execution improves delivery or moves work into testing, approval, or incident response. The investment case should include context curation, platform capability, model use, and human oversight. Link any delivery improvement to the outcome that matters in the chosen domain.

These measures cannot attribute every outcome to context. They can expose the cost of fragmented knowledge and weak controls and help teams improve the relevant knowledge layer.

What leaders should do now

1. Select one high-value, repeatable delivery domain and map the decisions agents and reviewers make repeatedly.
2. Identify authoritative sources, missing knowledge, owners, sensitivity classifications, and context-update triggers.
3. Expose the smallest useful set through the agent workflow as a knowledge graph, with source links and task-scoped permissions.
4. Provide a way to report missing or contradictory context.
5. Encode stable rules in the harness and retrieve task-specific knowledge by querying the knowledge graph.
6. For recurring work, design a bounded loop with separate generation and verification, persistent state, stopping conditions, and named escalation owners.
7. Review incidents, exceptions, and delivery-flow data. Improve the context, harness, or loop that contributed to the failure.

The aim is to give agents authoritative, current context for decisions within clear boundaries, while directing uncertainty to a person who can decide.

References

1. Birgitta Böckeler, “Harness Engineering for Coding Agent Users”, 2026-04-02. Defines the outer harness, feedforward and feedback controls, and the relationship between harness and context engineering.
2. Addy Osmani, Shubham Saboo, and Sokratis Kartakis, “The New SDLC With Vibe Coding: From Ad-Hoc Prompting to Agentic Engineering”, May 2026. Discusses context types, static and dynamic context, harness components, and the shift in engineering work.
3. Andrew Davis and Rob Edwards, “How to Use Value Stream Mapping to Improve Software Delivery”, retrieved 2026-05-29. Describes outcome mapping, delivery and recovery value streams, and the use of flow data to target improvements.
4. Muhammad Haseeb, “Context Engineering for Multi-Agent LLM Code Assistants”, arXiv:2508.08322v1, 2025-08-09. Proposes a workflow combining intent clarification, retrieval, document synthesis, and specialised agents; findings should be assessed against the publication’s methodology and target environment.
5. Addy Osmani, “Loop Engineering”, 2026-06–07. Defines loops as recurring systems for discovering, assigning, verifying, recording, and continuing agent work; distinguishes the loop from the individual agent harness.
6. IBM Institute for Business Value, “Agentic AI’s Strategic Ascent: Shifting Operations from Incremental Gains to Net-New Impact”, August 2025. Reports executive survey findings on operating-model redesign, trust, workforce readiness, data, and governance in agentic AI adoption.
7. DORA, “The ROI of AI-Assisted Software Development”, 2026. Describes AI as an amplifier of existing delivery systems, the J-curve of adoption, verification overhead, and the need to assess throughput and stability together.

Disclaimer

This article is part of a series exploring challenges and approaches in AI for SDLC and PDLC, covering architecture, methods, and sovereignty.

The AI space moves fast. What works today may feel outdated tomorrow and wrong the day after. Review these ideas critically and decide what applies to your context.

These views reflect the state of knowledge at the time of writing. No guarantee of correctness, especially as the field evolves.

AI assistance was used to support drafting and editorial refinement, including language polishing, as English is not the author’s native language.

Last Updated: 2026-08-22

See also

• The governance speed gap: harnesses, review, and accountable AI delivery
• Why SDD fails without harness engineering
• Vibe coding is dead (but your org still does it)
• Use, Adapt and Integrate Enterprise-Grade Agentic AI Frameworks: A Series