agenthub · ai.llm
LLM
One model call. Give it messages, get an answer — and if you bind tools to it with a tool edge, the same node becomes an agentic loop that calls them until it can answer.
Why the node earns its place
This is the workhorse. On its own it is a single, stateless generation: messages in, text out. It keeps no history, so two turns of a conversation are two unrelated calls unless something upstream supplies the history.
What makes it more than a wrapper is the tool edge. Bind a tool node to it and the node runs the model, executes the tools the model asks for, feeds the results back, and repeats until the model answers — capped by max_iterations. Nothing about the node changes; the wiring is what turns a generation into a loop.
How it works at run time
- 1If only
textis wired, wrap it as a single user message. - 2If the node has a
system_promptand no upstream node already supplied a system message, insert one — this is why an agent wired straight from Chat Input still keeps its persona. - 3Fold the current date and time into the system message, in the caller's timezone when the run carries one, so today, this week and is this overdue are answerable rather than guessed from the training cutoff.
- 4If tools are bound by tool edges, run the loop: model, tools, results, model again, up to
max_iterations. Otherwise make one call. - 5Return the text, the assistant message, token usage, and per-leg tool costs.
What comes out
text the reply
message {role: "assistant", content: …}
usage token counts for this call
leg_costs per-tool cost attribution (empty when no tools ran)What you wire
Inputs
- messages *array
- textstring
- output_schemaobject
Outputs
- textstring
- messageobject
- usageobject
- leg_costsarray
Configuration
| Key | Type | Default & options | What it does |
|---|---|---|---|
| provider * | string | choices from model-library:providers | — |
| model * | string | choices from model-library:models | — |
| system_prompt | string | — | — |
| temperature | number | default 0.7 | — |
| max_tokens | number | — | — |
| max_iterations | number | default 8 | — |
What usually goes wrong
Watch for this
Binding a tool with a data edge instead of a tool edge. With a data edge the tool runs once, unconditionally, and the model never learns it exists. With a tool edge the model is given the contract and decides. The node looks identically wired either way on the canvas — check the edge kind.
Also: this node declares delegated side effects even though it computes nothing itself. The declaration has to cover the worst case, because the tools it may call are chosen on the canvas, not here.
Behaviour & provenance