Context, Loop and Graph Engineering: The Agent Control Stack

Three control surfaces for building agentic systems that can remember, progress, coordinate and stop

Altivate | Published 5 July 2026 | Updated 26 July 2026

1. Keep the labels provisional and the responsibilities precise

The language around AI engineering is moving quickly. Prompt engineering focused attention on the instruction for one model call. Context engineering expanded the frame to everything available to the model when it decides. More recent practitioner language adds loop engineering for the system that repeatedly runs and checks an agent, and graph engineering for the topology of multiple specialized runs.

The risk is turning a useful distinction into a trend ladder:

prompt -> context -> loop -> graph

That sequence suggests each new term replaces the previous one. It does not. A production system needs all four responsibilities at the appropriate scale:

• a clear instruction;
• curated state for the current decision;
• a controlled way to continue, retry and stop;
• an explicit topology when work is divided.

This paper uses these definitions:

Context engineering controls the information and capabilities available to a model for one decision. That includes instructions, tool definitions, retrieved evidence, memory, task state, prior messages, policies and output constraints.

Loop engineering controls how one agent run progresses through repeated decisions and tool calls. It covers state persistence, checkpoints, evaluation, budgets, retries, intervention, recovery and termination.

Graph engineering controls dependencies among multiple agent or workflow nodes. It covers specialisation, handoffs, concurrency, joins, shared state, authority, error propagation and the conditions for creating or removing nodes.

These are practitioner definitions for this paper. Context engineering has direct support in current Anthropic and Google guidance. Loop engineering and graph engineering remain emerging terms with varying definitions. The engineering problems beneath them are established.

First decide whether the work needs an agent at all with RAG, tools, workflow or agent.

2. Context engineering: decide what the model may know now

Anthropic defines context engineering as curating and maintaining the set of tokens available during inference. The emphasis on curation matters. More context is not automatically better.

An enterprise agent can draw from:

• system and task instructions;
• tool names, descriptions and schemas;
• retrieved policy or knowledge;
• live business state;
• conversation history;
• short-term task memory;
• durable user or process memory;
• prior tool results;
• messages from other agents;
• policy, authority and output constraints.

Each source needs four fields:

The context specification should answer:

1. Which source is authoritative for each fact?
2. How is relevance selected?
3. How does stale or unavailable context fail?
4. Which untrusted content can carry instructions?
5. Which fields are excluded even if the caller may see them?
6. What survives into the next decision or next session?
7. How can a reviewer reconstruct the context used?

Treat tool descriptions as context. A vague tool contract can steer an agent toward the wrong operation even if the underlying API is safe. Treat retrieved documents as untrusted input. A policy PDF can contain an instruction to ignore policy.

Context quality is not measured by tokens filled. Measure whether the system selected the minimum sufficient, current, authorised evidence for the decision.

3. Loop engineering: decide how one run makes progress

An agent loop usually follows a simple shape:

1. inspect goal and current state;
2. choose the next action;
3. call a tool or produce an intermediate result;
4. observe the result;
5. update task state;
6. continue, ask for help or stop.

The difficult engineering sits around that shape.

State

What must survive between decisions? Store task progress, accepted facts, tool outcomes, pending approvals and unresolved questions in explicit state. Do not depend on the model rediscovering everything from the conversation.

Anthropic’s work on long-running agents found that context compaction alone was insufficient for consistent progress across sessions. Its approach used persistent artefacts and clear handoffs so a later session could continue incrementally. This is one vendor’s engineering pattern, not a universal architecture, but the failure mode is general: a compressed conversation is not a transaction log or a project state.

Budgets

Set budgets for:

• model turns;
• tool calls;
• elapsed time;
• consumption cost;
• breadth of search;
• number of retries;
• number of delegated tasks;
• reachable actions.

The agent should know the remaining budget and what to do when it is exhausted. “Try harder” is not a termination policy.

Checkpoints

Checkpoint after meaningful state change. A checkpoint should record:

• completed work and evidence;
• committed downstream state;
• pending work;
• unresolved risks;
• current budget;
• the next valid actions.

This supports recovery without replaying a transaction or losing a completed result.

These patterns are established systems engineering applied to probabilistic components. Treat loop state as a state machine; make side-effecting tool calls idempotent; define transaction and compensation boundaries; version checkpoints; and specify concurrency, ordering and conflict resolution. A model does not repeal distributed-systems failure modes. It makes the state and authority boundaries more important.

Evaluation

Evaluate while the loop runs and after it ends. In-loop checks can validate source, schema, authority and progress. End-state checks determine whether the outcome exists and meets the task criteria.

Stop conditions

Stop when:

• the outcome is achieved and verified;
• required evidence is unavailable;
• authority or approval is missing;
• progress has stalled;
• the budget is exhausted;
• repeated attempts enter the same state;
• a material safety or policy condition triggers;
• a person must decide.

An agent without a stop condition is not autonomous. It is uncontrolled.

4. Graph engineering: decide how work is divided

A graph becomes useful when one loop should not carry all context, tools, expertise or work.

Common node roles include:

• planner;
• retriever;
• domain specialist;
• tool operator;
• evaluator;
• integrator;
• policy or authority checker;
• human decision.

Edges are more important than node names. Every edge needs a contract:

Anthropic’s published multi-agent research architecture uses an orchestrator-worker pattern with specialized subagents. It also reports coordination, evaluation and reliability challenges. Its own measured system used much more token capacity than a chat interaction. Those figures belong to that implementation. The durable lesson is that parallel intelligence is not free. It adds coordination cost and new failure paths.

Google Cloud publishes a multi-agent GraphRAG architecture in which specialized agents navigate a knowledge graph and persistent session data. That is one useful graph pattern. It is not a definition of all graph engineering.

Build a graph only when separation creates a measurable advantage:

• independent branches can run in parallel;
• contexts would otherwise compete for limited space;
• tools or authority must be isolated;
• distinct evaluation logic belongs to distinct work;
• one integrator can reconcile bounded results.

Do not add nodes to imitate an organisation chart. A “legal agent,” “finance agent” and “sales agent” create a convincing diagram. They create value only if the decomposition improves outcome, cost, isolation or control.

5. The failure patterns cross the three surfaces

The context is correct, but the loop is not

The system has the right policy and live data, then repeats a failed tool call until it creates duplicate work. Fix idempotency, state and retry logic, not the prompt.

The loop is controlled, but the context is not

The agent stops correctly and records every turn, but it selected an outdated policy or exposed a field the caller should not see. Fix source selection, freshness and authorisation.

Each loop works, but the graph is not

Two specialists produce valid but conflicting results. The integrator has no rule for precedence or evidence quality. Fix the join contract.

The graph is elegant, but the economics are not

Specialized agents improve a benchmark slightly while multiplying latency, consumption and operations. Compare the incremental outcome with the incremental cost.

The system is observable, but no person owns the consequence

Traces, metrics and alerts exist, yet nobody has authority to stop the action or accept residual risk. Fix the operating model.

6. The architecture review workbook

Complete one row per responsibility before reviewing frameworks or platforms.

Worked example: supplier exception resolution

A procurement agent receives a blocked invoice. Context engineering assembles only the authorised purchase order, receipt, supplier master, policy version and case history, marking the supplier attachment as untrusted. Loop engineering moves the case through gather, reconcile, propose, validate and await-approval states with a cost budget and checkpoint after each tool result. Graph engineering runs tax validation and goods-receipt reconciliation in parallel, then joins them under a deterministic conflict rule. The payment-release node cannot execute without the scoped identity, current approval and idempotency key. A timeout preserves the case for recovery; it does not replay the release.

That example exposes the three design questions: what evidence enters the decision, how one unit of work progresses safely, and why multiple specialised loops are necessary.

Context workbook

Loop workbook

Graph workbook

If the “why more than one loop” row is weak, keep one loop.

Download the editable context, loop and graph architecture workbook.

7. Build in this order

Make one decision inspectable

Version the instruction, context sources, tool contract and output. Prove that a reviewer can reconstruct why one decision occurred.

Make one loop operable

Add explicit state, budgets, checkpoints, evaluation, intervention and recovery. Prove that the loop can stop and resume without repeating side effects.

Split only the constraint

Add one node because context, expertise, authority or parallel work needs separation. Define the edge contract before the new prompt.

Add graph-level evaluation

Test not only each node, but delegation quality, missing work, duplicated work, conflicting results, blocked joins and error propagation.

Re-evaluate the economics

Compare the graph with the simpler loop on quality, latency, consumption, operator effort and failure recovery. Complexity must keep earning its place.

This order prevents a common failure: a team distributes an unreliable loop across several agents, then calls the resulting coordination problem “emergent behaviour.”

8. The control-stack review

Before production, answer yes:

• ☐ Context sources are authoritative, current, relevant and authorised.
• ☐ Untrusted content cannot silently become instruction.
• ☐ Tool descriptions and schemas are versioned and tested.
• ☐ Task state exists outside the model transcript.
• ☐ Turn, tool, time and cost budgets are enforced.
• ☐ Checkpoints prevent duplicated side effects.
• ☐ Outcome evaluation is independent of agent self-report.
• ☐ Stop, intervention and recovery are tested.
• ☐ Every graph node has a necessary responsibility.
• ☐ Every edge defines payload, authority, completion and failure.
• ☐ Conflicts and partial joins have a resolution rule.
• ☐ The multi-node design outperforms the simpler loop on an accepted measure.

The stack is ready when those controls reinforce one another. More context cannot compensate for an unbounded loop. More agents cannot compensate for bad context. A stronger model cannot compensate for an ownerless consequence.

Return to How to Start with AI Agents for the operating roadmap, or browse White Papers.

Sources and verification status

Checked 26 July 2026. Loop engineering and graph engineering are emerging practitioner terms, not formal standards. Anthropic and Google sources are vendor architecture guidance.

• Anthropic, Effective context engineering for AI agents – vendor definition and practices for curating finite model context.
• Anthropic, Effective harnesses for long-running agents – vendor engineering pattern for persistent progress across sessions.
• Anthropic, How we built our multi-agent research system – vendor account of orchestration, specialisation, evaluation, cost and coordination.
• Anthropic, Demystifying evals for AI agents – vendor guidance on traces, outcomes and evaluation harnesses.
• Google Cloud Architecture Center, Multimodal GraphRAG resource orchestration – vendor reference architecture for a multi-agent knowledge-graph use case.