Graph engineering is where AI agents stop working alone

Sometimes, the demo works but the actual rollout doesn’t. An agent on one task is reliable, but run several against the same codebase and the results stop adding up: they rebuild what a neighbor just shipped, make conflicting changes to the same file, take an approach another agent ruled out an hour earlier. The gap is coordination: assignments, dependencies, and review workflows.

Prompt engineering was about the words you gave a model. Loop engineering was about the cycle one agent ran to finish a task. Graph engineering is about how many agents work as a system: which agents exist, what each one owns, how work splits across them, where results come back together, and where a person still signs off.

Coordination has to be designed

Split a feature across several agents and you’ve created a set of dependencies that has to be spelled out. An agent acts on what it’s handed, so anything not written into the structure is invisible to it.

Say you split a service by ownership: a security agent owns auth, permissions, and audit logging; a data agent owns the schema and migrations; and an API agent owns the endpoints and their contracts. Each is capable on its own, but the API agent can’t finalize an endpoint until the data agent’s migration lands. The security agent has to review any change that touches permissions before it ships. If the data agent renames a field, the API agent needs to know before it builds against the old one. Those handoffs, dependencies, and review gates are the actual system. They don’t live inside any single agent’s loop, and they don’t emerge on their own. It’s on you to design them.