Agentic engineering
Why agents need structural context
Relevant code includes the relationships that constrain a change, not only the file an agent is editing.
The edited file rarely contains the whole contract
An AI coding agent can find a relevant implementation and still miss a constraint elsewhere. A caller may depend on the shape of a return value. A shared interface may promise a particular error. A test may describe behavior that the local function does not explain.
A task is paired with relevant source, explicit constraints and tests into a reviewable context package before a person or agent reasons about a change. This is a conceptual example of useful context.
Adding more files to a prompt is one response, but volume alone does not establish relevance. Useful context explains which source matters, how the pieces connect and what the agent should verify before changing them. The engineering task provides the boundary for that context.
Build a context around the decision
Imagine changing a checkout operation from a single item to multiple items. The local implementation is only one part of the work. Its input contract, the callers that construct it, the calculation it invokes and the tests around totals all constrain the change.
A useful context includes those pieces with a short explanation of their role. The input type defines the new shape. A caller shows how data is assembled. A calculation exposes rounding assumptions. A test demonstrates a behavior to preserve. These explanations help distinguish necessary context from nearby but unrelated code.
State the intended behavior and the behavior that must stay unchanged.
Identify the interfaces and direct relationships involved.
Include relevant source and the reason for selecting it.
Name the checks and unresolved questions before editing.
Preserve the source of the observation
Context becomes less reliable when it loses its connection to a particular code state. A relationship observed before a refactor may no longer describe the current implementation. A truncated result may omit a relevant caller. An agent should be able to recognize both limits.
Attach the revision and source locations to the investigation. Explain whether a connection was directly observed or inferred. When the agent discovers conflicting evidence, update the context instead of forcing the new information into the original plan. A context package is a working explanation, not a permanent truth about the system.
Keep verification separate from confidence
A convincing explanation is useful, but it is not a test result. Ask the agent to show how the proposed diff addresses the task, which relevant checks ran and what those checks establish. Review changed interfaces and call sites together so that a locally correct edit does not hide an incompatible assumption.
Structural context does not remove the need to understand tool permissions, review source changes or validate behavior. It supports those activities by making the relationships involved easier to inspect. Missing evidence should remain visible even when the proposed change looks plausible.
A direction for better engineering context
Graphtia Explorer focuses on the code-understanding layer: files, symbols, relationships and source context. Graphtia Governance explores a future direction for keeping longer tasks, plans and evidence reviewable. These are related problems, with different responsibilities.
Product access and supported agent integrations are still in preparation. The useful habit today is straightforward: give an agent a bounded engineering question, connect the relevant code and require an explanation that can be checked against source and results. Better context makes that review more focused.