In This Issue
What “graph engineering” means in the current agent architecture discussion.
Why agent workflows are moving toward a mix of model reasoning and explicit software control.
When a graph improves reliability, and when it adds unnecessary structure.
What production examples show about routing, state, retries, permissions, and human review.
The signal
“Graph engineering” is a newly surfaced label for an established software architecture pattern now being applied to AI agents.
LangChain started using the term publicly in July 2026. Its description is straightforward: represent an agentic system as a graph so the builder can define valid paths, decide where the model gets to choose, and enforce deterministic behavior where needed. Nodes perform work. Edges determine what happens next. State moves through the workflow. A node can contain code, a model call, a tool call, or an entire agent with its own internal loop.
The terminology may or may not last. The architecture is more important.
Google ADK 2.0 now provides graph-based workflows that combine deterministic steps with LLM agents and human intervention. Microsoft Agent Framework describes workflows as explicit graphs for processes where order, decision points, checkpoints, and approval gates should be defined in advance. OpenAI's Agents SDK describes the same underlying design choice without using the graph-engineering label: orchestration can be controlled by the LLM, controlled in code, or combine both approaches.
The practical question is becoming clearer:
Which parts of an AI workflow should the model be allowed to decide, and which parts should software control?
What graph engineering is
A graph turns the execution structure of an AI application into an explicit part of the system.
Consider a customer refund process.
A traditional autonomous agent might receive instructions, access several tools, inspect the customer's history, interpret the policy, decide whether a refund is allowed, issue it, send the confirmation, and close the ticket.
The model is doing two different jobs. It is reasoning about the customer's situation, but it is also orchestrating the process.
A graph separates those jobs.
One node can retrieve the purchase history. Another can let an LLM interpret an ambiguous complaint. Code can apply the routing decision. Another node can issue the refund. A separate agent can draft the response. The workflow can then close the ticket.
Google uses essentially this example in its ADK 2.0 documentation. Its recommendation is to use deterministic execution when the sequence is known and reserve model reasoning for steps involving ambiguity or unstructured information.
The graph does not remove the agent. It defines where the agent operates.
Why it matters
Prompting can describe a process. Software can enforce one.
A prompt can tell an agent to validate permissions before taking an action. An explicit workflow can make the permission check a required transition before the action becomes reachable.
A prompt can tell an agent to retry after an error. A workflow can define which failure returns to which node, what state is preserved, and when the process stops retrying.
A prompt can ask an agent to request human approval. A workflow can pause at an explicit gate and resume only after that decision arrives.
This is why the emerging graph discussion belongs closer to software architecture than prompt engineering.
Microsoft makes the trade-off particularly clear. Its Agent Framework describes a spectrum from a single agent, where the model chooses every step, through hybrid workflows, where agents handle reasoning-heavy steps inside a graph, to fully deterministic business logic with no LLM involved. Microsoft recommends starting with simpler patterns and introducing workflows when explicit execution order or other controls are actually required.
Where should autonomy live?
The useful rule is simple:
Encode the process you know. Use agents for the uncertainty you cannot economically encode.
Suppose an AI system investigates a failed payment.
The system may already know that identity must be verified before account data is accessed. Permissions must be checked before a transaction is changed. Some remedies may be calculated from fixed rules. Refunds above a threshold may require approval.
Those are poor places to spend model reasoning.
The investigation itself may be different. The system may need to interpret logs, compare unusual events, search documentation, reason across conflicting evidence, or decide what additional information is needed. That is where an agent can earn its autonomy.
This produces a hybrid architecture:
Input → deterministic checks → agent investigation → policy/routing → action or human review → completion
OpenAI's Agents SDK supports the same architectural choice. Developers can let an LLM plan and delegate when a task is open-ended, orchestrate agents through code when the application should determine the flow, or combine the patterns.
The architecture decision is not graph versus agent.
It is who decides what happens next at each point in the workflow.
What production systems show
Uber's Finch is a useful first-party example.
Uber says it uses LangGraph to construct and orchestrate specialized agents for financial data retrieval. A Supervisor Agent routes requests to agents such as its SQL Writer. The SQL Writer retrieves metadata, constructs queries, validates user permissions before execution, and can rewrite a failed query using the returned error. Uber evaluates sub-agent accuracy, supervisor routing, end-to-end behavior, and regressions separately.
The lesson is not that every financial application should use LangGraph. It is that explicit orchestration gives Uber distinct components and transitions it can evaluate independently.
A LangChain customer case study describes a different pattern at Remote. Remote's Code Execution Agent combines LLM reasoning with deterministic Python execution for HR and payroll data migration. Ingestion, mapping, execution, and validation are represented as graph steps with explicit success, failure, and retry transitions. According to the case study, the workflow converts diverse source data into Remote's target schema in hours rather than days.
Another LangChain case study describes Trellix using map-reduce graphs and reusable subgraphs in its Sidekick system. The reported use cases include log parsing and SaaS integration development, with human intervention available during development. The case study says Trellix reduced manual log-parsing work from days to minutes.
Different industries. Different workflows. The recurring condition is more useful: the work has multiple steps, state, branching, exceptions, or consequential actions that benefit from being made explicit.
When not to use a graph
Graphs also create architecture you have to own.
A single model call does not need a workflow engine. A simple agent with a few tools may not need one either.
Open-ended research is another case where too much predefined structure can work against the task. LangChain says its own earlier deep-research implementation used predefined graph workflows and later moved toward a more autonomous core loop because planning, delegation, search, and synthesis were difficult to specify in advance.
Microsoft similarly recommends trying simpler patterns before reaching for workflows because graphs introduce additional setup and debugging complexity.
The test should therefore not be:
Can I draw this as a graph?
Almost any process can be.
Ask instead:
Does making this path explicit give me enough control, recovery, observability, or reuse to justify maintaining it?
Graphs add control, not automatic security
There is also an important security distinction.
Google argues that separating workflow routing from the LLM can mitigate prompt-injection risk. If a manipulated model does not have a valid graph path to a sensitive operation, the workflow can prevent that transition from occurring.
That is useful, but it should not be interpreted as a complete security boundary.
A badly designed graph can still expose overly powerful nodes. Tools still need authorization. Inputs still need validation. Application code can contain flaws. Permissions, identity, policy enforcement, secrets management, and auditing remain separate controls.
The graph reduces the number of execution decisions entrusted to the model. It does not make the surrounding system secure by itself.
What to know before committing
Graph engineering starts with workflow understanding.
If the team cannot describe the states, mandatory steps, exceptions, decision boundaries, and authority lines, choosing a graph framework will not solve that problem.
Start by mapping the work.
Which steps always happen?
Where does the path branch?
Where is judgment genuinely required?
Which actions change data or affect external systems?
Where can the process fail?
Where must it stop for a person?
Once those boundaries are visible, the architecture usually becomes easier to choose.
At application scale, this may remain a relatively small orchestration problem. At platform scale, additional questions appear: shared workflows, tenancy, reusable agents, access control, persistence, observability, deployment, cost allocation, and workflow versioning.
That is when graph engineering stops being only an application concern and begins touching platform architecture.
Builder takeaway
Do not begin by choosing LangGraph, ADK, Agent Framework, or another orchestration tool.
Begin with the workflow.
Keep ordinary code where the outcome is known. Use model reasoning where interpretation or adaptation creates value. Put human review where authority cannot safely be delegated.
Then decide whether the resulting process is complex enough to justify an explicit graph.
Operator takeaway
Graphs can make agent systems easier to inspect because the workflow creates identifiable states, routes, and execution steps.
That gives operators places to measure failures, retries, latency, model usage, human interventions, and recovery behavior.
But the graph is only the structure. Reliability still depends on state management, permissions, failure handling, checkpointing, evaluation, and operational discipline.
Worth reading
LangChain's “3 Years of Graph Engineering with LangGraph” is useful because it separates the recent terminology from the established architectural idea. It also identifies the more interesting shift: a graph node can increasingly contain a capable agent with its own internal loop, rather than only code or a single model call.
Takeaways
“Graph engineering” is a new label for an established architecture pattern.
The important decision is where autonomy belongs inside the workflow.
Use explicit workflows when process order, routing, recovery, permissions, or human gates matter.
Keep more autonomy when the path itself must emerge through reasoning.
Map the workflow before choosing the orchestration framework.
Reply
Where in your current AI workflow should the model decide what happens next, and where should software keep that decision?
If this helped you, leave a comment or your reaction. I’d like to hear where you landed.
INVENEW exists to help tech builders, operators, founders, and leaders turn AI from experiments into working systems.
In partnership with AWS
Sponsored link – Webinar: Redefining application and API security in the age of AI. See how to embed security early, align with compliance expectations, and discover AWS Partner solutions in AWS Marketplace.
Note: Third-party company and product names belong to their respective owners and are used for identification and illustrative reference only.