Engineers certifying software against DO-178C for airborne software and hardware against DO-254 can’t ship an artifact that’s almost right, and neither can a quality lead pulling together design-control evidence for a submission. In that setting, almost right is an audit finding waiting to happen.
Almost right is exactly what artificial intelligence (AI) agents produce. Across more than 31,000 developers surveyed in 2025, 66% reported hitting AI output that is “almost right, but not quite”. That was the most-cited frustration with AI tools, and 45% said debugging AI-generated code is more time-consuming. A productivity tax turns into an audit finding when the agent was not reading an approved, versioned record the team could trace. This guide covers why agents fail on context, what every context engineering technique leaves to the source it reads, and what changes when approved requirements with live trace links become that source.
What Is Context Engineering?
Context engineering decides what a model sees at each inference step. Requirements and retrieved documents compete for the same context window with tool outputs and whatever the agent remembers of earlier turns, and something has to choose among them. Prompt engineering governs how an instruction is phrased. Context engineering governs what sits in front of the model while it reads that instruction. Choosing which requirement version, which linked artifacts, and which prior turns survive into the window is systems engineering work, and the team does it before the agent ever runs.
Take an agent we ask to draft test cases for a battery management system. It gets the approved requirement, the hazards that requirement mitigates, and the test cases already linked to it. It does not get the email thread where the threshold was argued over, or the superseded revision still sitting in a shared drive. What we leave out is as much of the work as what we send.
Retrieval-Augmented Generation (RAG) handles the retrieval piece of that job, and it answers which documents look relevant to a query. It can’t answer whether the document it found is the approved version, whether that version is current, or whether anyone can prove later which version the agent read. Memory management and tool orchestration run into the same limit. Before any of them can help, though, we have to deal with the mechanics of the context window itself.
Why Do AI Agents Fail Without Accurate Context?
Agents fail on context in two ways, and only one of them is ours to fix. One failure is mechanical: accuracy drops as the window fills, and the model quietly favors what it learned in training over what we just handed it. The other sits in the specification, where a requirement that reads clearly to an engineer leaves an agent to guess at a threshold nobody wrote down.
Long Context Degrades Before the Window Fills
With long-context models, accuracy falls as input length grows. Models retrieve information most reliably from the beginning or end of an input and degrade significantly when the relevant material sits in the middle. Practitioners have started calling this context rot, and it sets in well before the full window is reached. Advertised context-window length is not a reliable measure of usable performance.
Models can also fall back on training knowledge when retrieved context conflicts with it. An agent analyzing medical device software applies an outdated clause of IEC 62304, the medical device software lifecycle standard, that it learned during training. On the surface it looks like it is working from the current version we gave it. Nothing in the output signals the substitution.
None of this is a requirements problem. Context rot and positional degradation are properties of the models themselves, and no amount of requirements discipline will fix them.
Specification Problems Outrank Everything Else
A 2025 analysis of more than 200 tasks across seven multi-agent frameworks sorted failures into 14 modes in three categories. The largest of the three, at 41.77%, was specification issues, which covers system architecture decisions, unclear task specifications, and agents that disobey the roles they were given. The authors caution that each system was measured on a different benchmark, so the failure rates they report cannot be compared across systems. Taken one at a time they are still low, and ChatDev returned correct output on 33.33% of the tasks in the study’s program-development benchmark.
The same failure logic operates one level up. Inside an agent system, a specification is a prompt and a role definition. In a regulated program, it’s the requirement the agent is building against, and that requirement is reviewed and versioned by the team before the agent ever sees it.
So which of the two can better tooling fix?
Every Context Engineering Technique Hits the Same Ceiling
Every technique we have for managing an agent’s context controls which records the model sees. None of them can tell the model which record is approved.
Four Techniques Manage Which Records the Agent Sees
The four that show up in nearly every production agent architecture all try to supply the smallest set of high-signal tokens likely to produce the right outcome:
- Compaction: The agent framework summarizes a conversation nearing the context limit and reinitiates a fresh window with the summary before accuracy starts to slide.
- Structured note-taking: The agent writes notes to memory outside the window and pulls them back into context on later turns.
- Sub-agent isolation: Specialized sub-agents explore focused tasks with clean windows. They spend substantial token budgets and return condensed summaries.
- Just-in-time retrieval: The agent pulls context through tool calls as the task demands.
A safety requirement for a battery management system sits in an email thread, in a SharePoint document, and in a Jira ticket, each carrying a different threshold value. A verification engineer three weeks from a design review has no way to know which one the agent read. Retrieval will fetch one of those versions, and whichever it fetches is the one compaction summarizes and isolation quarantines. Memory can make it worse, because a note summarizing a safety requirement loses the nuance, and every later action runs on a degraded copy.
Certification Demands a Traceable Chain
Certification adds a demand that relevance can’t satisfy. DO-178C requires bidirectional traceability across five artifact types: system requirements, high-level requirements, low-level requirements, source code, and test results. ISO 26262, the functional safety standard for road vehicles, places requirements management among the supporting processes in Part 8 that a program runs from the start. Neither chain can be built out of documents, however well versioned, that carry no links between them.
The difference between the two kinds of source is version authority the team can defend:
| Scattered Documents as Agent Context | Structured Requirements With Live Trace Links | |
| Version authority | Multiple conflicting copies | One approved, versioned item |
| Relationships | Implied in prose, invisible to agents | Explicit links from requirement to design to test to verification result |
| Change impact | Manual re-checks after the fact | Downstream artifacts flagged when an upstream item changes |
| Audit evidence | Reconstructed before each review | Produced from live project data |
Nothing in the technique list produces the right-hand column. Every row in it is a property of the system the records live in, which puts the fix upstream of the agent.
Spec-Driven Development Puts Requirements in Charge
Spec-driven development makes the specification the artifact of record and the code a derivative of it. A full walkthrough of the practice is worth reading alongside this section, which takes up what spec-driven development inherits.
Agents Inherit Whatever the Spec Says
Spec quality sets implementation quality whenever agents execute from specs, and the dependency only runs in that direction. In GitHub’s Spec Kit, agents follow a version-controlled specification through a Spec, Plan, Tasks, Implement sequence. Other spec-driven toolchains name the phases differently.
The trouble starts there, because ambiguity in a requirement leaves the agent to resolve it, and different runs resolve it differently. When we hand an agent “the system shall respond quickly,” it picks a threshold, and the threshold changes between runs.
An agent inherits whatever practice we point it at. Written-down decisions and automated tests give it something to build against. If the same knowledge lives in people’s heads, it has nothing to read and reproduces the team’s disorganization faster.
Spec-driven development doesn’t escape that, and it is the practice most teams adopting agents are already moving toward. That’s where the debugging cost from the opening comes back, because time saved writing gets re-spent reviewing. Checking generated code against an approved requirement is narrower work than checking it against nothing in particular.
What the EU AI Act Asks the Record to Prove
The European Union (EU) AI Act puts the evidence requirement in statute. Article 12 requires high-risk AI systems to allow automatic logging of events across the system’s lifetime, and every system in scope needs a risk classification before that applies. Logging an agent’s actions is only useful if we can resolve each one to the requirement the agent was working from.
That obligation lands on the connection between the agent and the engineering system it reads from. The Model Context Protocol (MCP), an open standard for exposing structured data and tools to AI applications, is that connection in most production setups, and systems engineering and software teams are already using MCP servers for production AI workflows. In regulated deployments, MCP servers that use shared application programming interface (API) keys may not produce attributable audit records, so every AI-initiated call has to resolve to a specific user and session before an Article 12 log is worth reading.
How Jama Connect Supports Context Engineering
Jama Connect®, a web-based requirements management and traceability platform for complex, regulated product development, provides the Product Context Layer that agent context engineering is missing. That layer is a governed system of record connecting requirements, risks, tests, SysML models, code repositories, simulations, defects, reviews, approvals, verification evidence, and change history, and at its center the Traceability Information Model (TIM) defines how those artifacts relate to one another. Spec-driven development depends on a specification of record that is reviewed, versioned, and linked to what it governs, which is what the TIM already holds. The MCP Server, one of Jama Connect’s AI-powered engineering capabilities, exposes the TIM to AI agents without routing around the permissions, reviews, and audit logging the project already runs on.
Anything performed with AI inside Jama Connect is versioned and documented as AI-generated, which is an audit trail external AI tools can’t produce and a certification review or a submission will ask for. Live Traceability™ keeps the TIM current by marking downstream artifacts as suspect the moment an upstream item changes, so an agent reading an approved requirement is reading the current one. Jama Connect Advisor™ flags vague requirement language at authoring time, the same ambiguity that leaves an agent guessing at a threshold, and it creates nothing until an engineer accepts the suggestion. An engineer can then walk into the next design review with a versioned record of what the agent read and what it produced.
Getting Started With Context Engineering
An almost-right artifact only becomes defensible when the agent read an approved, versioned requirement and the trace link survives review, so the first move is finding where we still make an agent guess. If your team is already pointing agents at engineering work and can’t say which version they read, you can see a governed context layer in a Jama Connect demo.
Frequently Asked Questions About Context Engineering
How is context engineering different from prompt engineering?
Prompt engineering is about the wording of the instruction. Context engineering is about everything else in the window when the model reads that instruction, including which requirement version and which prior turns survive. The two are complementary, and on a regulated program the second one is where the compliance exposure sits.
Is retrieval-augmented generation enough on its own?
Not on its own. RAG finds documents that match a query, which is not the same as finding the document a team has approved. It has no concept of baseline, review state, or supersession, so it will return a draft revision alongside the released one and rank them by textual similarity. Teams that stop at RAG usually discover this the first time an agent cites a requirement that was withdrawn two revisions ago.
Does a bigger context window solve context rot?
No. Degradation tracks how much of the window is filled and where the relevant material sits. A larger window mostly buys more room to bury the important record in the middle, so the practical response is to send less and send the right thing, which is a selection problem.
What should go into an AI agent’s context first?
The approved requirement, its parent, and the verification evidence already linked to it. That set is small and it carries version authority, so the agent reads a decision the team has already made. Everything else, including design notes and ticket history, is optional context that should earn its place in the window.
