For those would put some serious thoughts and time to agent work, the loop looked like this: write a prompt, send it to an agent, watch what came back, adjust. Humans here are the glue between steps. That is changing fast I am not sure practitioners are noticing.
In practice the shift is: AI-native professionals are no longer the ones sending prompts to agents. Other systems are. An event fires, a schedule ticks, a goal-state check fails — and the agent gets its next instruction automatically, from another piece of software rather than from a person at the keyboard. The human only enters the loop when the agent decides the situation warrants it. This is how it is going to be: verification and evaluation are paramount.
This is what “control graphs” actually refers to in practice: a structured workflow that defines what an agent does at each step, what it does next depending on the outcome, and what state it carries forward. Nodes, edges, state. This three-part structure is not new but it is how workflow automation has always worked. What is new is that a node can now be a full reasoning agent rather than a simple script or lookup call.
Two Patterns
The groups of emerging patterns at AI-native are two.
The first is the agent loop: a trigger (time-based, goal-based, or event-based) wakes an agent on a schedule or in response to an event. The agent works, checks whether it has satisfied its goal, and either continues or surfaces a decision to a human. The key design question is not “how do we build the loop”, but “what can the agent do alone, and where does a human genuinely need to be in the path?”
The second is the orchestrator pattern: a top-level agent with full context spins up a team of sub-agents to handle execution, monitors their outputs, and synthesizes the results. Running hundreds or thousands of agent tasks overnight without human supervision is already happening (eg. in the so called “Dark” Factories.
Implementing a Control Graph
There is no single required framework and two approaches are in use, each with a different tradeoff.
The text-based approach (sometimes called LLM-as-graph) means writing the workflow as a standard operating procedure — plain text, JSON, a diagram, or a skill file — and letting the agent follow it natively. There is no graph framework involved. The limitation is that it does not resume state cleanly across separate sessions.
The code-based approach means writing the graph structure explicitly in code (e.g. LangGraph), using primitives like sequential pipelines or parallel fan-out. Each agent node outputs a typed schema that becomes the input for the next node’s prompt. This suits very large or highly deterministic workflows where resume-ability and predictability matter more than flexibility.
For most everyday workflows, the text-based approach is the more practical starting point. Code-based graphs make sense when the task scale or the need for strict output schemas genuinely demands it.
The Pattern Loops Are Still Missing
There is one design choice that separates loops that work from those that drift or hallucinate silently: a separate verifier node.
Asking an agent to evaluate its own output within the same context does not work well. The agent that produced the result tends to rationalize it rather than catch its flaws. A distinct agent node — given the original goal and the output, with a clear brief to evaluate rather than generate — is a different approach. This addition, more than any choice of framework or infrastructure, unlocks loops that can run unattended without quietly producing bad results.
The complementary approach is keeping deterministic steps in code rather than in agent calls: data fetching, running tests, spinning up a dev environment, evaluating against known metrics. Agent calls handle the reasoning; code handles the mechanics. This approach is more token efficient
Where This Is Heading?
The next question in this space is what happens when a company is running not one agent loop but many simultaneously. Errors in one loop may cascade into another. Improvements, if accumulated correctly, can compound across the system. Nobody seems to has solved this cleanly just yet. This t is the kind of architectural choices that tends to lag behind the tooling. How organizations design for this compounding behavior, whether for improvement or for failure, is likely to be one of the most important design decisions in AI-native operations over the coming years.
Text summarized and optimized using Anthropic’s models and reviewed by a human.