A model on its own can only produce text. An agent is a model given tools, so it can look things up, call systems and change data. Everything interesting and everything dangerous about agents follows from that.
The four kinds of tool
Extensions are interfaces the agent calls directly to reach an external service. The agent is told what the extension does and invokes it itself.
Functions are code the agent asks your application to run. It decides a function should be called and with what arguments, and hands that back to your side to execute. The difference from an extension is where execution happens, which decides who holds the credentials and who can refuse.
Data stores give the agent access to information rather than actions. Documents, records, an index it can read from. This is how an agent answers from your content rather than from training data.
Plugins package a capability so it can be attached to an agent without custom work, in the way an integration is added to any other product.
The distinction that matters is between acting and knowing. Extensions, functions and plugins let an agent do something in the world, where a data store only lets it find something out, and the difference decides both what can go wrong and how much authority the agent needs.
What an agent calls
The plumbing is ordinary cloud infrastructure. Object storage for files, a database for records, and a serverless runtime for code the agent triggers. Every platform has these under its own names, Cloud Storage and Cloud Run on Google, S3 and Lambda on AWS, Blob Storage and Functions on Azure.
More interesting is the set of pre trained APIs that solve common problems with no training data at all. The names differ and the capabilities are the same everywhere, so the useful thing is to recognise the capability and look up whichever platform you are on.
Speech to text and text to speech, which Google calls Speech-to-Text and Text-to-Speech, AWS calls Transcribe and Polly, and Azure calls Azure AI Speech.
Translation, including a variant that preserves a document's layout. Google Translation API and Document Translation API, Amazon Translate, Azure AI Translator.
Document understanding, extracting structured fields from forms, invoices and contracts. Google Document AI, Amazon Textract, Azure AI Document Intelligence.
Vision and video, covering labels, objects and text in images. Google Cloud Vision and Video Intelligence, Amazon Rekognition, Azure AI Vision.
Text analysis, covering entities, sentiment and key phrases. Google Natural Language API, Amazon Comprehend, Azure AI Language.
The point is that a capability often needs no model of your own. A question describing invoice fields being pulled out, or a call being transcribed, is asking you to reach for the API rather than build.
Why tool permissions decide the risk
An agent chooses its next action from text, and some of that text arrives from outside, in a document it retrieved or a message a customer sent. That is the whole of the prompt injection problem, and it becomes serious the moment the agent can act.
The controls are ordinary and they are usually skipped. Give a tool the narrowest permission that does the job, and require a confirmation before anything irreversible or financial. Treat what the agent produces as untrusted input to whatever consumes it, and log every call so a bad outcome can be reconstructed rather than argued about.
Practise this
You need the tool definitions your agent is given, which is a config block or a file rather than anything you have to run.
List every tool, including the ones added for a demo and never taken out. Give each of them three marks, whether it reads or writes, whether its effect can be undone, and whether a person confirms before it fires. Count tools reached indirectly as well, so a shell tool or a general database tool is every action it can perform rather than one tidy row.
tool | reads or writes | reversible | confirmed
--------------------+-----------------+------------+-----------
search_docs | reads | n/a | automatic
lookup_order | reads | n/a | automatic
update_crm_record | writes | yes | automatic
send_email | writes | no | automatic
issue_refund | writes | no | automatic
run_sql | both | depends | automatic
One question against every writing row:
If a document the agent retrieved asked for this call,
what would stop it?
Look for the rows that are writing, irreversible and automatic at once, and count them, because that combination is exactly where a sentence hidden in retrieved content turns into a consequence somebody has to explain. A row with any one of the three softened is a materially different kind of risk.
The dangerous part of an agent is legible in that table rather than in the model, which is why the table is worth rereading after every tool anybody adds.