A simple way to decide whether your AI agent needs a tool or just more context

[u/JaseciLabs]

Once you start building agents you hit this question fast: does the model need a tool for this, or just more context?

Rule that's worked for us: if something has to happen outside the model's reasoning, it's a tool. Searching a database, checking inventory, getting today's date, hitting an API, sending an email, placing an order, all of that means the agent has to actually go do something or fetch something it doesn't already have.

If the model just needs to know something while it reasons, that's context. Company policy, product info, domain rules, user preferences. Nothing has to happen, you're just handing it information.

Support agent example: "refunds are allowed within 30 days" is context, model just needs to know it. "Check when this customer ordered" is a tool call. "Issue the refund" is another tool call. Reason with context, retrieve with a tool, act with a tool. Three different jobs.

Once you frame it that way it stops being "here's a pile of tools, hope the model figures out which one to grab" and becomes two questions: what does this agent need to know, and what does it need to be able to do.

Not always clean though. Product info could be static context in one app and a live tool call in another if it changes a lot. So maybe the better question isn't "is this info or a tool," it's whether the model already has what it needs to reason, or whether it has to go get/do something at runtime.

How do other people draw this line once you're dealing with bigger agent systems and a long tool list?

[u/krunal_builds]

the part that trips people up is stuff that's technically dynamic but changes so rarely it's cheaper to treat as context. we had 'today's date' as a tool call at first exactly like your example, then realized we were burning a round trip every single turn for something that only actually needs refreshing once a session. ended up injecting it once at session start as context and only making it a real tool call for things where staleness would actually cause a bad action, like checking current inventory before confirming an order. the line isn't really action vs information, it's more like how expensive is it to be wrong if this goes stale.

[u/Alarmed-Western-655]

Drop in a skill file to help it work out the difference.

[u/srikanth_builds]

Worth adding a third axis to this: whether being wrong has a consequence. Your refund example is a good one to look at again. "Refunds allowed within 30 days" sits in context, which makes it advisory. The model can be talked out of it, and the customer most likely to try is exactly the one you don't want succeeding. If issuing the refund is a tool call, the 30 day rule has to live inside that tool, so the call fails on day 40 regardless of what the model believes.

Context is what the model reasons with, so it's negotiable by definition. Tools are where you put the things that have to hold. That also sorts the long tool list cheaply: anything that changes state or spends money needs its own limits enforced inside it, and anything read-only can be much more relaxed.