An Agentic Loop Is More Than Arrows Between Phases#

Most agent systems start with something simple. A while loop. A state machine. A list of phase names with arrows between them. intake -> classify -> draft -> review -> escalate. That is a reasonable starting point, and usually the fastest way to get a workflow running.

The trouble shows up when that loop needs to mean something outside the app that wrote it. Another team wants to reuse the same escalation flow. A teammate wants to inspect the approval checkpoints before adopting it. An SDK app needs to know what a phase expects before it trusts the workflow. At that point the graph alone stops being enough. The arrows are not wrong. They were just never the whole contract.

The app-local control-flow problem#

The failure mode is not that agent systems lack control flow. Most of them have plenty of it. The problem is that the control flow usually only makes sense inside one codebase, one runtime, and one set of local assumptions.

That matters because long-horizon agent work does not fail at the same rate as short, single-turn tasks. The gap gets worse as the workflow stretches across more steps, more uncertainty, and more chances to lose the plot. TheAgentCompany benchmark makes that painfully clear. Even the strongest agents in the benchmark complete only around 30% of long-horizon professional tasks autonomously, and the paper states directly that more difficult long-horizon tasks remain beyond current systems [1].

WebArena shows the same pattern from a different angle. On realistic long-horizon web tasks, the best GPT-4-based agent in the benchmark reached 14.41% end-to-end success, against 78.24% for humans [2]. That gap says orchestration quality matters more as the number of steps grows, not that loops are useless. A workflow that survives one phase transition is not the same thing as a workflow that survives ten.

Then there is the business side. MIT NANDA reports that 95% of enterprise GenAI pilots show no measurable P&L return, and the diagnosis is not simply “models are not good enough” [3]. The workflow-integration gap is a major part of the problem. Teams can demo a promising agent. They struggle to integrate it into real work in a way that is inspectable, governable, and repeatable.

An app-local loop is easy to write, and much harder to review, reuse, version, or compare once another team needs to adopt it. A codebase might contain a graph of phases somewhere, but if the meaning of that graph depends on reading the surrounding app code, the loop is still trapped in that app.

Support escalation is a good example. One team may have a flow that looks like intake -> classify -> draft -> review -> escalate. Another may have a similar incident-investigation shape with assess -> execute -> review -> handoff. On paper, both are just arrows between phases. In practice, each one carries assumptions about when work should stop, when it should continue, when a human should step in, and what conditions count as success. If those assumptions live only in handler code, approval callbacks, and local comments, the graph is only a sketch.

Agent control flow that only makes sense inside one app is not portable orchestration. It is app-local runtime glue.

What a phase graph leaves out#

A phase graph can say a few important things: where work starts, what phases exist, which transitions are possible. That is useful. It is also incomplete.

Real workflows need more than “and then it goes to the next phase.” Take a support escalation flow. A graph can show that a draft phase can transition to review or escalation. It does not tell you what counts as a valid outcome, whether escalation requires approval, or whether the loop should stop after eight steps, retry after a tool failure, or hand off after a blocked review.

The same is true for incident investigation. The Microsoft paper on LLM-based agents for root cause analysis is a good example because its motivating problem is not “how do we draw a graph?” It is that a single-pass analysis is not enough. The workflow needs to gather evidence, reassess, decide whether another action is needed, and continue iterating until the investigation can end or hand off [4]. The value is in the structure of the loop. A bare arrow from one phase to another does not capture that structure by itself.

What is missing?

Named outcomes, so transitions are attached to a meaningful decision rather than an implicit jump.
Checkpoints, so approval-gated or sensitive steps are visible before adoption.
Limits, so the loop has a declared boundary instead of running until some app-local condition happens to stop it.
Error policy, so the workflow says what should happen when a phase or tool call fails.
Access intent, so the workflow can at least describe what kind of surfaces a phase expects around it.

Once those concerns appear, the graph stops being just a diagram; it becomes part of the contract for how the workflow is supposed to work.

If the loop defines how an agent works, then the loop needs the same treatment every other important agent artifact needs: a name, a version, and something that can be inspected before it is trusted. Engineers already understand this instinct for tools, libraries, manifests, and lockfiles. Orchestration deserves the same discipline.

The arrows show how work moves. The contract explains what the loop expects.

Loops describe control flow, runtimes execute it#

There is an important boundary here.

A portable loop contract is not a universal executor, a scheduler, or a policy engine, and it is not proof that every transition, checkpoint, or limit will be enforced the same way in every host environment.

Drawing that boundary is deliberate. It keeps "describe the loop" from quietly turning into "run the loop."

This is also a familiar shape in good infrastructure. A schema that describes retrieval context does not replace the vector database serving it. A contract that describes durable state does not replace the database storing it. A profile that describes authored behavior does not replace the prompt, or enforce it at runtime. A contract that describes control flow should not replace the runtime executing it either.

The first useful step is to describe the phases, outcomes, transitions, terminal targets, checkpoints, limits, and error policy in a way that another system can inspect, without reading the app that authored them. Once that exists, a host app, framework, or harness can decide how to interpret and execute that description.

Without that separation, orchestration stays welded to whichever runtime happened to define it first. The workflow might run correctly in one app, but the orchestration itself is not portable. It cannot be reviewed independently or versioned as its own artifact, and another runtime cannot load it and ask basic questions about what the loop intends to do.

This is the same disciplined boundary good infrastructure work usually needs. Describe the artifact first. Keep execution decisions separate.

The first useful boundary is not “run every loop.” It is “make the loop understandable outside the runtime that authored it.”

What each phase expects to see and use#

Now take the support escalation example again.

intake -> classify -> draft -> review -> escalate

The graph tells you how work moves, not what actually matters when another team tries to adopt the workflow.

The graph doesn't say whether intake needs customer memory or just the current thread, whether classify needs a knowledge package with support policy and escalation criteria, whether draft needs tools that can prepare a customer response, whether review shares drafting's profile or gets a stricter escalation posture, or whether escalate runs on an entirely different execution surface.

Those are not small details. They determine whether a phase can run sensibly at all. A graph of phases says nothing about them. Yet every real loop implies them.

The gap sits between control flow and orchestration contract: the arrows tell you where the work goes. They do not tell you what each phase is expected to see and use while it is there.

This is where AgentPM introduces a useful term: bindings.

Bindings are authored metadata describing which package surfaces an agent expects globally or within a specific phase. That can include Tools, Skills, Knowledge, Memory, Profiles, and MCP surfaces. The important part is not the word. The important part is the discipline. The loop no longer lives as arrows plus a pile of unwritten assumptions.

Bindings are also deliberately modest. They do not compute effective runtime access. They do not enforce permissions. They do not guarantee that a host app actually scopes tools or memory the same way the authored metadata suggests. They make the expectation visible.

If a review phase expects incident memory plus an approval-gated communication profile, another team should be able to see that before adopting the loop. If an execution phase expects different tools than a reasoning phase, an SDK app should be able to read that contract before pretending those phases are interchangeable.

A loop needs more than arrows because phases imply expectations. AgentPM calls the authored scoping metadata for those expectations bindings.

How AgentPM Loops and bindings work#

AgentPM introduces kind: "loop" manifests that package phases, outcomes, transitions, terminal targets, checkpoints, limits, access intent, and error policy as a first-class artifact. The CLI supports agentpm init --kind loop, publish and install flows treat Loops as a real package kind, templates can depend on a singular dependencies.loop, and agents can carry a singular top-level loop reference.

Agents can also carry structured bindings metadata. That authored contract can describe global expectations plus phase-specific expectations for package surfaces such as Tools, Skills, Knowledge, Memory, Profiles, and MCP connections. The Node and Python SDKs expose the Loop metadata through loadLoop() and load_loop(). They also expose the authored bindings on loaded agents. None of that executes the loop. It makes the authored orchestration contract inspectable and portable.

The runtime still decides how to interpret the metadata. A local app may render it in a startup banner. A framework may map it into its own execution model. A future harness may use it more directly. The packaged contract does not depend on any one of those choices.

The full artifact model now includes control flow:

Tools package actions.
Skills package procedures.
Knowledge packages context.
Memory packages durable state contracts.
Profiles package authored behavior.
Loops package iterative control flow.
Agents compose those artifacts.
Templates bootstrap working systems from them.

Control flow now has the same status as the other building blocks. The loop is no longer an invisible part of app code. It is an artifact with identity, versioning, and inspectable structure.

The portability problem was never drawing the graph. Engineers can draw graphs all day. The harder problem is making orchestration visible enough for agents, templates, SDKs, and runtimes to understand what the workflow expects before they adopt it.

AgentPM makes authored loop structure and bindings inspectable and portable. Runtime execution remains something the host app, framework, or harness decides how to implement.

Sources#

TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks. https://arxiv.org/abs/2412.14161
WebArena: A Realistic Web Environment for Building Autonomous Agents. https://arxiv.org/abs/2307.13854
MIT NANDA. The GenAI Divide: State of AI in Business 2025 (July 2025). https://tinyurl.com/nh37nwmt
Exploring LLM-based Agents for Root Cause Analysis. https://arxiv.org/abs/2403.04123