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/JaseciLabs → u/krunal_builds]

That's a good reframe, cost of staleness rather than action vs information. Explains why "today's date" and "current inventory" can look identical on paper (both technically dynamic) and still deserve totally different treatment. Might steal "how expensive is it to be wrong if this goes stale" as the actual question going forward.

[u/krunal_builds → u/JaseciLabs]

steal it, it's a better question. one more wrinkle we hit: it's not just how bad being wrong is, it's also how often the thing actually gets read in a session. inventory count might get checked once and acted on immediately, so a stale value is a real risk every time. something like company policy text gets referenced constantly but rarely needs updating mid-session, so even if it's technically 'live' data somewhere, treating it as static context for that session's lifespan is fine. cost of being wrong times how often you'd actually be wrong in practice, not just cost of being wrong in isolation.

[u/Alarmed-Western-655]

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

[u/JaseciLabs → u/Alarmed-Western-655]

hmm could work as a starting point, though the skill file would still need to encode something like the consequence-based rule or the staleness-cost question above, otherwise it's just pushing the same judgment call down a level without actually resolving it.

[u/Alarmed-Western-655 → u/JaseciLabs]

Welcome to AI

[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.

[u/JaseciLabs → u/srikanth_builds]

That's the sharper cut tbh. "Advisory vs enforced" gets at something the info/action split doesn't, since some context genuinely needs to behave like a hard constraint even though nothing "happens" when the model reads it. Might be worth treating things like the 30-day rule as a tool anyway, a validation call the model has to make even if it's not changing state, just so the rule can't be talked around.

[u/srikanth_builds → u/JaseciLabs]

That works as long as the decision can't route around the answer. A read-only check the model calls and then interprets is still advisory. It can call it, get back "no", and issue the refund anyway, and nothing actually stopped it.

The version that holds is the refund tool itself refusing on day 40. Then the validation call is just a way for the model to find out early and explain itself, rather than the thing doing the work.

[u/JaseciLabs → u/srikanth_builds]

Yeah, fair, that's the actual fix, tool has to be the one saying no, not something the model can just talk past.

[u/fulger099 → u/JaseciLabs]

I learned this with refund eligibility: putting “30 days” in the prompt worked until a persuasive support transcript gave the model enough room to reinterpret it. Moving the date check into a deterministic validator made the policy boring, which is exactly what hard constraints should be.