Three Graphs, Three Jobs: Loop, Task Graph & Plugin Runtime in Agent Systems

Previous articles discussed Harness, Loop, Graph, plugin loading, and runtime Context. When combined in a single Agent Runtime, a confusion appears: task graphs, component graphs, and evidence graphs all look like graphs and get stuffed into one "main Agent," creating a central conversation that knows everything, schedules everything, and loses boundaries.

Conclusion First: Three Structures Solve Three Different Levels

They can be distinguished in one sentence:

Loop – how a single task node converges.

Task Graph – how multiple task nodes collaborate.

Plugin Runtime – what capabilities a node can actually use.

All three need state, input, output, and boundaries, but their objects differ.

Loop: Only Handles Node-Internal Convergence

Loop’s object is always a piece of work with a relatively clear boundary. Example: the backend implementation node for "add rate limiting to login API" runs:

read current design baseline
-> modify rate-limiting implementation
-> execute build and related tests
-> correct based on failure evidence
-> re-verify
-> complete, wait, block, or hand off to human

Key point: after a test failure, the next step is not necessarily "keep fixing code."

If failure stems from implementation logic, Loop corrects and retries locally.

If failure stems from a design gap, Loop stops guessing, emits a structured issue, and requests Task Graph routing.

If failure stems from environment or permissions, Loop waits or blocks; it must not mask missing preconditions with retries.

If a high-risk action is triggered, Loop escalates to human confirmation instead of expanding its own permissions.

Loop therefore does not decide how the whole project is split, nor does it manage tool-provider lifecycles. It only consumes the capabilities and conditions already granted to the current node and owns that node’s state and evidence.

Task Graph: Makes Work Dependencies, Parallelism, and Recovery Explicit

When "add rate limiting" expands to design, implementation, test, security review, and integration verification, a single Loop should not coordinate everything. The Task Graph clarifies four relationships:

Dependency : without a design baseline, backend implementation and test-case design cannot start.

Parallelism : after design confirmation, backend implementation and test-case design can run in parallel.

Convergence : integration verification must wait for both branches to deliver.

Exception Routing : design gaps route back to the architecture node; test failures route back to the affected implementation node; high-risk changes enter human approval.

Task Graph manages work state, not the state of a single model call. A node must at least declare: what it depends on, what it produces, who is responsible, what constitutes done, and where to go on failure. Example node specification:

node:
  id: backend-rate-limit
  requires: [design-baseline]
  produces: [code-diff, test-evidence]
  done_when: [build-passed, required-tests-passed]
  on:
    design-gap: waiting-design
    implementation-error: retry-locally
    approval-required: waiting-human

Here retry-locally enters the current node’s Loop; waiting-design and waiting-human change the Task Graph node state and wait for external conditions. The Graph’s value lies not in drawing many boxes, but in turning implicit dependencies, responsibilities, state transitions, and recovery scopes—previously hidden in the main Agent’s context—into inspectable runtime contracts.

Component Graph: Manages Capability Assembly, Not Workflow

The same task node at runtime also uses models, code repositories, terminals, dependency installation, test sandboxes, logs, and data services. These objects form a graph, but it is not the Task Graph.

Backend implementation node
-> resolves Code Edit Skill
-> binds restricted terminal and workspace
-> uses allowed-version dependency installation capability

Test node
-> resolves Test Skill
-> binds test sandbox, test data, and log capability

The Component Graph focuses on provider–consumer composition: who provides what, who depends on what, which version is actually bound, whether permissions and environment are satisfied, and which consumers must re-evaluate when a provider changes. It should not decide "test node must wait for backend node" or route design gaps to architects—those are Task Graph responsibilities. Conversely, the Task Graph should not treat "replace code-execution tool v1 with v2" as an ordinary development step. Tool replacement is first handled by the Component Runtime for compatibility, permissions, actual binding, and impact analysis; then the affected nodes, caches, and invalidated evidence are notified to the Task Graph.

The two graphs align through runtime Context: Context resolves the actual visible capabilities, versions, permissions, and isolation resources for a task node; the Task Graph records the conditions under which the node ran, what it produced, and whether the results remain valid after conditions change.

Routing Each Problem to the Right Layer

Separating the three layers clarifies many debated questions:

Unit test fails, code logic needs fixing → current node’s Loop. Reason: node goal and capabilities unchanged; local convergence.

Developer discovers missing interface fields and business rules → Task Graph. Reason: must freeze affected nodes and route to the design-baseline maintainer.

Tool, model, sandbox, or permission provider changes → Component Runtime. Reason: must recompute actual bindings, compatibility, and affected scope.

Completed node’s input version changes → Task Graph with evidence mechanism. Reason: must judge which downstream artifacts and validation results are invalidated.

High-risk external action needs approval → Task Graph triggers human gate. Reason: not a permission upgrade the model or plugin can decide alone.

This table is not a rigid classification. A tool replacement may invalidate test evidence, eventually requiring the Task Graph to rerun affected nodes; a node’s environment fault may be confirmed first by the Component Runtime. The key is to identify what changed: the current node’s implementation and plan, the dependencies between tasks, or the runtime capabilities themselves.

Stop Piling All State into a Main Agent

Many Agent systems start with an "omnipotent main Agent": a long prompt, access to all tools, self-decomposition, self-created sub-agents, self-recorded state, self-judged completion. Prototyping is fast, but complexity brings typical problems:

Task dependencies exist only in context; impossible to judge which nodes can run in parallel or need rerun.

Sub-agents inherit excessive tools and data permissions; least-privilege delegation is hard.

After tool replacement, permission revocation, or sandbox change, old sessions may still use stale assumptions.

"Completed" is just text the model wrote; it cannot be traced to a specific design version, code version, or validation evidence.

Every exception falls back to the main Agent, becoming an ever-longer, ever-harder-to-recover conversation.

This is not because the main Agent isn’t smart enough; it’s because control problems at different levels are handed to a single context and a single model turn. What truly needs to converge is not prompt length, but responsibility boundaries.

Phase 1: No Need for Dynamic Graph Generation Yet

Distinguishing Task Graph, Loop, and Component Runtime does not mean building a complex graph platform in phase one. A more practical approach: pick one real execution chain and freeze the following:

Use a small, static Task Graph with node count within manual-review range.

Define per node: inputs, outputs, responsible role, completion conditions, exception destinations.

Only resolve approved models, tools, Skills, data services, and sandboxes for each node.

Let the node-level Loop handle only local correction, with explicit stop states: completed, waiting_design, waiting_human, blocked.

Bind capability versions, permissions, environment, and validation evidence to node execution records.

Validate recovery paths with one design gap, one test failure, and one tool/permission change.

First prove the system can do local reruns, re-validate after condition changes, and stop when boundaries are exceeded—before discussing autonomous task decomposition, graph modification, or cross-project graph reuse.

Summary

Complex Agent systems need at least three main structures, with Context and Evidence as cross-cutting concerns:

Task Graph: how work is organized.

Loop: how a single node converges.

Component Graph: what capabilities a node can use.

Context: binds capabilities, permissions, and isolation to the current node.

Evidence: explains why the node and the whole can be accepted.

Putting all these structures into one main Agent does not make the system smarter; it only makes task routing, capability boundaries, and acceptance criteria invisible. The next article will discuss the other side of this boundary: when "everything is a plugin," who is responsible for external side effects, version changes, and production audit.