AI Agent Workflow: Passing data between `ai_tool` nodes (SerpAPI to Code Tool)

Questions
1

AI Agent Workflow: Passing data between ai_tool nodes (SerpAPI to Code Tool)

Hi n8n community,

I’m working on an AI Agent workflow where the agent needs to use a Fallback - Enrich with Google Search (SerpAPI) tool and then process its output with a Code Tool.

Both the SerpAPI tool and the Code Tool are connected to the AI Agent - Lead Collection node as ai_tool connections (dashed lines), meaning the AI Agent orchestrates their use.

The core problem: I cannot draw a direct solid connection line from the Fallback - Enrich with Google Search node to the Code Tool (or to a Set node in between) because the Fallback node, when used as an ai_tool, doesn’t seem to have a direct sequential output for items[].

My understanding is that the AI Agent itself needs to handle the data transfer:

  1. The AI Agent calls the Fallback - Enrich with Google Search tool.
  2. The AI Agent receives the output from the Fallback tool.
  3. The AI Agent then needs to pass this output as an argument to the Code Tool when calling it.

I’ve tried adjusting the AI Agent’s systemMessage to instruct it to perform this sequence (e.g., “Upon receiving results from Fallback, pass them to Code Tool”). I’ve also adjusted the Code Tool to receive data as an argument (e.g., const raw = data; instead of $input.first()).

My questions are:

  • Is this the correct approach for handling data flow between ai_tool nodes orchestrated by an AI Agent?
  • Are there specific prompt engineering techniques or best practices for the AI Agent’s systemMessage to ensure it correctly passes the output from one ai_tool to another?
  • How should the Code Tool be structured to reliably receive this data when it’s passed as an argument by the AI Agent?

Any guidance or examples on this inter-tool data transfer within an AI Agent’s orchestration would be greatly appreciated!

TEMPLETS HERE

Thanks in advance!

2

Hey @Ricardo_Tatagiba

Generally speaking though it is possible, you want to avoid having the agent to be passing around large JSON arrays or objects. In your case, the Agent taking the whole of the search results from the SERPAPI tool and inputting them into the code tool.

Since they are always being called together, it’s better to combine the SERPAPI + code tool into a custom workflow tool and use them as a subworkflow like you are doing with the google maps and content crawler.

This way you don’t need to over-engineer the system prompt to have implementation-specific instructions which may not always work.

Here’s an example using the official SERPAPI community node.

3

Hey Jim, thanks a lto for your time and response. I will try this template and i’ll tell you about the results

4

Totally resonate with your ‘who owns the retry’ dilemma. Our current pattern is a three-layer safety net:
• Agent Self-Awareness – each agent is prompted to detect when it lacks sufficient context and to ‘escalate’ instead of hallucinating.
• n8n Workflow Guardrails – a simple JS function node checks the agent’s JSON output against a schema and fails fast if it smells off.
• Supervisor Flow – any failure bubbles to a separate “Incident Router” workflow that decides whether to auto-retry, notify Slack, or hand the task to a human.

The nice part is we can tweak retry policies without touching agent prompts, but the trade-off is extra latency.

I’m experimenting with letting the agent embed a suggested retry_after_seconds key in its error payload so the supervisor can make smarter back-off decisions. Has anyone here tried something similar or gone full-blown exponential back-off inside the agent itself?

Excited to learn how others are keeping hybrid systems resilient.