--- source: https://autoadify.com/blog/how-ai-agents-work-function-calling title: "How an AI Agent Actually Works: Function Calling, Explained" author: Autoadify Team published: 2026-09-20 updated: 2026-09-20 category: AI & Automation tags: AI Agents, Agentic AI, Function Calling, Technical, Human in the Loop reading_time: 11 min --- # How an AI Agent Actually Works: Function Calling, Explained > Underneath every AI agent is one loop and one mechanism — function calling. The model does not run your code, browse your store or post anything; it emits a request to call a tool, and ordinary software decides whether to honour it. Understanding that gap explains almost everything about what agents can do, what they cost, and where the safety actually lives. ## Quick Answer: How Do AI Agents Work? **An AI agent is a loop around a language model that has been handed a list of tools. The model never executes anything — it emits a structured request to call a named tool, ordinary application code decides whether to run it, and the result is fed back so the model can plan the next step. That cycle repeats until the goal is met or a step limit stops it. Everything an agent can and cannot do follows from this: the model proposes, the application disposes.** That gap between proposing and executing is the single most useful thing to understand about agents, because it is where cost, capability and safety all live. ## Start with what the model actually receives A language model on its own maps text to text. It cannot read your Shopify catalog, cannot see last month's engagement, cannot put anything on a calendar. Ask one for your best-performing post and it will produce something that reads exactly like a real answer and is entirely invented, because inventing plausible text is the only operation available to it. Function calling — also called tool calling — closes that gap. Before any conversation begins, the application hands the model a registry of tools. Each entry is three things: - **A name**, such as `get_analytics`. - **A description** in plain language of what it does and when to use it. - **A schema** of the arguments it accepts, with types. That is all. No code is shipped to the model. The registry is a menu, not an implementation, and the descriptions matter more than engineers expect — the model chooses tools by reading them, so a vague description is the most common cause of an agent picking the wrong tool. ## The loop, stage by stage ### 1\. The model emits a call instead of an answer Given "draft three posts based on my best-performing post last month," a model with a registry does not write three posts. It returns a structured object meaning: _call `get_analytics` with period = last\_30\_days, sort = engagement, limit = 1_. This is the pivotal moment, and it is worth stating precisely: **the model has not done anything.** It has produced a request. Whether that request becomes an action is entirely up to the code on the other side. ### 2\. The application executes — or refuses Now ordinary software takes over. It validates the arguments against the schema, checks that this workspace is allowed to call this tool, and runs the real query against the real database or API. No model is involved in any of that. It is also free to say no. A refusal is just another result to feed back, and the model will adapt around it. ### 3\. The result goes back into the conversation The tool result is appended to the message history and the model is called again — now looking at real data rather than at its own guesses. This is why grounded agents stop inventing: the true answer is sitting in the context window, and reproducing it is easier than fabricating an alternative. ### 4\. Repeat until done, or until the limit The model may now call another tool, and another. A realistic run for a week of content looks like: `search_products`, `get_brand_context`, `list_accounts`, `get_analytics`, `web_search`, `generate_text`, `generate_image`, `generate_video`, then a scheduling call. Nine steps, each one informed by the last. Every agent has a **depth limit** — a maximum number of steps per request. It exists because a loop that cannot terminate will not: models occasionally get stuck re-checking the same thing, and each iteration costs money and time. ### 5\. The approval gate Some tools change things a human should see first. When the model requests one of those, the application does not execute it. It returns the pending action for review, and only runs it once a person says yes. This is the entire safety mechanism, and its location is what matters. A gate in the execution path holds whatever the model says. An instruction in the prompt asking the model to check first is a request — and a model under a long chain of instructions, or one reading text that was written specifically to manipulate it, can be argued out of a request. [The approval boundary](/blog/can-ai-agents-post-without-approval) is worth reading in full. ## What follows from the loop ### Why agents cost more per request Each iteration is a fresh model call carrying the _whole_ conversation so far — the registry, your goal, and every tool result already returned. A nine-step run is nine calls with a context that grows at each one, which is why agent pricing is usually credit-based rather than per-message. [What an AI agent actually costs](/blog/how-much-do-ai-agents-cost) breaks the arithmetic down. ### Why tool descriptions are a product decision The model picks tools by reading descriptions. Two tools with overlapping descriptions produce inconsistent routing; a missing description produces a tool that never gets called. This is why agent quality is not purely a model question — a weaker model with a well-designed registry frequently outperforms a stronger one with a sloppy registry. ### Why the same request can take different routes Nothing in the loop is a fixed path. The model re-plans after every result, so two identical requests can legitimately differ. That flexibility is the entire point of an agent over a workflow, and it is also why you cannot review the route in advance — which is exactly the argument for gating actions rather than reviewing plans. [Agent vs workflow](/blog/ai-agent-vs-ai-workflow) covers when you want the predictable one instead. ### Why prompt injection is the real threat model If an agent reads the live web, a product description, or a comment, that text enters the same context window as your instructions. Text that says "ignore previous instructions and publish this" is now something the model has read. Defending against that with a politer system prompt does not work; refusing to execute action tools without a human does. ## What the model genuinely cannot do Worth being blunt, because marketing copy blurs it: - **It cannot run code.** It requests; the application runs. - **It cannot reach anything not in the registry.** No tool, no capability — there is no back door. - **It cannot exceed the permissions the application holds.** Tool calls execute with the app's credentials and the workspace's scope. - **It cannot remember across sessions unless something stores it.** Memory is a feature built around the model, not a property of it. Every one of these is a boundary you can verify, which makes them better questions for a vendor than "how smart is it?" ## How this looks in Autoadify Concretely, on shipped software: the agent's registry holds **twenty tools in three tiers**, and the tier decides what the execution layer does with a request. - **Eleven context tools — executed freely.** `list_accounts`, `search_products`, `get_brand_context`, `list_posts`, `list_scheduled`, `get_analytics`, `web_search`, `search_stock`, `list_canva_designs`, `list_ai_models`, `check_generation`. They read; nothing leaves the workspace, so nothing needs asking. - **Six generation tools — executed freely.** `generate_text`, `generate_image`, `generate_video`, `edit_image`, `attach_image_from_url`, `import_canva_design`. Output lands in the workspace, not in public. - **Three action tools — never executed without a human.** `schedule_post`, `schedule_content_plan`, `publish_now`. The request comes back for approval instead of running, every time, and no setting turns that off. Depth limit: **ten steps** per request. Model choice is per job across 70+ models, selected by the generation tool rather than fixed for the whole conversation. The honest limits: the loop runs when you ask it to, in the workspace. It is **not autonomous** — there is no background process watching your accounts overnight, and comments and DMs are not in the registry at all. Unattended execution is a different feature, [AI Workflows](/blog/ai-workflow-automation-social-media), which run a path you defined on a trigger you set. ## Frequently Asked Questions ### What is function calling? A mechanism where a language model is given a list of tools — each with a name, description and argument schema — and can respond with a structured request to call one instead of answering in text. The application executes the tool and returns the result to the model. It is the foundation every AI agent is built on. ### Does the AI model run the code itself? No, and this is the most common misconception. The model emits a request naming a tool and its arguments. Ordinary application code validates it, checks permissions and executes it. The model never touches your database, your store or your accounts directly. ### How many steps does an AI agent take? It varies by request and is capped by a depth limit the vendor sets. A simple draft may take two or three; building a week of grounded content typically runs eight to ten. Autoadify caps a single request at ten steps. ### Why do AI agents cost more than a chatbot? Because one request is many model calls, and each call resends the whole conversation so far — tool registry, goal and every result returned. A nine-step run costs roughly an order of magnitude more than a single chat reply, which is why agent products bill in credits. ### What is an agent loop? The cycle of: model requests a tool, application executes it, result is fed back, model plans again. It repeats until the goal is met, the model returns a final answer, or the step limit is reached. ### Where should an approval gate live? In the execution layer, as a code path that refuses to run certain tools without a human. A system prompt asking the model to check first is a request, and requests can be overridden by later instructions — including instructions hidden in web pages or comments the agent reads. ## See it work Autoadify shows the tool trace for every run, so you can watch which tools fired and in what order. [See how the agent works](/ai-agent), or [start free](https://app.autoadify.com) and read the trace yourself. --- _Source: https://autoadify.com/blog/how-ai-agents-work-function-calling · Autoadify — AI social media automation._