Artificial Intelligence
On-premise AI architectures, local LLMs, RAG, autonomous agents. Design and development of governed agentic systems.
Discover →
Admina Enterprise
Open Source AI governance: audit trail, PII redaction, bidirectional ALLOW/BLOCK/REDACT policies on every call and tool.
Discover Admina →
Cybersecurity
Agent security: prompt injection, least privilege, sandboxing, human-in-the-loop, NIS2 compliance.
Discover →
Research & Development
Applied research on agentic systems, multi-agent orchestration and evaluation.
Discover →A 3-part series. (1) anatomy of the cycle · (2) context, patterns and multi-agent · (3) security and governance (from 10 July). This is part 2: it assumes the basic cycle from part 1.
In part 1 we saw the skeleton: goal, decide, act, execute, observe, repeat. It works for short tasks. Making it last, and capable of big problems, is another job: it starts with the context.
Context engineering: the real bottleneck
Every step appends the model’s reply and the tool results to the context. The context grows monotonically, and this is the practical limit of long-horizon tasks: a twenty-step task with hefty tool outputs saturates the window before finishing. Worse: beyond a threshold, too much context degrades reasoning (the model drowns in its own history). Volume does not matter, relevance does. Context-engineering strategies are what make an agent last:
- Truncation: drop the oldest messages. Simple, but you lose memory.
- Compaction / summarization: compress the history into a structured summary, keeping key decisions and facts. An LLM summarizing itself.
- Externalized state: write state to files or a database and keep only the pointers in context. The agent re-reads on demand what it needs, instead of dragging everything along.
- Retrieval (RAG): fetch only the piece of knowledge relevant to the current step, rather than preloading everything.
- Sub-agent offload: a sub-agent runs an expensive search and returns a distilled result to the parent, keeping the parent’s context small.
Then there is the economics: the cost and latency of every step grow with the context length, and the context grows at every step. Prompt caching (reusing the stable portion of the context across calls) slashes, by up to 90% depending on the provider, the cost of the input tokens re-read at every step, which dominate the bill of a long loop; output tokens and uncached portions still pay full price.
Beyond the reactive cycle: plan, reflect, verify
The minimal loop is reactive: it decides one step at a time looking at the last observation. It works for short tasks, less for long ones. On top of the loop you build more robust patterns:
- ReAct (reason + act): the model interleaves explicit reasoning and action, keeping a thought scratchpad before each tool call.
- Plan-and-Execute: first generate a plan (a list of sub-goals), then execute it step by step, re-planning when an observation invalidates the assumptions. The plan is structured memory that holds course over long horizons.
- Reflexion / self-critique: after an attempt, a critic step reviews the result, spots the error and retries; the reflection is kept in memory and guides the next attempts. It is a correction loop above the action loop.
- Verification: generate → verify → fix. A second agent (or the same one, with a different prompt) adversarially checks the output before accepting it. Independent verification is what lifts reliability above “looks right”.
Multi-agent: loops of loops
When a task is too big for a single context, you move to multiple agents: an orchestrator spawns sub-agents, each with its own loop and isolated context, and aggregates their results. From the orchestrator’s point of view, a sub-agent is just another tool: it passes a task, receives a distilled result. The upsides are parallelism (fan-out over independent sub-problems), context isolation and specialization; the costs are coordination and context duplication. It is the principle behind the “ultra” modes with sub-agents now appearing in frontier models (we discussed it when covering GPT-5.6 Sol).
Robustness: errors, retries, idempotency
In the real world tools fail: timeouts, exceptions, malformed responses. In a well-built agent a failure is not fatal: it becomes an observation that feeds back into the context, and the model can recover (retry, change approach, ask for help). Three cautions:
- Retry with backoff and a cap: do not retry forever.
- Idempotency for side-effecting tools: a retry must not create two orders, send two emails, apply the same patch twice. Idempotency keys or state checks before the action.
- Containment: an error in a sub-agent must not bring down the whole tree.
Determinism, latency, cost
Sampling makes the output non-deterministic. For reproducibility you use temperature=0 and, where available, seeds; even then, determinism remains a best effort: dynamic batching, GPU floating-point arithmetic and provider infrastructure updates can still change the output for identical inputs. The latency of a loop is the sum, step by step, of model and tool latency: a ten-iteration agent multiplies by ten. The cost is the sum of tokens across all steps, with the context growing each turn. Streaming, prompt caching, speculative execution and parallel calls are what makes an agent usable in production rather than a demo.
Context, patterns and orchestration make an agent capable. But a capable agent that touches real data and actions is also an attack surface: that is the subject of part 3.
Go back to part 1: anatomy of the cycle. Part 3 (security and governance) arrives on 10 July.