Walk into a distribution center and show an operations team a new conveyor design. Nobody will begin by asking how powerful the motor is. They will ask where the line branches, what happens when a carton fails a scan, where work can recirculate, which route has priority and where a person can stop the system.
For some reason, we have spent much of the agentic AI wave doing the opposite. We talk about the model first (its reasoning scores, context window and tool use) and treat the workflow around it as implementation detail.
Three events in the last four weeks suggest this order is beginning to reverse. Google has released a graph-based workflow engine for ADK Go 2.0, Microsoft has brought declarative multi-agent workflows to version 1.0 in Python and .NET, and a preprint by Mingzhou Fan, Siyuan Xu and Mingxuan Yuan proposes an attention layer that decides which parts of a multi-agent graph deserve to be executed.
Taken separately, these are a product release, a framework milestone and an early research idea. Together, they point to something broader: the graph is becoming the operational plane of the agent.
A graph is not just a nicer flowchart
A simple agent loop is easy to explain. Give the model an objective, let it choose a tool, observe the result and repeat until it finishes. That is enough for a prototype and, in tightly bounded cases, sometimes enough for production.
Real-world operations are rarely that simple; a request may require triage before reaching a specialist, two investigations may run in parallel, a failed tool call may require a retry, while a business rule failure must follow a different route. The workflow may have to wait overnight for a supervisor, maintain its status, and resume with another process the following morning.
The use of graphs makes these differences possible:
1. Nodes represent the actions or tasks that the system executes.
2. Edges connect these nodes and establish the possible flow paths.
3. The state acts as a shared memory that stores and transports the information generated during execution.
4. Conditions evaluate this state to decide which path to follow next.
5. Finally, checkpoints save a snapshot of the process, allowing it to be paused, resumed, or recovered without starting from scratch.
The model supplies the intelligence, the graph decides where that intelligence may go, what it may touch and when a human gets the final word.
That is why graph architecture matters far beyond software elegance. It is where autonomy becomes an operating model.
Microsoft: the workflow becomes something the business can inspect
On 23 July, Microsoft announced that Declarative Workflows had reached version 1.0 across both Agent Framework SDKs. The important detail is not simply that the framework supports branches, agent handoffs, loops, tools, approvals and checkpoint recovery. Many orchestration tools already offer versions of those capabilities.
The important change is that Microsoft allows the orchestration to live in a YAML document instead of being buried inside application control flow. The definition states which agent runs, how workflow state changes, where execution branches and when a person must intervene. It is then loaded into the same runtime used by code-first workflows.
This separation has an operational consequence I find more interesting than the syntax. A product owner, solution architect or operations lead can review the shape of the workflow without reconstructing it from source code. Adding an approval gate or changing an escalation route becomes a visible, versioned change.
In a warehouse environment, that is not cosmetic. If an agent can reprioritize work or propose an inventory movement, I want the boundary of that authority to be reviewable by the people accountable for service and stock, not only by the developer who implemented the agent.
The graph becomes part of the control documentation.
Google: the graph becomes the runtime
Google's ADK Go 2.0 announcement on 30 June approaches the same problem from a different direction. Its new workflow engine represents multi-agent applications as nodes and edges, then hands execution to a scheduler capable of concurrency, persistence, pausing for human input and resuming across process restarts.
Google summarizes the design with a short line: a graph is an agent.
That matters because it removes the artificial separation between a single intelligent component and the system coordinating many of them. A function, an LLM-powered specialist and a complete workflow can participate in the same execution model. Human-in-the-loop is not an exception bolted onto the end; it is one of the primitives from which the graph is built.
This is exactly the direction production systems need. A demo is judged by whether it reaches the answer. An operational agent is judged by whether it can reach the answer, survive interruption, expose its current state and stop safely when the next action carries consequences.
The graph gives those requirements somewhere concrete to live.
New research asks a harder question: should every node run?
Once we accept graph-based orchestration, the next problem appears quickly. Bigger graphs contain more specialists, more routes and more opportunities to spend tokens and time on work that contributes very little to the objective.
A preprint published on 26 July, Focus Is All You Need, calls this problem attention dilution. Its proposed framework, Adaptive Goal-aware Attention Orchestration, or AGAO, inserts an attention layer between the user's objective and the agent graph.
The system estimates three things:
1. How relevant each agent is to the goal.
2. How important it is within the graph's dependency structure.
3. How computational resources should be allocated.
Those signals influence which agents activate, which execution paths receive priority and how the graph adapts as intermediate results arrive.
The idea is compelling: do not send every case through the entire multi-agent organization. Focus the expensive reasoning on the critical path.
But this is where precision matters. AGAO is a recent research preprint evaluated by its authors on limited task suites. It is not a production feature from Microsoft, Google or LangGraph, and its reported gains should not yet be treated as an industry result. What it offers today is a useful direction: after graph engineering comes the question of how intelligently the graph allocates attention.
What would this look like in a WMS?
Imagine an agent investigating a stockout risk for an urgent order. A weak design gives one model broad access and asks it to solve the problem. A graph-based design separates the work:
- One node validates the order, allocation and inventory facts.
- Two branches investigate replenishment and alternative stock in parallel.
- A policy node checks lot, ownership and customer restrictions.
- A planning node compares the feasible options.
- A human-approval node interrupts the workflow if the proposal changes a service commitment or consumes protected inventory.
- An execution node performs only the approved WMS transaction.
- A final node verifies the result against the live operation.
The edges matter as much as the nodes. The execution agent should not be reachable before policy validation. A failed data lookup should retry; a policy conflict should not. The graph must distinguish a technical exception from an operational rejection.
An attention-aware version could go further. If adequate stock exists in the assigned location, the alternative-stock and transport-impact branches may not need to run. If the order is already inside a critical dispatch window, those branches could receive more budget and execute in parallel.
That is a much more useful definition of intelligence than simply adding more agents.
What I would ask before approving the graph
These announcements reinforce a checklist I would want answered before an agent touches a live operation:
- Can I see every route that reaches a write action?
- Is the shared state made of traceable operational facts rather than opaque summaries?
- Are retries bounded and different from business-rule loops?
- Can a human approval pause indefinitely and resume without repeating earlier actions?
- Does each specialist receive only the tools and credentials required by its node?
- Can we reconstruct why one branch ran and another did not?
- What is the cost and latency of the longest path through the graph?
Those questions are not model evaluations. They are graph reviews.
Microsoft is making that graph easier to inspect and version. Google is making it the execution model itself. Early research is asking how it can focus dynamically on the paths that matter. The common signal is difficult to miss.
We spent the first phase of agentic AI choosing better models. The next phase will be about designing better routes around them: routes that are durable, observable, economical and constrained by the reality of the operation.
In other words, the model may still be the most impressive component in the room, but the graph is becoming the product.
---
Sources: Microsoft Agent Framework, Move Agent Orchestration/Workflows out of Code with Agent Framework Declarative Workflows 1.0 · Google Developers Blog, Build reliable multi-agent applications with ADK Go 2.0 · Mingzhou Fan, Siyuan Xu and Mingxuan Yuan, Focus Is All You Need: Adaptive Goal-aware Attention Orchestration for Multi-Agent Graph Systems