AI Agent Node Won’t Pass Binary Data to HTTP Request Node

Questions
1

Hello everyone,

I’m stuck with a workflow problem and could really use some advice.

In n8n, the HTTP Request node can send binary data in the request body without issues. However, when I try to connect it to an AI Agent node, I can’t access any binary files from the previous steps in the HTTP Request node. Essentially, it seems that the AI Agent node doesn’t forward binary data at all.

Has anyone run into this before? Is there a way to make binary data available to the HTTP Request node after using an AI Agent node?

Any pointers, workarounds, or explanations would be hugely appreciated!

Thanks in advance!

2

This is actually expected behavior with the AI Agent node rather than a bug.

The AI Agent is designed to operate on text/JSON and often creates a new item as its output. When it does that, it does not automatically carry forward the binary property from upstream nodes. As a result, any binary data (files from HTTP Request, Read Binary File, etc.) appears to “disappear” after the agent, even though it worked fine before.

A few reliable ways to handle this:

1) Keep the binary on a parallel branch and merge later (recommended)
Let the node that produces the binary continue on one branch, and send only the text/metadata into the AI Agent on another branch. After the AI Agent, use a Merge node (usually “Combine by position”) to recombine the AI output with the original item that still contains the binary. This preserves the file without fighting the agent’s behavior.

2) Re-attach the binary after the AI Agent
If needed, you can explicitly copy the binary from an earlier node back onto the AI Agent’s output using a Code node. This works, but is a bit more manual.

3) Pass a reference instead of the file
If the agent is only making a decision, store the file somewhere (S3, Drive, local disk, etc.) and pass a file ID or URL through the agent. Download the binary again right before the HTTP Request that needs it. This is often cleaner for larger files.

4) Base64 encode (only for small files)
You can serialize the binary into Base64 so it travels as text, then decode later — but this gets heavy fast and isn’t ideal unless the files are small.

In short: the AI Agent doesn’t forward binary by design. The parallel-branch + merge pattern is usually the cleanest and most maintainable solution.

If you want, feel free to share the workflow JSON — happy to point out exactly where to merge and which mode to use.

1 Like
3

Thank you for your response; I understand it.
I would like to clarify my question a bit further. I am not referring to a node that runs after the AI agent, but rather to a tool used by the AI agent—specifically, the HTTP tool.

This HTTP tool does not seem to be able to receive binary files when it is invoked by the AI agent. However, the tool theoretically offers the option to specify a binary file as the payload for the request body.

This point is confusing to me. It appears as if the HTTP tool is capable of sending files as part of an HTTP request, but there is absolutely no way to pass a binary file into the tool in the first place.

Is this a limitation of n8n? Or would this perhaps even be worth a feature request?

1 Like
4

Thanks for clarifying — and yes, this is a real limitation rather than a misunderstanding on your side.

When the HTTP Request node is used as a tool inside an AI Agent, it’s not executed with the full workflow item. Instead, the agent invokes tools via a JSON-only argument payload, which means the tool has no access to upstream binary data. As a result, there’s currently no supported way for an agent to pass a binary file into the HTTP tool, even though the HTTP Request node itself supports binary payloads when used normally in a workflow.

This mismatch between capability and actual behavior is confusing, and you’re definitely not the only one to run into it. There are several community threads describing the same limitation:

So to answer the two core questions directly:

  • Is this a limitation of n8n?
    Yes — specifically of the current agent → tool contract, which is JSON/text-only.

  • Is it worth a feature request?
    I’d say yes. The UI implies that tools like HTTP Request can accept binary input, but there’s no mechanism for an agent to supply that binary today, which is misleading.

In practice, most people work around this by:

  • Storing the file somewhere and passing a reference (URL/path/id) through the agent, or

  • Keeping the agent purely decision-making and performing the actual binary HTTP request outside the agent with a normal HTTP Request node.

Bottom line: you’re not missing a configuration — binary data simply doesn’t cross the agent → tool boundary at the moment.

2 Likes
5

Hi Michael,

Thank you for the detailed clarification and for confirming the limitation. I appreciate you taking the time to explain how the agent-to-tool contract currently works and why binary data cannot be passed through.

That clears things up on my end. I agree the behavior can be a bit misleading given the HTTP Request node’s standalone capabilities, so a future enhancement in this area would definitely be valuable.

For now, I’ll proceed with a workaround and wait to see whether this becomes a supported feature in a future release.

Thanks again for your help.

1 Like