Skip to content

How Agents Work

A Smartunit agent is a Node-RED runtime that combines instructions, a model, conversation context, memory, tools, planning, and usage controls. The agent node is the center of that configuration.

Early-stage notice: Agent behavior and configuration are under active development. These pages describe the current Node-RED implementation.

Each agent selects:

SettingWhat it controls
ParentWhether the node is a root agent or a sub-agent.
ConnectionProvider endpoint and credentials used for model calls.
BehaviourInstructions, planning mode, iteration limit, router, and debug mode.
ReasonerDirect or Thinker model-call strategy.
ModelModel used by Direct, or Think Model used by Thinker.
Schema ModelOptional extraction model used only by Thinker.
MemoryFacts store, events store, and fact scope.
BudgetOptional token or provider-reported spend limit.
ContextAmount of stored conversation history supplied to the model.
Skill SetFlow actions the agent is allowed to call.

The connection, behaviour, models, memory, and budget are reusable Node-RED configuration nodes. A change to a shared config node can affect every agent that references it.

agent.request
-> check the configured budget
-> load conversation history, facts, and runtime context
-> call the model using Direct or Thinker
-> execute returned actions, including optional plan operations
-> repeat when tools or memory operations require another step
-> emit agent.response, agent.clarify, or agent.error

The runtime processes actions through an event loop. A model response can ask for a tool, read or write memory, update a plan, ask the user for clarification, or finish with a response.

If a model returns both a tool call and a final response in the same step, the tool call takes priority. The agent continues after the tool result instead of ending before the requested work is complete.

Max Iterations limits agent reasoning steps for one request. It does not directly count provider requests:

  • Direct normally uses one provider request per reasoning step.
  • Thinker normally uses two provider requests per reasoning step.

When the limit is reached, the runtime asks the model for a best-effort final response rather than silently continuing forever.

sessionId identifies a conversation. Events and conversation history are associated with the session.

userId is optional for requests, but it is required for reliable user-scoped memory and non-session budgets. When a memory node uses User scope, facts can follow the same user across sessions.