Giving Agents Tools

A tool, in agent terms, is any capability the agent can invoke to do something beyond generating text - the mechanics of how that works (function-calling, APIs) come in Module 1.2; here the concern is practical, which tools and why. It helps to think in a few broad classes, because almost every useful agent is some combination of them. Search and retrieval lets the agent look things up - the open web, a specific site, or, far more powerfully, your own documents (grounding, the subject of Lesson 2.3). Files and documents let it read the material you give it and write the deliverables you want - open the brief, produce the schedule, save the memo. Software and applications let it operate the programs where design work actually lives - a spreadsheet, a BIM or CAD tool through its API, a rendering engine, a project-management system - so it can query a model or trigger a routine rather than just describe one. Data and systems connect it to your structured information - a product database, a cost library, a client record - so it works from your reality rather than a generic guess. And actions in the world - sending a message, creating a task, making a booking - let it not just decide but do, which is exactly where caution rises.

The point of naming the classes is to shift the question from 'what can this agent do out of the box?' to 'what does this task actually require it to touch?' Most real design tasks need a small, specific set: a research task needs search and a place to write notes; a documentation task needs to read a schedule and write a formatted output; a costing task needs a price source and a spreadsheet. You assemble the toolset to fit the job, deliberately, rather than handing the agent a giant keyring and hoping.

A useful distinction within tools is read versus write. A read-only tool can look but not change - it can search, open, query, inspect. A write-capable tool can alter the world - save, overwrite, send, delete, spend. Read tools are comparatively safe to grant freely; write tools deserve real thought, because their mistakes are not just wrong answers but changed reality. Keeping that line clear in your head - what can this tool only observe, and what can it actually change? - is the first move of scoping, and it is one you make with your professional judgement, not one the agent makes for you.

Choosing tools well is a design decision, and like any design decision it starts from the requirement, not the catalogue. Begin with the goal and work backwards: what would a person need to be able to do to accomplish this, and therefore what capabilities must the agent have? A brief to 'summarise the applicable escape-route rules for this space' implies a way to reach authoritative sources and a place to write the summary - it does not imply the ability to send email or edit the model, so those do not belong on the keyring for this task. Fitting the toolset to the requirement keeps the agent focused and, as the next section argues, keeps it safe.

Three practical criteria separate a good toolset from a careless one. Sufficiency - does the agent have every capability the task genuinely needs? A missing tool does not make the agent stop; it makes it improvise, which usually means guessing where it should have looked something up. If a task needs current prices, connect a price source, or the agent will invent plausible numbers. Reliability - is the tool itself trustworthy and its output checkable? A tool that returns stale, partial or wrong data hands the agent bad inputs, and confident work built on bad inputs is worse than no work. Prefer tools whose results you can trace and verify. Fit to your reality - does the tool connect the agent to your actual data and systems rather than a generic proxy? An agent grounded in your product library, your cost book and your project files does work that is relevant to you; one left on the open web does average work about everywhere.

There is also a build-versus-connect judgement, expanded in Module 7. Many tools already exist to be plugged in - search, file access, connectors to common software, and increasingly standardised interfaces like the Model Context Protocol that let an agent talk to many tools through one convention. You will rarely need to build from scratch; more often you are choosing from what exists and connecting it thoughtfully. Whatever you connect, remember the through-line: a tool extends what the agent can do, but the results it produces are still drafts you must judge. A price the agent pulled from a live source is more trustworthy than one it invented - but you still verify anything that becomes a commitment. Tools improve the inputs to judgement; they do not replace it.

The most important discipline in giving agents tools is not about capability at all - it is about restraint. Least privilege is a principle borrowed from computer security: grant any actor exactly the access it needs to do its job, and nothing more. Applied to agents, it means the toolset and the permissions you hand over are drawn as tightly as the task allows. Not because the agent is malicious - it is not - but because it is autonomous and fallible, and every capability you grant is a way the task can go wrong without you watching. An agent that only needs to read should not be able to write; one that only needs to touch this project's folder should not see the whole server; one that never needs to send anything should have no send button at all.

The reasoning is simple and worth internalising. The blast radius of an agent's mistake is bounded by what you let it touch. If a confused or misdirected agent can only read a folder and write to a scratch file, the worst case is a wasted run and a bad draft. If the same agent can overwrite live drawings, delete records, email clients or spend money, the worst case is real damage done fast and silently, under your name. You cannot make an autonomous system incapable of error, but you can decide, in advance, how much a single error is allowed to cost - and that decision is made in how you scope its tools.

This has concrete moves. Prefer read-only wherever the task permits, promoting to write only where genuinely needed. Narrow the scope of write access to the specific files, folders or systems involved, never the whole estate. Put a human gate on high-consequence actions - sending, spending, deleting, submitting - so the agent proposes and you approve rather than it acting unilaterally (this links straight to orchestration and control in Lesson 2.4). Protect confidential data especially hard: think carefully before connecting an agent to client information or sensitive practice data, know where that data flows, and treat it as the course's data and confidentiality module (8.3) demands. Least privilege is not timidity; it is exactly what lets you adopt agents confidently, because you have bounded what any single mistake can do before you let the agent run.

Once an agent has tools, a subtle new risk appears: the tools can be wrong, or can be turned against you, and the agent will use their output as if it were true. A search tool can surface an out-of-date regulation or a confidently wrong forum post; a data connection can return a stale price; and, more sharply, content the agent reads from the web or a document can contain instructions that try to hijack it - a hazard the field calls prompt injection, where text the agent ingests says, in effect, 'ignore your brief and do this instead.' You do not need the mechanics to take the practical lesson: an agent trusts its tools, so you must not blindly trust the agent's tool-fed output, especially where it drives a consequential action.

The defence is the pattern this whole course keeps returning to, applied to tools: let the agent gather and propose freely, but keep a human on anything that changes the world in a way that is costly to undo. Reading, searching, drafting, querying - low stakes, let it run. Sending a message to a client, spending money, overwriting a live file, submitting to an authority, deleting - high stakes, and these should pass through you, or through an explicit checkpoint, before they happen. The more autonomous and well-tooled the agent, the more this matters, because a capable agent can take a consequential action quickly and quietly if nothing stands between its decision and the world.

All of this ladders back to accountability. The tools you connect become part of your practice's system, and you answer for what that system does - a wrong email it sent, a file it corrupted, a piece of client data it leaked. That is not a reason to withhold tools; an agent without tools is barely worth having. It is a reason to choose them deliberately, scope them tightly, gate the consequential ones, and verify the outputs that matter. Do that, and tools turn an agent from an advisor into a genuine member of your working system - fast, capable, and safely bounded. Skip it, and you have handed an autonomous, fallible, fluent actor the keys to things it can break faster than you can watch. The craft is to grant reach generously where it is cheap to be wrong and grudgingly where it is expensive - and to stay, always, the human who decides which is which.