12 min read
This morning I came across two different discussions about “graph engineering,” a term that seems to have become the latest AI buzzword. One was a podcast. The other was a YouTube video.
For readers who have not come across the term, graph engineering organizes work into jobs connected by dependencies, decisions, and shared state. The work may happen in sequence or at the same time and may be performed by AI agents, people, tools, or traditional software.
That sounded familiar.
A cross-functional software team already operates as a connected system of responsibilities, decisions, knowledge, and work. A value stream and an AI graph share much of the same basic structure.
Value stream mapping makes that system visible so people can understand and improve it. Graph engineering can make parts of the same system executable. AI adds new participants and new ways to preserve context. The team and its leaders still own how the system is designed and whether the outcome matters.
The more I listened, the more familiar the underlying system sounded. I kept returning to a simple thought.
We have been designing graphs of work for decades. AI added a new kind of participant.
I have spent much of my career helping organizations understand how work moves through software delivery. I have stood with teams around whiteboards mapping value streams, looking for the places where work waited, decisions slowed down, handoffs created confusion, or teams stayed busy without improving the outcome.
There are new technical challenges. AI agents need context. They need to know when to call another tool, ask another agent for help, pause for human approval, or recover when the work moves in the wrong direction. Their output is less predictable than traditional software, which creates new questions around testing, controls, cost, and trust.
Those challenges are real. The questions about the work itself are much older.
We still need to understand how work flows through the system, where it begins, who or what performs it, which activities depend on something else, what can happen at the same time, and where human judgment belongs. We still need feedback, clear ownership, and a way to know whether the work produced something useful.
These are the same questions we have asked while designing software delivery systems, operating models, and value streams.
AI is changing who can perform some of the work.
Software Delivery Was Already a Graph
A software delivery team is a collection of capabilities connected by work.
Traditionally, product brings an understanding of the customer and the business problem. Software developers design and build the product. Quality brings testing and risk thinking. Data specialists help the team understand information and make better decisions. Security protects the customer and the organization. Platform and operations capabilities help teams deliver and run software safely. Agile and delivery leadership help work move through the system.
Some of that work happens in sequence. Much of it can happen at the same time. Decisions can change the path, feedback can send work back to an earlier step, and people may need to become involved when risk or uncertainty requires judgment.
That connected system already contains the basic elements of a graph.
The jobs are the responsibilities and activities required to deliver. The arrows represent dependencies, handoffs, decision paths, and feedback. The state is the shared record carried with the work, including the customer need, product decisions, technical context, quality findings, risks, and what has already happened.
Value stream mapping helps teams see and improve that system. It reveals where work waits, where dependencies restrict Flow, where context is lost, and where decisions happen too far away from the work.
An AI graph uses the same basic structure. It connects jobs through dependencies, carries shared state between them, and allows work to happen sequentially, in parallel, or along different paths.
One important distinction is that a node in the graph should not always be viewed as a job title or a person. It can represent a responsibility or capability.
Testing, customer discovery, architecture, security, data quality, production readiness, and product decisions all represent responsibilities that need a home in the system.
The work within each responsibility may be performed by a person, an AI agent, traditional software, or some combination of all three.
That is a more useful way to think about the graph.
A product manager does not simply become a product agent. Product management includes understanding the customer, defining the problem, weighing trade-offs, setting direction, and evaluating the result. AI may help perform parts of that work. The responsibility still needs a home within the team.
The same applies to quality, architecture, data, security, and delivery. The terms may be different. The work still has to move through a system.
Responsibilities Belong to the Team
This connects directly to why I have supported small, self-managed, cross-functional teams for much of my career.
With the right architecture, a team should have enough capability and authority to take work from a customer or business need through delivery, production, and learning from the result.
That requires more than software development.
The team needs product understanding, technical capability, quality, data, security, delivery, and operational thinking. The mix will vary by product and domain, but the responsibilities still need a home.
Those responsibilities belong to the team.
Specialized skills determine how the work is distributed across its members. One person may bring deeper product knowledge. Another may provide technical direction. Someone else may contribute quality, data, security, or delivery experience.
The strength of the team comes from how those capabilities work together.
At Parchment, we spent years building an operating model where responsibility did not simply follow the management hierarchy. Engineering Managers focused on people, coaching, professional development, organizational health, and their own technical contributions. They did not manage the day-to-day delivery of their direct reports’ teams.
Each cross-functional team brought together the product, software development, architecture, quality, data, delivery, and technical leadership capabilities needed to deliver within its domain. Responsibilities were distributed across the team based on the work and the specialized skills of its members.
Authority moved closer to the work.
People understood which decisions they owned, where they needed another perspective, and when a broader organizational concern required escalation.
That model helped support more than 3,000 production changes a year while reducing lead time by roughly 80 percent and maintaining average change quality of 95 percent.
The numbers mattered, but the operating model behind them mattered more.
The teams were able to move because they had the capabilities, architectural independence, and decision authority needed to deliver within their domain. They did not need to send every question through the management structure. They could bring the right people together around the work and make decisions closer to where the context lived.
That experience shapes how I think about AI-enabled teams.
An AI agent can become another participant in that same delivery system.
It may help with research, analysis, implementation, testing, documentation, review, or coordination. It may provide a specialized capability that previously required more human effort. It may help a smaller team operate with greater independence.
The team still needs the full set of responsibilities required to deliver responsibly.
A coding agent can produce implementation without owning the product decision. A testing agent can generate test cases without carrying the full responsibility for quality. An AI assistant can summarize customer interviews without understanding every business trade-off behind the roadmap.
Humans, traditional software, and AI agents may each perform part of the work. The team remains responsible for how those capabilities come together and for the outcome they produce.
Shared Context Can Become Shared Team Memory
In graph engineering, state is the shared record of what the system knows so far. In a software delivery system, that state can include the customer problem, product decisions, business constraints, technical choices, risks, and what the team has learned.
Imagine a product manager working with an agent to clarify a customer problem. The agent captures the need, the options considered, and why one direction was chosen.
That shared state can then move with the work. Engineering can use it during implementation. Quality can carry the same context forward to understand the original intent, identify important risks, and test whether the result solves the right problem. Data specialists can see which measures matter, while support and operations can understand the assumptions behind the product decision.
That starts to look like shared team memory.
Today, much of this knowledge is scattered across meetings, documents, tickets, chat threads, source code, and individual experience. When someone leaves, part of that context often leaves with them.
A shared memory or knowledge store could preserve the customer problem, the decision made, the trade-offs accepted, the risks identified, and what the team learned after delivery. Over time, it could connect product knowledge, technical choices, quality findings, customer feedback, and operational experience.
That knowledge did not come with the AI model. It came from years of working with customers, operating the product, learning from failures, and understanding the domain.
This connects to a broader point I explored in The Real Intellectual Property of Modern Software. Code remains important, but a growing amount of value lives in the customer understanding, product judgment, data, operating experience, and decisions surrounding the code.
A well-designed graph may help preserve and apply that knowledge across the team.
It also requires discipline. The team still needs to decide what should be remembered, which information is authoritative, what has become outdated, and what should be protected or removed.
Shared memory can make organizational knowledge easier to preserve and reuse.
The organization still owns it.
The Graph Can Become Part of the Work
A value stream map and an AI graph can describe the same basic system of jobs, dependencies, shared state, sequential work, and parallel activity. The important difference is how each one is used.
A value stream map helps people see, measure, and improve how work moves through the system. An AI graph can make parts of that system executable.
It can assign a job to an agent, call a tool, carry state from an earlier activity, start independent work at the same time, request human judgment, or follow another path when conditions change.
That makes graph engineering useful, and it makes understanding the current workflow more important.
A graph can speed up whatever process an organization gives it. That process may include approvals that no longer serve a purpose, reviews that repeat the same work, policies that have outlived their usefulness, or handoffs that exist because of organizational boundaries rather than customer value.
AI can make that work move faster. The organization may still be producing the same waste.
Years of value stream work taught many of us to understand the work before automating it. We looked at why each activity existed, what outcome it supported, and whether the team had the authority to remove it.
The same discipline applies here. Before deciding which agent should perform a task, leaders should understand whether the task belongs in the workflow.
An Agent Can Perform the Work Without Owning the Decision
I previously explored this idea in The AI Didn’t Sign Your IP Agreement.
The same principle applies to graph engineering.
An agent may generate code, review another agent’s output, recommend an architecture, select a software dependency, or prepare a production change.
Someone still owns the customer experience and operational risk, decides how much independence the agent has earned, and stands behind the result.
A graph can record what the agent did and how the work moved. It cannot accept accountability for the business decision that allowed the action to happen.
This becomes part of the operating model.
Organizations need to decide where agents can act independently, where traditional automated controls are enough, and where a person needs to remain involved.
The answer should depend on the work.
An agent drafting internal documentation may need very little supervision. An agent changing production data or modifying a security control carries a different level of consequence.
The team and its leaders need to set those boundaries. The graph then carries the work through them.
Graph Engineering Can Improve Flow
In Profitable Engineering and several of my recent articles, I have argued that AI should be applied across the entire value stream, rather than concentrated only in product delivery or software development.
Graph engineering provides another way to help work, decisions, and context move more effectively through that broader system.
Agents can take on specialized work. Independent activities can move forward at the same time. Feedback can arrive earlier, and teams can preserve context as work moves between product, engineering, quality, data, operations, and other parts of the value stream.
This allows people to spend more of their time on decisions where judgment and consequences are highest.
That matters because work has to move efficiently through the whole system.
Bottlenecks still need to be identified, understood, and resolved.
The Theory of Constraints still applies. Improving one activity creates limited value when another part of the system continues to restrict the flow of work.
Many organizations still carry delays that have little to do with the effort required to build software. Work waits for approvals. Teams wait for another team to become available. Feedback arrives too late. Valuable context gets lost between handoffs.
AI agents and shared memory may help remove some of that friction.
The improvement becomes meaningful when it helps the team deliver a better outcome for the customer or the business.
“Work has to move. It also has to matter.”
Leadership Still Owns Realization
A graph can show whether the workflow completed, how long it took, which path it followed, what it cost, and where a person had to step in.
Those measures tell us a great deal about Flow, but they do not tell us whether the work produced a meaningful outcome.
Leaders still need to understand whether the work solved the customer’s problem, improved the product, reduced risk, created efficiency, or strengthened the business.
They also need to understand whether the result was worth the cost of the models, tools, infrastructure, and human attention needed to produce it.
Those are questions of Realization.
The graph helps work move through the system. Leadership decides which work deserves to enter the system and how the organization will know when that work has created value.
A Familiar System With New Participants
I understand why graph engineering is gaining attention.
AI systems need structure. Agents need boundaries. Work needs a clear path, feedback, recovery, shared context, and oversight. Graphs give teams a practical way to design those systems.
Software delivery leaders should learn the technology.
They should also recognize the experience they already bring.
Leaders who understand value streams and cross-functional teams have already been designing systems of jobs, dependencies, shared context, decision paths, and feedback. They have been deciding what must happen in sequence, what can happen at the same time, and where judgment and accountability belong.
They have also been building teams around the same idea. Bring together the capabilities needed to deliver, give the team enough authority to act, and reduce the dependencies that slow delivery and learning.
AI adds another participant to that team.
Shared memory may also help the team preserve more of what it learns as work moves between product, engineering, quality, data, security, and operations.
The next challenge is deciding how work and knowledge should be distributed across people, traditional software, and AI agents while keeping ownership of the whole within the team.
AI changed who can execute the work. It changed how quickly the work can happen and how much of the surrounding context can be preserved.
The responsibility to design the system around valuable work remains with leadership.
Graph engineering can improve Flow. Leadership still owns Realization.
For those who have spent years improving software delivery systems or building autonomous cross-functional teams, I am curious how graph engineering first sounded to you. Did it feel like a new discipline, or did you also recognize a familiar value stream with a new kind of participant?
The most important question remains the one we should have been asking all along.
Does the work moving through the system create an outcome that matters?
Reference: Value Streams and AI Graph Engineering
| AI graph language | Value-stream language |
|---|---|
| Job | Activity, process step, or responsibility |
| Arrow | Dependency, handoff, or flow of work |
| State | Work item, shared context, decision history, or information carried forward |
| Sequential work | Dependent activities performed in order |
| Parallel work | Activities that can proceed at the same time |
| Owner | Person, team, system, or agent responsible for performing the step |
| Output | Result passed to the next activity |
About the Author
Phil Clark is a technology executive, advisor, and author of Profitable Engineering (profitableengineering.com). His work focuses on helping leaders connect software delivery, operating discipline, and AI adoption to measurable business value.
Related Articles
- The AI Didn’t Sign Your IP Agreement, https://rethinkyourunderstanding.com/the-ai-didnt-sign-your-ip-agreement/
Explores why AI can perform work without accepting ownership, accountability, or responsibility for the intellectual property it helps create. - The Real Intellectual Property of Modern Software, https://rethinkyourunderstanding.com/the-real-intellectual-property-of-modern-software/
Examines how customer knowledge, product judgment, data, operating experience, and organizational decisions increasingly shape the value surrounding the code. - Profitable Engineering, https://profitableengineering.com/