# What to Ask Your Developer (or Coding Agent) About Tool Calling > Tool calling is where your agent stops describing and starts acting — sending the email, updating the record, moving the money. Here's what to ask before you approve that, and which answers should worry you. **Published:** 2026-08-20 **Author:** Frameworkr Team **Category:** AI Agents **Tags:** tool-calling, ai-agents, hiring-a-developer, agent-design, human-in-the-loop, blueprint **Canonical:** https://www.frameworkr.ai/blog/what-to-ask-your-developer-about-tool-calling --- A developer or a coding agent tells you the agent needs "tool calling" before it can actually do anything — book the appointment, send the invoice, update the record. You say yes, because saying no isn't really on the table. But tool calling is also where an agent stops talking and starts acting, and that's not a detail to wave through without a few questions. ## Tool calling is the moment your agent stops describing and starts doing Everything before tool calling is talk. The agent reads a message, reasons about it, drafts a reply — and none of that touches anything real. [Tool calling](/glossary/tool-use) is the wire between that reasoning and your actual systems: your calendar, your CRM, your invoicing tool, your inbox. When a developer says they're "setting up tool calling," they mean they're deciding which of those systems the agent is allowed to reach, and what it's allowed to do once it's there. This is also where the risk changes shape. A bad reply from an agent that can only talk is embarrassing. A bad reply from an agent that can also *act* is a refund that shouldn't have gone out, a slot that got double-booked, an email that went to the wrong list. You don't need to understand how tool calling is built. You need to know what it's been given permission to do — because that part is yours to decide, not your builder's. ## What a developer means when they say "I'll add tool calling" Underneath the phrase is a short list of jobs, whether the one doing them is a human developer or a coding agent working from a blueprint: decide which outside systems the agent can reach, write a narrow function for each one thing it's allowed to do — send this email, not "access the inbox" — decide what happens when a call fails or comes back with something unexpected, and keep a record of every call so there's a trail if something goes wrong. None of that requires you to read code. All of it requires you to have an opinion about the boundaries, and that opinion has to exist before the first tool call ships, not after something goes sideways. ## The questions worth asking before you approve the build You don't need the technical vocabulary to ask these. You need the answers. ### Which tools can it call without asking you first? **Red flag:** "whatever it needs to get the job done." That's not a boundary, it's the absence of one. A good answer names the tools individually — send-a-reminder, check-a-calendar, look-up-an-order — and treats anything not on that list as something the agent can't touch. ### What happens when a call fails? An API times out, a record doesn't exist, a service is down. **Red flag:** "it'll retry" with nothing after that. A good answer includes what the agent tells the customer when it can't complete the action, and what it tells you. ### Can you show me a log of every call it made? If a customer disputes what happened, you need to know whether the agent sent the message, and what it sent. **Red flag:** "we can add logging later." Later is after the dispute, not before it. ### Which of these actions are reversible, and which aren't? Reading a record and sending a refund are not the same kind of action, even though both are "tool calls." **Red flag:** a build that treats every action the same way, with no distinction between looking something up and changing something real. ### Where does a [human have to approve](/glossary/human-in-the-loop) before it happens? Every agent with tool calling needs at least one category of action that never fires without you seeing it first. **Red flag:** "it's accurate enough that it doesn't need one." Accuracy and consequence are different axes — an agent can be right 98% of the time and still need a human on the 2% that would hurt if it's wrong. ## Where this goes wrong when nobody asked Say a booking agent gets tool calling wired up against your payments platform, and the fastest way to close the ticket is to let it issue refunds directly. Nobody asked whether refunds should be on the list of things it can do without you. Three weeks in, a customer disputes a charge in a way that reads, to the agent, like a legitimate complaint — and it refunds a job you'd have fought. Nothing broke. No error fired. The agent did exactly what it was built to do; the boundary was just drawn in the wrong place, and nobody drew it on purpose. ## The decision that's still yours None of this depends on which framework your developer picks, or whether the "developer" is a person or a coding agent working from a blueprint. Every framework covered in Frameworkr's [agent architecture guide](/blog/what-is-an-ai-agent-architecture) implements tool calling as the same wire between reasoning and action — the specifics of how differ, the question of what it's allowed to touch doesn't. [Guardrails](/glossary/guardrails) are how a builder enforces the boundary once you've named it. Naming it in the first place is yours, for the same reason the rest of the architecture is yours: your builder can explain how a permission model works. Only you know whether your business would survive an agent that got one boundary wrong. Answering the five questions above takes less time than the meeting where you'd otherwise just nod along. [Map the tool-call boundaries](/blueprint) — what it can touch, what it can't, what needs you first — before you hand this to anyone to build. --- _Published by Frameworkr — https://www.frameworkr.ai_