Skip to main content

Advanced Agents

View as Markdown

Advanced Agents

This page builds on the foundations in Agents & Tools to cover multi-agent patterns, memory strategies, and safety techniques for production agent pipelines.

Multi-agent hierarchies​

A manager agent can invoke a specialist agent as a tool. The specialist is just another pipeline; it has its own source, its own nodes, and its own response target. The manager calls it the same way it calls any other tool: by sending a question and receiving an answer.

manager-pipeline.pipe
  source_1 (webhook)
  agent_1 (agent_rocketride)   ← manager
    ↓ invokes via tool call
    specialist-pipeline.pipe
      source_1 (webhook)
      llm_1 (llm_openai)
      target_1 (response)

The agent_rocketride node supports this pattern natively — expose any running pipeline as an MCP tool (see MCP Server) and the manager agent can call it.

This is useful when different specialists need different models, memory, or tool sets. Keep each specialist pipeline small and single-purpose.

Parallel tool calls​

When an agent's reasoning step identifies multiple independent tool calls, the engine fans them out concurrently. If the agent decides to search the vector store AND look up a database row in the same step, both calls happen in parallel and the results are merged before the next reasoning step.

This behaviour is automatic — no pipeline configuration is required. The latency of a multi-tool step is bounded by the slowest tool, not the sum of all tool latencies.

Agent-as-tool via MCP​

Any running RocketRide pipeline is automatically exposed as an MCP tool by the MCP server. This means a Claude Desktop or Cursor session can invoke your pipeline as a tool, making your pipeline an agent capability in an external system.

To use a pipeline as a tool in another RocketRide agent, expose it via MCP and configure the consuming agent's tool_mcp_client node to point at the MCP server.

Memory strategies​

Memory nodes give agents context across turns. The right choice depends on what you need to survive and how:

StrategyNodePersists acrossUse when
Session memorymemory_internalNothing (resets on restart)Conversation context within one session only
Persistent memorymemory_persistentPipeline restartsContext must survive restarts; backed by a configured store
Long-term semantic memorytool_mem0Restarts; searchableAgent should recall extracted facts and user preferences across many sessions

For most conversational agents, memory_internal is the right default. Add memory_persistent when sessions must resume after a restart. Use tool_mem0 when the agent is expected to build a model of the user or domain over many interactions.

When using persistent or long-term memory, scope it tightly. Storing everything degrades retrieval quality. Use the memory node's summarisation or extraction settings to store only meaningful context.

Guardrails in agent pipelines​

Place a guardrails node on the answers lane between the agent and the response target to validate outputs before they reach the caller:

agent_1 → (answers lane) → guardrails_1 → target_1 (response)

The guardrails node can check for:

  • Harmful or policy-violating content.
  • Outputs that fail a format constraint (e.g. must be valid JSON).
  • Answers that contain PII when they should not.

If a check fails, the guardrails node blocks the output. The pipeline run stops cleanly rather than returning an invalid answer to the caller.

Limiting agent scope​

Agents are powerful, but an agent with too many tools becomes hard to reason about and may make unexpected tool calls. Keep the tool set small and specific:

  • Give each agent only the tools it needs for its task.
  • Use a prompt node to explicitly tell the agent which tools to prefer.
  • Use the max_iterations config (where available) to cap reasoning loops — an unbounded loop is a latency and cost risk.