An AI agent can understand a request such as “correct this customer record,” but understanding the request is not the same thing as being authorized to change a production database.   That difference is where graph engineering becomes important. Instead of allowing one agent loop to decide, execute, and declare success, we can design a workflow graph that separates interpretation, planning, authorization, approval, execution, verification, recovery, and completion. This post uses one invented teaching scenario throughout: a support user asks an AI assistant to correct the phone number stored for customer <CUSTOMER_ID> . The database, business rules, identities, and values are fictional. The architecture is a teaching model, not a description of any private company's implementation. The central idea is simple: the model may help decide what the user probably wants, but the graph should decide which controlled path is allowed, and the database executor should enforce wha...

When an AI agent changes software, the difficult engineering problem is not simply getting the model to write code.   The harder problem is deciding what happens before the change, what evidence must exist before the next step, which tools are allowed to act, what happens when tests fail, when a human must intervene, how state survives interruption, and how the system knows that the work is actually finished. That is where graph engineering for AI agents becomes useful. Instead of treating an agent as one large loop that can freely decide what to do next, we can represent the work as a controlled workflow: planning, inspection, implementation, testing, review, repair, approval, and completion connected by explicit routes. This article uses one fictional software-engineering scenario throughout: an AI-assisted system receives a change request, creates a structured implementation plan, inspects a repository, proposes a change, runs tests, reviews the result, repairs failur...