“Let Kai answer” hands over an open conversation. “Give Kai a task” is narrower: you write instructions for one specific job, and the step does that rather than answering whatever comes up.
The step has two parts. The instructions say what to do, and the tools decide what it can reach while doing it. Searching your knowledge base is available from the start; anything else comes from the tools you've built for your agents.
Write the instructions as a job with a finishing line — what to produce, and what to do when it can't. “Summarise the customer's problem in two sentences for the engineering team” works; “help the customer” doesn't tell it when it's done.
Deciding something the flow then branches on — whether a message is a complaint, which product it concerns.
Producing a summary for your team before a conversation reaches them.
One lookup with a tool, where a whole agent would be overkill.
The two overlap, and the honest distinction isn't capability but ownership.
A task belongs to the workflow step it sits in. It's quick to add, and it exists in exactly one place — which is fine until you want the same behaviour in a second flow and end up maintaining two copies of the instructions.
An agent is a thing in its own right: reusable, with its own tools, its own triggers, its own cost ceiling and a record of every run. That last part matters more than it sounds when something goes wrong.
Give the step only the tools its job requires. A task with access to everything will occasionally use something unexpected, and inside a live customer conversation that's harder to notice than in an agent run you can review afterwards.
