Ai AppliedLong-horizon coding agents are changing the unit of software work. Instead of completing a narrow function or fixing a single bug, an agent can now spend hours navigating a repository, tracing dependencies, modifying schemas, coordinating migrations, and validating a change across multiple boundaries.
That expanded autonomy is impressive. But it also exposes a problem that longer execution alone cannot solve: an agent can make a series of locally reasonable decisions that produce a globally incoherent system.
The next step in agentic software development is not merely longer execution. It is accountable execution.
Local correctness is not enough
Most coding workflows are good at checking two layers of correctness. Syntactic correctness asks whether the code compiles, parses, or executes. Behavioral correctness asks whether it satisfies the stated requirement and passes its tests.
Long-horizon engineering adds two more layers. Systemic correctness asks whether the change preserves wider architectural, security, data, integration, and operational invariants. Temporal correctness asks whether the decisions embedded in the change will remain suitable as scale, topology, dependencies, policies, and operating conditions evolve.
A patch can pass every available test and still fail at those wider layers. A retry policy may work in one process but duplicate an irreversible side effect after failover. A cache may improve local latency while violating a distant consistency expectation. A schema migration may look safe inside one service but break an asynchronous consumer that was never named in the task.
The context completeness fallacy
The usual answer is to give the agent more context: larger context windows, repository maps, retrieval, and persistent memory. These capabilities are valuable, but they do not create complete engineering context.
Important facts may live in source code, infrastructure, production data, incident history, customer contracts, security policy, road maps, or the expectations of people who were never part of the task. Some facts are unavailable. Others are stale, contradictory, or undocumented.
Even when a critical fact is present, the agent may not give it the appropriate weight. Context availability and decision alignment are different problems. The goal should not be perfect context. It should be disciplined decision-making under unavoidable contextual incompleteness.
Hidden decisions compound over long trajectories
A broad request such as “make this workflow reliable” contains a large hidden decision surface. The agent must decide what counts as failure, which errors are retriable, how often to retry, where state is persisted, how concurrency is controlled, whether side effects require idempotency, and what evidence is sufficient to declare success.
Those choices affect reliability, cost, latency, compliance, consistency, and future extensibility. Yet they often appear in a review as small constants or ordinary control flow. Code review exposes the implementation; it does not necessarily expose the interpretation, assumptions, alternatives, optimization criteria, or conditions under which the design should expire.
Introducing the Engineering Decision Graph
In my paper, From Local Correctness to Global Engineering Coherence, I propose the Engineering Decision Graph (EDG): a governance framework that makes material engineering decisions durable, inspectable, connected, and revisable.
The framework has three levels:
- Agentic Engineering Decision Record (AEDR): the atomic record of one material decision.
- Engineering Decision Graph (EDG): the dependency and evidence model connecting decisions to assumptions, requirements, code, tests, owners, observations, and validity conditions.
- Engineering Decision Engine (EDE): the active control layer that compiles decision-aware context, estimates blast radius, detects contradictions, and applies policy gates.
An AEDR does not store private chain-of-thought. It records the engineering-facing object required for review and control: the intended outcome, objective interpretation, system boundary, evidence, assumptions, selected parameters, alternatives, trade-offs, invariants, validation plan, and temporal validity conditions.
Govern the decisions that matter
Not every code edit deserves a full decision record. Formatting changes, generated files, and mechanical refactors should inherit existing decisions. Governance needs to be proportional or it becomes ceremony.
The EDG framework therefore uses hard gates for changes involving external contracts, security or privacy boundaries, irreversible data mutations, destructive migrations, external side effects, and shared architectural constraints. Other decisions can be classified using five factors: blast radius, reversibility, uncertainty, longevity, and operational impact.
The point is not to maximize documentation. It is to expose consequential choices before they harden into code and to match review effort to engineering risk.
A retrospective loop, not a static archive
Decision records become much more valuable when they participate in an active control loop:
- Frame: compile the objective, relevant system slice, prior decisions, constraints, and unknowns.
- Decide: create a provisional AEDR with alternatives, parameters, trade-offs, and expected outcomes.
- Challenge: assume the decision is wrong and search indirect callers, background work, permissions, lifecycle paths, rollback behavior, and future-scale contradictions.
- Execute: implement only after contradictions are resolved or explicitly accepted, then bind the code and validation evidence to the decision.
- Observe: compare runtime behavior with the recorded expectations and reopen the decision when its conditions no longer hold.
This separation matters. The same reasoning path should not silently create and approve its own assumptions. A context-independent challenge pass can search for evidence the implementation trajectory failed to consider.
A practical example: “add retries”
Consider an agent asked to add retries around an external tool call. A local solution might use three attempts with exponential backoff. An EDG-guided process widens the boundary before changing code.
It asks whether the external operation is idempotent, where attempt state is persisted, how cancellation interacts with delayed retries, what happens after a worker crash, which connectors ignore idempotency keys, and whether the added delay violates the user-visible service objective.
The value of the EDG is not that it chooses “three retries.” It makes the conditions, dependencies, and consequences of that choice visible before implementation—and revisitable after deployment. If the system later moves from one region to active-active operation, the topology change can reopen the decision rather than assuming that yesterday’s passing tests prove today’s fitness.
What changes for engineering teams
The artifact of autonomous coding becomes more than a patch and a test report. It becomes a traceable chain of intent, evidence, assumptions, authorization, implementation, and observation.
Teams do not need to begin with a graph database or a large governance program. A practical adoption path starts with one consequential decision class—retries, caching, public APIs, or database migrations. Store lightweight AEDRs in version control, link them to pull requests and tests, introduce an independent challenge pass, and add retrospective triggers where operating evidence can invalidate a decision.
The framework is a reference specification and research agenda, not a claim of universally validated performance. Materiality thresholds, invalidation rules, agent quality gates, and governance burden must be calibrated against real repositories, teams, incidents, and review outcomes.
From capable agents to accountable engineering
Long-horizon agents will inevitably work with incomplete context. They will infer objectives, select parameters, and make trade-offs. The goal is not certainty. It is a system that knows what it decided, why it decided it, what the decision depends on, and when that decision should no longer be trusted.
Read the full pre-print: From Local Correctness to Global Engineering Coherence →