agenthub · agent.loop
Agent Loop
Give the model a goal and let it work. It plans, calls the tools bound to it, reads the results and keeps going — saving its progress after every turn, so a long run survives a restart.
Why the node earns its place
The LLM node already runs a tool loop, but as an implementation detail of one chat turn: capped at eight turns, with the working history thrown away the moment the node returns. Right for a reply, useless for an agent — a run that dies on turn seventeen would start again at turn one, having already paid for sixteen.
This node is the same loop under a durable contract. Its input is an objective rather than a conversation, its real bound is the wallet rather than a turn count, and its scratchpad is checkpointed after every turn so an interruption costs one turn instead of the whole run.
How it works at run time
- 1Take the goal from the wired
goalport, or from config when nothing is wired. - 2Plan, call bound tools, read results, continue — the same loop body the LLM node uses.
- 3Checkpoint the scratchpad into durable run state after every turn. A resume picks the history back up mid-plan.
- 4Stop when the model says it is done, when the budget is exhausted, or at the
max_iterationsbackstop.
What comes out
text what the agent concluded stopped why it stopped — done, budget, or cap iterations turns used, counted across resumes usage / leg_costs what it spent
What you wire
Inputs
- goalstring
- messagesarray
- contextobject
Outputs
- textstring
- messageobject
- usageobject
- leg_costsarray
- stoppedstring
- iterationsnumber
Configuration
| Key | Type | Default & options | What it does |
|---|---|---|---|
| provider * | string | choices from model-library:providers | — |
| model * | string | choices from model-library:models | — |
| goal | string | — | What the agent should accomplish. Overridden by the `goal` input port when one is wired. |
| system_prompt | string | — | How the agent should work — its role, limits and style. |
| temperature | number | default 0.3 | — |
| max_tokens | number | — | — |
| max_iterations | number | default 40 | Safety backstop on total turns, counted across resumes. The real limit is the run's BICS budget. |
What usually goes wrong
Watch for this
Treating max_iterations as the cost control. It is a safety backstop; the real bound is the run's budget, enforced per model call. Budget exhaustion stops the loop gracefully and keeps the work so far rather than discarding a run that did fifteen useful turns — so check stopped before assuming a short result means failure.
Behaviour & provenance