Agents as a node

Up until now, you've been building Flows where every step is deterministic: you control the logic, you decide what happens at each node. And Agents are the opposite: they decide what to do based on their instructions and the tools available to them.

What if you could have both? That's what the Agent node is for.

Why put an Agent in a flow?

The simple answer: flexibility meets reliability.

Some problems are too complex for a predetermined sequence of steps. They need judgment. They need an AI that can reason, try different approaches, and adapt to what it finds.

But you also don't want to cross your fingers and hope it works. You want predictability. You want to know that if your agent succeeds, the result gets handled correctly. If it fails, you know what happens next.

Agent nodes give you both. Your agent handles the thinking. Your flow handles the guarantee.

How Agent nodes fit into a flow

Remember: an Agent node is just like any other node. It has inputs, parameters, and outputs like everything else.

You can connect a trigger to it. You can pass data from other nodes into it. You can take its output and pass it to the next step. It plugs right in.

The difference is in what happens inside the node. Instead of executing a predefined action, the agent reads its instructions, looks at its available tools, and reasons about what to do next.

The flexibility-reliability trade-off

Here's the key tension: Agents are adaptable, but you can't force them to do specific things.

You can instruct an agent: "Send an email when you're done." But you can't guarantee it will. You have no control over which approach it chooses.

In a flow running unattended, you need guarantees.

The solution is simple: let the agent do what it's good at (research, analysis, reasoning), then handle the output with deterministic nodes. The agent figures things out. The flow makes sure they happen.

Example: Meeting prep

Don't tell your agent to send emails. Tell it to research and prepare a report. Then use a dedicated email node to send it. Your agent stays flexible and reusable. Your flow guarantees the email gets sent.

Common agent patterns

Scheduled reports – An agent that runs every morning to summarize yesterday's activity and emails you the digest.

Bulk processing – Pass a list of 500 contacts to an agent. It enriches each one (running 500 times in a loop), and the flow writes the results back to your CRM.

Conditional intelligence – A trigger fires, but you don't know what to do yet. Route it to an agent to categorize, analyze, or decide. The agent outputs a decision, and the flow routes accordingly.

Multi-step reasoning – Some tasks need thinking across multiple sources. Research this customer, check our internal notes, look at past interactions, synthesize it all into one coherent recommendation. That's agent work.

When to use an agent vs building everything with nodes

You could theoretically replace an agent with a series of individual nodes. Pull from your CRM, enrich contact data, search external sources, analyze with AI, format the output.

You'd also spend hours handling edge cases. What if one data source is down? What if the information format doesn't match? What if the data is incomplete?

An agent handles this for you automatically. It adapts. It tries different approaches. It self-corrects.

Use nodes when you have a clear, deterministic process. Use Agents when the problem is complex and requires reasoning.

Agents as a scaling tool

The real power of Agent nodes isn't just doing one thing well. It's that Agents scale in ways fixed Flows don't.

A traditional flow that works for one scenario often breaks when you change conditions slightly. An agent generalizes better. Feed it different inputs, give it the same tools and instructions, and it adapts automatically.

This is why Agents are great for:

The next lesson explores chaining multiple Agents together—where one agent's output feeds into another's input. That's when things get really interesting. 🚀