Tools & Function-Calling

A tool, from the agent's point of view, is a described capability it can invoke. The scaffolding presents the model with a menu: here is a tool called web_search that takes a query and returns results; here is read_file that takes a path and returns the contents; here is run_calculation, query_database, send_email, update_schedule, and so on. Each comes with a short specification - its name, what it does, what inputs it needs, what it gives back. Crucially, the model does not run these tools and cannot; it can only do the one thing it ever does, which is produce text. Function-calling is the convention that lets a *piece of text* stand for a request to run a tool.

Here is the whole trick. The model, when it decides a tool would help, emits text in a strict, agreed structure - conceptually, call web_search with query = "mid-size civic library precedents". In practice this is a tightly formatted object (often JSON) that names the tool and supplies the inputs the tool's specification requires. The scaffolding is not merely displaying the model's output; it is *parsing* it, watching for exactly this structured request. When it sees a valid one, it stops, extracts the tool name and inputs, and actually runs the corresponding real function - hits the search API, opens the file, performs the sum. Whatever that function returns is then formatted as text and inserted back into the context the model sees on its next turn. The model reads the result as if it had been told the answer, and carries on. On the model's side it was all text in, text out; in the world, a real action occurred and a real result came back.

Two things about this are worth fixing in mind. First, the model chooses *whether and which* tool to use, and with what inputs - that decision is reasoning, and it can be wrong (the wrong tool, a bad query, a mistaken argument). Second, the *format* has to be exact, because deterministic code is parsing it; modern models are trained specifically to emit well-formed tool calls, and the harness usually validates them, but malformed or hallucinated calls are a real failure mode. The elegance is that a fuzzy, probabilistic text-predictor and rigid, literal software meet at a precise, structured handshake - and that handshake is the joint on which every acting agent turns.

The specific tools change constantly, but they fall into durable classes, and it is worth knowing them because each unlocks a different kind of design work. Information tools let an agent bring in knowledge it does not carry: web search, document retrieval, database and catalogue queries, reading a PDF of a code or a product sheet. These are what let an agent research precedents, pull current product data, or ground its answer in *your* files rather than its training - the foundation of retrieval, which the next lesson covers. File and document tools let it read and write real artefacts: open a schedule, edit a spreadsheet, draft a specification document, produce a report. This is where a great deal of the tedious production work of a practice becomes delegable. Software and API tools let it operate other programs: query or modify a BIM model, drive a rendering engine, call a structural or energy analysis, place an order through a supplier's API, post to a project-management system. And computation tools - a calculator, a code interpreter, a unit converter - let it compute exactly instead of estimating in fluent prose, which matters enormously because a language model doing arithmetic in its head is one of the least reliable things it does.

That last point deserves emphasis for designers, who deal in numbers that matter. Ask a raw model to total a bill of quantities or convert areas and it will produce a confident figure that is often subtly wrong, because it is predicting plausible digits, not calculating. Give it a calculator tool and instruct it to use it, and the arithmetic becomes exact - the model decides *what* to compute and the tool computes it correctly. This is the general pattern and the reason tools matter so much: they let each part of the job be done by the thing best suited to it. The model supplies judgement, language and the decision of what to do; the tool supplies a correct, real-world action. Reasoning where reasoning belongs, computation where computation belongs, retrieval where facts belong.

A fast-moving development worth naming as a class, not a product, is the move toward standard protocols for connecting tools to agents - an emerging effort (the Model Context Protocol is one prominent example as of 2026) to let any tool or data source expose itself to any agent through a common interface, rather than every tool being wired in by hand. If it matures, it means an agent could be given access to your practice's document store, your BIM software, your suppliers, through standard connectors. The principle to carry, whatever wins: an agent is only as capable as the tools it can reach, and deciding which tools it may reach - and may not - is a design and governance decision you own.

Tools are not a nice add-on; they are the line between an assistant and an agent, and it is worth being precise about why. Without tools, everything a model gives you is a *proposal expressed in words*: advice, a draft, an estimate, a description of what should be done. Useful, but inert - you still have to do the doing. With tools, the model's decisions become *actions with real results*: the search is run and the actual sources come back; the file is genuinely edited; the calculation is truly performed; the order is actually placed. This is what closes the gap between talking about the work and completing it, and it is why the arrival of reliable function-calling, more than any single jump in model cleverness, is what made agents practical. An agent is, almost by definition, a model that has been given tools and a loop.

But the very thing that makes tools powerful - real actions on the real world - is what raises the stakes sharply, and this is where your professional discipline re-enters. A talking model can only be wrong on paper; a tool-using agent can be wrong in *effect*. If it can write files, it can overwrite the wrong one; if it can send email, it can send the wrong message to a client; if it can hit a supplier API, it can place a real order; if it can modify a model, it can change something you did not intend. The blast radius of a mistake grows with every capability you grant. This is not an argument against tools - it is an argument for granting them deliberately. Which tools an agent may use, on which data, with what limits, and where it must stop and ask a human before an irreversible or costly action - these are the real safety controls, and they live in the scaffolding you shape, not in the model's good intentions.

So the professional posture toward tools is: enable generously for the reversible, gather-and-draft work where a mistake costs only a review; gate carefully anything that spends money, sends an external communication, changes a record of authority, or touches safety or compliance, so a human confirms before it happens. And verify tool *outputs* as rigorously as any other agent output - a search can return a bad source, a retrieval can pull an outdated document, a tool can return an error the model then reasons over as if it were fact. Tools let the agent act; they do not make its actions correct or safe. That judgement, and the accountability for what the agent does under your direction, remain yours as the architect of record.

Knowing how function-calling works turns into practical craft in a few concrete habits, and they are habits any designer can build without writing a line of code. The first is giving the agent the right tools for the job - and no more. An agent with too few tools cannot do the work and will either give up or, worse, fabricate a result it could have looked up; an agent with too many, or with dangerous ones it does not need, is a larger risk surface for no benefit. Match the toolset to the task: a research agent needs search and document reading; a documentation agent needs file read/write and a calculator; almost nothing needs the ability to send external email or spend money unless that is precisely its supervised purpose. Right-sizing the toolset is a real design decision and one of your main levers of control.

The second habit is watching how the agent uses tools, not just what it concludes. Because an agent's final answer rests on a chain of tool calls, the answer can be undermined anywhere along that chain - a search that returned nothing useful, a file it read the wrong version of, a calculation it chose not to run and estimated instead. Good agentic tools show you the trace: which tools were called, with what inputs, and what came back. Reading that trace is how you catch the difference between an agent that grounded its conclusion in real, correct actions and one that took a shortcut and dressed the guess in confidence. When something matters, do not just accept the conclusion - inspect the tool calls that produced it.

The third habit is placing the human checkpoint at the point of consequence. The goal is not to approve every trivial step - that would destroy the productivity the agent exists to give you - but to insist on a human decision precisely where an action becomes irreversible, external, expensive, or bound to a professional commitment. Let the agent search, read, draft and compute freely; make it pause before it sends, spends, submits, or overwrites something of record. Set that line thoughtfully and you get the best of both: the agent does the volume of real work through its tools, and you retain the decisions that carry weight. This is the whole game in miniature - delegate the doing, keep the judgement, and situate your verification where the stakes actually are.