Skip to main content

Agents & Tools

View as Markdown

Agents & tools

Most nodes pass data along a lane and move on. An agent is different: it reasons in a loop, deciding which model to call, which tools to use, and when it is done. To do that it needs a few helpers wired to it: an LLM, optionally tools, and (for some agent types) memory.

Data lanes vs. control connections

Agents introduce a second kind of wiring alongside data lanes:

  • Data lanes carry data into and out of the agent, a question arrives on an input lane, an answer leaves on an output lane.
  • Control (invoke) connections attach the agent's capabilities: the LLM it thinks with, the tools it can call, the memory it reads and writes.

See the Execution model for how the two interact.

Wiring: control lives on the helper

The connection between an agent and its helpers is declared on the helper, not on the agent. Each LLM, tool, or memory node carries a control array whose from points back at the agent that invokes it. The agent itself has no control array, only its input lanes.

The agent has input lanes only, no control array. The LLM declares it is controlled by the agent, and the tool does likewise:

[
{ "id": "agent_1", "provider": "agent_rocketride",
"input": [{ "lane": "questions", "from": "chat_1" }] },
{ "id": "llm_1", "provider": "llm_openai",
"control": [{ "classType": "llm", "from": "agent_1" }] },
{ "id": "tool_1", "provider": "tool_http_request",
"control": [{ "classType": "tool", "from": "agent_1" }] }
]

A single LLM, tool, or memory node can serve several invokers: list each one as its own entry in the helper's control array.

Tools

A tool (class type tool) is a capability an agent can invoke at runtime: an HTTP request, a web search, a shell command, a filesystem or git operation, another pipeline, and many more. Tools have no data lanes: nothing streams through them. They sit idle until an agent decides to call one, then return a result to that agent. A tool joins a pipeline purely through its control connection.

Memory

Some agents keep state across turns through a memory node (memory_internal or memory_persistent), wired the same way as any other helper.

AgentLLMMemoryTools
agent_rocketrideRequired (exactly 1)Required (exactly 1)Optional
agent_crewaiRequired (min 1)Not supportedOptional
agent_langchainRequired (min 1)Not supportedOptional

Only agent_rocketride has a memory port. Do not wire memory to agent_crewai or agent_langchain.

Multi-agent pipelines

An agent can invoke another agent as a tool. The sub-agent declares control: [{ "classType": "tool", "from": "<parent_agent_id>" }] and takes no input lanes of its own, it is driven by its parent. The sub-agent's own helpers (its LLM and memory) point their control at the sub-agent, not at the parent. This lets you compose specialists under a coordinator.

The same invoke/control pattern applies beyond agents, any node whose catalog entry declares an invoke field (for example summarization or extract_data) is wired to its LLM the same way.

Next steps