Last weekend, something popped up on one of my radars — I have more than one — an article by Anatoli Kopadze about Graph Engineering. It actually came from a post on X, and it caught my attention.
We had been talking about loops, agents working for longer periods of time, and how to close those loops with tests. Well, «we had been talking» is probably a generous way of putting it. It is almost a conversation with myself. But over the last few weeks, there has been a lot of discussion in different places about moving from prompting to context, and from context to loops. Then, of course, we add the word engineering in front of everything — or say it in English, which apparently makes everything sound better.
In the end, what we are really talking about is how we interact with agents, and also how agents interact with each other. In this case, the article proposed widening the focus: when work is distributed across several units, it makes sense to think about the relationships connecting them as well.
The term itself is relatively new in the current discussion around agents. Its foundations are not. Graphs have been part of software engineering long before a model could write code or use a tool. What is interesting now is that the nature of some nodes has changed. An operation can interpret context, choose an action, and return a result with a certain degree of uncertainty.
That uncertainty makes workflow design much more important. The sequence needs to reflect real dependencies, and each step must leave behind something we can inspect. When we bring this idea into software development, the relationship with ALDC appears almost immediately.
A useful definition for the agentic context
Graph Engineering still lacks a clear definition that can be directly applied to agents. In this article, I will use the term to describe the explicit design of a system as a graph of work, state, and dependencies, where nodes can be agents or humans.
A node represents a bounded unit of work. It can be executed by a specialized agent, a deterministic tool, a model, or a person. What matters is knowing:
- what input it receives,
- what artifact it produces,
- and what criterion allows us to consider the work complete.
An edge represents a dependency. To be useful, it should carry something concrete: an approved document, code, a decision, or a test result. Simple chronological order tells us very little. If the second step can start without using the output of the first one, there is probably room to reorganize the workflow.
Some processes fit naturally into a DAG — a directed graph that moves forward without cycles. Software development usually needs paths back as well: a test fails, the code is corrected, and the system runs the validation again. These cycles need a budget and an exit condition. Otherwise, execution can continue indefinitely without any real progress.
A story that started long before LLMs
From a historical perspective, what we are talking about today — at least at the theoretical level — is hardly new. No, I do not have the mathematical background to explain graph theory properly, nor do I intend to pretend that I do. That is why I have included some references at the end. Use AI to help you with them, of course.
Sorry if this offends the «purists», but guys, it is what it is. We used Google for everything. We abused Stack Overflow for years. So perhaps we should not be so sensitive now. And anyway, who even pays with cash anymore? So many «pure» things…
Oops. I am wandering off again. Back in 3, 2, 1…
As I was saying, Graph Engineering brings together ideas coming from dependency graphs, concurrent systems, and process orchestration. So what is different now? Our AI agents are not deterministic. They make mistakes. They get things right. And we cannot always anticipate where the mistake will happen — or at least it is extremely difficult to do so. That is the problem.
Why it is appearing now in the agent discussion
Anthropic published Building effective agents in December 2024. The article distinguished between workflows, where predefined execution paths exist, and agents that dynamically direct their own processes.
I want to stop here for a moment because this distinction matters. The article is talking about agents directing their own process. Not a human directing it. It described patterns such as prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. Each one structures the relationships between tasks differently, and defines how agents deal with them. And this was almost two years ago already.
Current frameworks make these relationships even more visible. LangGraph works with state, nodes, and fixed or conditional edges. GraphFlow, within Microsoft AutoGen, uses a directed graph to control sequences, parallel branches, and loops. Its documentation still marks the feature as experimental, which is an important detail if we are thinking about real adoption. But, dear audience, who has not been continuously experimenting over the last two years? If you are not experimenting, you are probably not really in this game. And that is exactly the point.
There are more sources of uncertainty as well — yes, more. The execution environment also matters. An instruction that activates a workflow in Claude Code may behave differently in GitHub Copilot or Codex. The available model, its tools, and the policies of the execution environment all influence orchestration.
One thing must be clear: the graph does not replace the harness. The graph describes or controls the flow. The harness is responsible for executing it, preserving state, and enforcing operational boundaries. It should also isolate workspaces when several agents are writing at the same time.
Do you realize how many new terms we are introducing? Doesn’t it feel as if everything is moving at an overwhelming speed? Understanding all this is difficult enough. Applying it inside a framework such as ALDC is another level entirely.
Real dependencies and parallelism
Kopadze proposes a simple question for reviewing every transition: does the next step actually need the result of the previous one? He calls this the false edge test, and it is worth applying to almost any inherited workflow.
Imagine a code review divided by files. Two analyses can start at the same time when each one reads a different file and works independently. The situation changes when they share write access, a rate-limited API, or depend on a previous decision. In those cases, a real dependency exists, even if it was not visible in the original diagram.
Isolation through worktrees can help with concurrent writes. Each agent gets its own workspace, and the changes are integrated afterwards. Even so, a worktree solves only the mechanical part of the problem. The decomposition still needs to define clear ownership of files and establish how overlapping changes will be handled.
A common topology opens several branches and later brings them back together:
┌─ Specialist A ─┐
Input ───────┼─ Specialist B ─┼─ Reduction ─ Verification ─ Synthesis
└─ Specialist C ─┘This is usually described as a fan-out / fan-in pattern. It works well when branches contain independent work and the join point knows how many responses it should receive. If one branch silently fails, the synthesis step must declare the result as partial.
Kopadze: «The graph buys breadth. It does not buy judgment.»
Verification needs hooks
Adding a second agent to review the work can help, especially if it starts with a clean context. That way, we reduce the risk of the reviewer being conditioned by what the first agent did. But both agents can still make the same mistake.
This is why we cannot leave all verification in the hands of models. The environment has to speak as well. A successful compilation, a test with a concrete result, a validation executed by code, or a reference supporting a finding provide much more objective signals.
And some rules should simply not be under the control of the agent we are evaluating. If an agent is trying to improve a metric, it cannot also have the ability to relax that same metric. Safety boundaries, gates, and certain validations must remain outside its control.
In software development, we have an important advantage: compilers, analyzers, and tests provide ground truth — a foundation of trust. We can actually verify whether something works. Human review remains necessary when we are dealing with requirements, architecture, or decisions where there is no purely technical answer.
Then there is cost. Adding more branches and more agents does not automatically produce a better result. It also means more calls, more time, and more information to consolidate. In the end, the question is quite simple: does the result improve? If it does not, running more agents only makes the graph more expensive and more complex.
When the graph is unnecessary
Kopadze dedicates part of his article to situations where this approach adds little value, and I think it is important to keep that more cautious perspective. A localized bug, a new field, or a small function is usually better handled by one agent, good tools, and a short loop. Coordination would add cost without bringing much in return. It is the old idea that a problem is not necessarily solved faster or better simply because we add more people to it.
Something similar happens with exploratory work. When we are still deciding what we are actually looking for, one agent that we can actively direct may be more useful than a group — or swarm — of agents blindly following our plan. And if the steps are genuinely dependent on each other, the graph may simply reproduce the same sequence using more pieces. It adds nothing.
Anthropic recommends starting with the simplest possible solution and increasing complexity only when there is a demonstrated improvement. That recommendation becomes even more relevant now that it is so easy to confuse orchestration capability with engineering quality.
ALDC from this perspective
ALDC structures AL extension development through requirements, contextual documents, and specialized agents. The conductor normally coordinates the evolution from architecture to implementation and review. Before preparing the pull request, there are tests and a human approval step for every phase. Or at least there should be.
When we represent the process as a graph, several relationships become clear. Architecture decisions feed the specification, and the implementation is prepared from there. Once the code reaches a reviewable state, several verification layers come into play: Dredd, BCQuality, compilation, and tests. Each one contributes a different signal, and all of them converge before the final human gate. Along the way, many HITL situations may also be raised by agents and subagents whenever a human decision is required.
Drawing this flow is easy. The difficult part is defining what happens between each step. A skill may provide knowledge to an agent, but to become a real part of the process it needs something more: a clear input and an output that the next node can understand and use.
The same applies to agents. The name tells us their responsibility, but it does not define their operational contract. al-architect, for example, receives context and returns decisions that constrain the design. Dredd receives a reviewable state and returns findings. And the conductor must know when those outputs are complete, when the process can move forward, and what to do when something is missing.
This is another area where Graph Engineering helps us organize verification more clearly. BCQuality provides specialized and citable knowledge about AL code quality. Dredd checks whether the implementation fits the ALDC process and its rules. Compilation and tests tell us whether it actually works. The key is not having many reviews. The key is making sure that each one verifies something different, and that when the results are consolidated we can always trace where each finding came from.
What could change in ALDC
Many framework dependencies are currently described inside Markdown instructions, and the conductor interprets them during execution. A more explicit contract would make it possible to know which artifact enables each phase and where the gates are located.
Handoffs are another obvious area for improvement. Instead of carrying a long conversation into the next phase, the next specialist could receive the approved decision and only the minimum context it actually needs. This improves traceability and reduces the propagation of assumptions made in previous stages.
Parallelism should also be treated as an architectural decision. Read-only reviews are a reasonable place to start. Concurrent implementations require isolation, file ownership, and controlled integration. Each case will have a different graph because the dependencies come from the requirement and the architecture chosen to satisfy it.
ALDC already has many of the necessary pieces: the conductor, specialists, persistent artifacts, validation tools, and human approval. Graph Engineering gives us a more precise way to describe how those pieces relate to each other and how to audit the path followed by each delivery.
The real test will be the results. A broader workflow will make sense when it reduces waiting time or increases coverage without degrading reproducibility. It must also preserve the boundaries that prevent ERP decisions from being delegated blindly or changes from being published without approval. That is the point where Graph Engineering stops being an interesting label and starts becoming actual engineering.
For now, we will see how this new architectural direction evolves and progressively apply it to ALDC. And considering how quickly everything is moving, it is entirely possible that ALDC itself will eventually need some kind of refoundation.
References
Some interesting reading here. Maybe slightly heavy for August. But use AI to help you summarize them. Nothing terrible is going to happen.
- Anatoli Kopadze, Graph Engineering explained: what it is, when to use it and when not to, 2026.
- Leonhard Euler, Solutio problematis ad geometriam situs pertinentis.
- Wolfgang Reisig, Essentials of Petri Nets, historical context around Carl Adam Petri’s 1962 thesis.
- Stuart I. Feldman, Make, a program for maintaining computer programs, 1979.
- W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski and A. P. Barros, Workflow Patterns, 2003.
- Jeffrey Dean and Sanjay Ghemawat, MapReduce: Simplified Data Processing on Large Clusters, 2004.
- Anthropic, Building effective agents, 2024.
- LangChain, LangGraph: Graph API overview.
- Microsoft AutoGen, GraphFlow (Workflows).