An agent that can write code still needs a way to know what it owns, which work it depends on, and what happened before a process stopped. Those questions become harder when several agents share a project. I use graph engineering as a way to inspect those relationships and the rules around them.
This case study connects the research to a read-only audit of my engineering tools. The strongest evidence is in ownership checks, revision-bound review evidence, dependency-aware planning, and knowledge discovery. The audit also found gaps in dependency semantics and source freshness. My next step is to test a few specific guarantees before considering broader architectural changes.
What graph engineering means
A graph describes things and their relationships. In a software workflow, a thing might be a task, agent, code revision, or test result. A relationship might say that one task depends on another, an agent owns a file, or a test result was produced from a particular revision.
The engineering starts when those relationships affect behavior. If two agents claim the same file, what rejects the conflict? If a predecessor disappears from a plan, does its dependent task wait? If a worker stops after making a change, what evidence tells the next worker where to continue?
Feng and colleagues organize agent-system graph engineering into task organization, agent coordination, and runtime state management. I use those three views as an audit framework. Their August 2026 paper is a survey and proposed organizing framework, rather than a benchmark result or an established standard. [1]
Conceptual map. Task, team, and runtime views follow the survey framework; the knowledge view is adjacent. Arrows connect a view to its question, not to a deployed component.
Open diagram at full size
Read the workflow as text
- Task view addresses prerequisites and readiness.
- Team view addresses ownership and review.
- Runtime view addresses state and recovery.
- Knowledge view addresses context and citations, separately from execution authority.
A knowledge graph sits beside these operational views. It can help an agent find related code or documents. That does not give its edges scheduling authority. A connection discovered between two files and a declared prerequisite between two tasks have different meanings, so I keep them separate.
None of this requires a graph database. A dependency list, a relational join, or a validated JSON record can express the relationships a workflow needs. The useful questions are whether their meaning is explicit, invalid combinations are rejected, and the evidence remains traceable as the work changes.
Why this is getting more attention
Graphs and workflow dependencies have a long engineering history. W3C PROV-O, published in 2013, describes relationships among entities, activities, and responsible agents. Bazel's dependency documentation distinguishes what a build actually depends on from what it declares. These are useful precedents for agent workflows: a relationship has to describe a real dependency or a traceable event to be useful. [2, 3]
The recent agent literature brings those concerns into systems whose workers can choose tools, exchange intermediate results, and take different paths through a task. AutoGen's 2023 paper describes configurable multi-agent conversations combining models, tools, and people. The 2026 graph-engineering survey groups the coordination problems into a wider system-level framework. These sources describe an active direction in research and tooling; they do not establish that every workload benefits from multiple agents. [1, 4]
In my own harness, the runtime part of this appears as a recovery question. When a worker stops partway through a task, saved state can tell the next worker where to resume, but not which steps already took effect. Anything after the last recorded completion may run again, including model calls and external requests. Saving state is the easier half; deciding what can safely repeat is the design work.
Graph-based retrieval is developing alongside this work. The original GraphRAG paper builds an entity graph and community summaries to answer questions over a text corpus. That is a retrieval design with its own evaluation task. I would evaluate a local discovery graph on the questions it is meant to answer, rather than borrow results from that paper. [5]
Questions and evidence
I wanted to answer three questions. Which important relationships already control our engineering workflow? Where does the recorded state leave room for a wrong interpretation? And what is the smallest experiment that could show whether a proposed change is worthwhile?
The working hypothesis is that explicit identity, dependency states, and evidence links will make some coordination failures easier to detect and recover from. The audit identifies places to test that hypothesis.
The evidence comes from a targeted local audit in early October 2026. It sampled executable source, configuration, tests, planning records, and generated graph artifacts. Small tests used synthetic data and temporary directories. The audit did not change application code or configuration, trigger CI, call paid models, or inspect production traffic.
I separate four kinds of evidence throughout: examined implementation, behavior reproduced in the audit, an inference that still needs a test, and a proposed experiment. Existing test files count as examined evidence unless the audit explicitly ran them. The examples below use generic names and omit application-specific architecture and data.
What we already do
Ownership and review are explicit relationships
The engineering workflow connects a run to its role, allowed files, review evidence, and code revision. Examined checks reject overlapping file ownership, duplicate writer identities, and changed files without an owner. Review evidence is tied to the exact code revision it describes.
That is a practical team graph, even though its representation is ordinary code and records. The important behavior is that the workflow can reject an invalid relationship. A diagram alone could show two owners on one file without preventing it.
The Harness page describes that workflow and its review steps in more detail.
The merge workflow also serializes work and records waiting state. Those controls give specific operations an order and a recovery path. Their scope is the merge workflow. The audit examined the implementation and related tests; it did not run the remote workflow end to end.
Planning models dependencies with a narrower scope
A dated planning prototype represents work items with predecessor lists, duration assumptions, priorities, and capacity limits. It uses predecessor-completion checks to decide eligibility and models a join where both component changes must land. This is a dependency-aware simulation used to reason about completion.
The packaged forecast examined alongside it is different. It uses completion-state and duration models without predecessor traversal. Keeping those paths separate matters: a feature found in an experimental scheduler cannot be attributed to the packaged command without checking which code it invokes.
The Monty page describes the forecasting work and how it was evaluated.
A related controller models handoff and recovery as explicit states. Those states come from upstream-derived code. The audit examined its state model, not autonomous operation.
Knowledge discovery has construction controls
The local discovery tool combines graph search with literal document search. Its source mirror has an allowlist, a writer lock, staged scanning, deletion propagation, and per-file atomic replacement. The graph artifact distinguishes extracted and inferred relationships. Aggregate checks found no duplicate node identities or dangling endpoints in the examined artifact.
These checks establish useful structural properties. They leave answer quality and source freshness as separate questions. The configured wiki layer was still a stub, so this snapshot supports a graph-search capability rather than a maintained, reconciled entity wiki.
What the audit made more precise
An absent predecessor can look complete
In the dated planning engine, the audit isolated and executed the actual dependency-completion function. A known predecessor absent from the active plan returned true; the same predecessor present and open returned false. The plan builder excludes several non-active states, so absence can stand in for more than completion.
This reproduced behavior gives the next test a clear target. If task A depends on B, parking B should keep A blocked. Completing B should release A. Omitting B should produce an explicit missing-input result. Figure 2 shows the proposed interpretation, not a fix already made.
Proposed test oracle for a single prerequisite. Release depends on explicit completion; parked and missing inputs remain distinguishable. The current engine has not been changed.
Open diagram at full size
Read the workflow as text
- Read the predecessor state and check whether it is explicitly complete.
- If yes, release the dependent task.
- If no, keep the task blocked or report missing input.
| Predecessor state | What it means | What the scheduler must do |
|---|---|---|
| Done | Recorded as complete | Release the dependent task. |
| Parked | Paused on purpose, and possibly left out of the active plan | Keep the dependent task blocked. |
| Missing | Named as a prerequisite but found in no plan or record | Stop and report a missing input. |
| Unknown | Present, but its state cannot be read or is not recognized | Treat it as not complete, keep the task blocked, and flag the record. |
Only an explicit completion releases work. This table is the proposed oracle for the dependency-state tests below, not a description of the current engine.
Synthetic illustration: each task is a prerequisite for dependent work. predecessor | state | absence-as-done | explicit state review-guide | done | release | release write-guide | parked | release | blocked index-guide | missing | release | stop: missing input translate-guide | unknown | blocked | blocked: flag record
I would resolve the current entrypoint first, then decide whether to change the dated engine, retire it, or keep it clearly isolated as historical work. I would also test a two-node cycle and an ordinary diamond-shaped dependency before simulation.
A current graph can describe an older mirror
The discovery graph's recorded build revision matched its local checkout. A separate byte comparison found differences between some indexed mirrored documents and their current source.
That snapshot establishes that graph-to-checkout freshness and mirror-to-source freshness are separate checks. Answer quality needs a separate evaluation on a representative question set.
The proposed change is to carry both identities into a query receipt: the graph generation and the source snapshot it describes. A source edit without a mirror refresh should be visible to the reader.
A failed refresh needs a publication guarantee
The refresh wrapper creates a backup, runs extraction and labeling against live output, and reports failure when a stage fails.
Whole-generation preservation needs a direct test. Upstream atomic behavior may already protect the files. The next step is to inspect that behavior and inject a synthetic failure, then compare the bytes that a reader receives with the previous validated artifact.
If that test fails, the candidate design is to build a separate generation, validate it, and switch the active pointer only on success. Per-file atomic replacement and a whole-generation switch solve different consistency problems. Figure 4 describes the candidate, not the current implementation.
Proposed only if fault testing shows a gap. Validation must succeed before the active generation changes.
Open diagram at full size
Read the workflow as text
- Build a candidate generation and validate it.
- If valid, switch the active generation.
- If invalid, keep the previous validated generation.
Security boundaries
Several relationships in this case study are also security boundaries. Treating them only as coordination data would understate what a wrong edge can do.
Discovery results are untrusted input
A discovery edge points an agent toward a document, and retrieval places that document's text in the agent's context. Either can carry text written by someone else, including instructions meant to redirect the agent. This is prompt injection in graph form. Retrieved text should be handled as data to cite, never as instructions to follow, and a discovered relationship should never grant permission to act. The Zeki page describes the same rule for its retrieval path.
The mirror allowlist is a data boundary
The discovery tool's source mirror copies only allowlisted sources. That list decides which material can reach an agent through search, so changing it is a decision about data exposure, not only about coverage.
Ownership is authorization
An ownership edge says which agent may change a file. That makes it an authorization record as well as a coordination record. The examined checks that reject overlapping or missing owners act as access control; a conflict should stop the change rather than produce a warning.
The published graph needs integrity
Readers and agents act on the graph generation that is currently published. If a refresh fails partway, the safe outcome is to keep the previous validated generation rather than serve a mixture of old and new relationships. A partial graph can silently drop an edge that a reviewer or an agent relies on.
The audit examined the ownership checks and the mirror's allowlist. It did not test prompt injection or a failed publication, so those two boundaries are stated here as requirements rather than findings.
Tests I would run next
These experiments are proposed.
- Resolve the invoked paths. Record the command, configuration, and source revision for the planner, discovery tool, and controller. A finding becomes an implementation candidate only after its active or supported path is known.
- Test dependency states. Use parked, completed, missing, and cyclic predecessors. The oracle is explicit: blocked work remains blocked, completed prerequisites release work, and malformed plans fail before simulation.
- Test failed publication. Inject extraction and labeling failures separately, including an error reported with a successful process exit. Verify that readers receive the previous validated generation and never a mixture of generations.
- Compare retrieval methods. Freeze the corpus and choose 15 to 20 representative questions with source-backed answers. Compare direct search and graph-assisted discovery using the same model and budget. Record correctness, valid citations, elapsed time, and total tokens. Add wiki-assisted discovery only after a populated wiki exists. Keep raw answers and score them without revealing the method when practical.
- Test acceptance and recovery boundaries. A merged change that has not been installed should remain distinct from an operationally accepted change. Following the recovery question above, use a synthetic side effect to test a restart between the effect and its recorded completion, with a defined duplicate-prevention rule.
The retrieval study is a small exploratory comparison. It can expose failures and suggest a larger evaluation; its results would not support broad performance claims on their own. Cost and retry counts belong in the record so extra computation cannot quietly explain an apparent architectural gain.
Lessons and current decisions
What I learned is that useful graph engineering already exists in ownership checks, dependency records, and state transitions. The places that deserve attention are often a specific edge meaning or an evidence boundary. W3C SHACL offers an established example of validating a graph against explicit constraints; the same discipline can guide small validators without adopting its RDF representation. [6]
What changed in this case study is the description of the system and the proposed test plan. I now separate planning experiments from invoked tools, discovery relations from execution dependencies, and structural checks from operational outcomes. The audit has not yet led to implementation changes.
My recommendation is to preserve the existing ownership and review controls, verify the current paths, and test the narrow failure cases first. A new graph platform, dynamic team reorganization, or broader wiki should follow a demonstrated need. The next decision is which findings still apply to the current tools and which small tests would change what we build.
Evidence limits
This is an implementation case study based on a targeted audit, not a peer-reviewed evaluation. Private source revisions and test receipts support the local findings but are not published here. The audit reproduced the dependency-function behavior and ran selected synthetic suites; other tests were examined only. The audit did not verify a unified deployed coordination system. It did not verify the planner's current invocation or measure effects on published forecasts, retrieval gains, or broad productivity improvements. The mirror comparison did not evaluate answer correctness. No served-graph corruption was demonstrated. The audit has not yet been independently reviewed.
Figure 3 is a synthetic illustration of the dependency case, built from made-up tasks rather than the audited code. A similar public reproduction of the publication case would be a useful next artifact; the implementation details here remain generalized.
Sources and further reading
The public sources explain the concepts and comparison points. They do not independently verify the implementation findings. Accessed 4 October 2026.
[3] Bazel. Dependencies. Official documentation on actual and declared dependencies.