Tools

In the previous section, we covered the agentic loop and the system prompt — the instructions side of agent design. Now we look at the other side: tools, which give the agent the ability to act.

What follows is an opinionated take on how to think about tools — but it is an extremely flexible way to create really powerful agents.

What is a tool?

A tool is a specific action that the agent can choose to perform. During the agentic loop, the LLM decides which tool to call and what parameters to pass. The system executes the tool and returns the result back into the context, where the agent can see it on the next turn and decide what to do next.

You should not need to build all the tools yourself. A good agent platform provides the foundational tools out of the box. What matters is understanding what they are, because they determine what your agent is capable of.

There are really only a small number of core tool categories that make an agent immensely capable.

File access

The first and most fundamental capability is file access. The agent can search, read, edit, and write files within the directories it has access to.

This may sound simple, but it is extraordinarily powerful. It means the agent can work with your notes, documents, configuration files, data files — anything stored as text. The current standard for agent-friendly documents is Markdown, and modern agent platforms have excellent tools for searching through files and making precise edits.

With file access alone, your agent can already maintain its own notes, update documents on your behalf, and work with structured information across many files.

Command execution

The second core capability is command execution — the ability to run command line commands. This is where the agent’s power expands dramatically.

With command execution, the agent can do most of what a computer can do. A few examples of what this unlocks:

• Access APIs — The agent can use tools like curl to call the APIs of services you use. If a service has a well-documented API, the agent can interact with it. Think task managers like Todoist, code platforms like GitHub, or communication tools.
• Use CLI tools — Many services provide command line interfaces. By installing these tools in the agent’s environment and providing the right credentials, the agent gains direct access to those systems.
• Write and run code — The agent can write scripts and execute them, enabling it to process data, automate workflows, or solve problems that require computation.

This is also where secrets come in. To access your systems, the agent needs credentials — API keys, tokens, passwords. These are passed to the agent as secrets, giving it authenticated access to the services you use. Combined with command execution, secrets are what connect your agent to your world.

Isolation matters

Command execution is extremely powerful — but also potentially dangerous. An agent that can run arbitrary commands can also cause harm if its environment is not properly contained. It is vitally important that the agent runs in a fully isolated environment, so that even if something goes wrong, the blast radius is limited. Your agent platform should handle this for you.

MCP servers

For the remaining systems that do not have a convenient API or CLI, there is a third option: MCP (Model Context Protocol) servers. These are purpose-built interfaces designed specifically for agents to interact with a service.

An MCP server exposes a set of tools that the agent can call, just like any other tool. The difference is that someone — the service provider or the community — has packaged the integration specifically for agent use.

The number of services offering MCP servers is growing rapidly. But MCP is really the cherry on top — file access and command execution already cover the vast majority of what you need.

You need less than you think

Here is the key insight: you do not need to set up a lot of tools.

File access and command execution are foundational — your agent platform should provide them out of the box. With just these two capabilities and your credentials, your agent can already interact with most of the systems you use and work with most of your files.

You do not need to build custom integrations for every service. You do not need to configure dozens of tools. The agent itself can figure out how to use an API, install a CLI tool, or write a script to get the job done. Your role is to provide the right access and the right instructions — not to wire up every connection by hand.

MCP servers and specialized CLI tools are useful additions, but the foundation is already there.

Example: a task management agent

Let’s extend the executive assistant from the previous section into a task management agent connected to Todoist.

What we add:

• A secret containing the Todoist API key
• Instructions (in the system prompt) telling the agent it can manage tasks via the Todoist API

Now the user sends a message:

“What are my tasks for today?”

The agent uses command execution to call the Todoist API, retrieves today’s tasks, and presents them in a clear summary.

The user follows up:

“Mark the first one as done.”

The agent makes another API call to complete the task, confirms it is done, and shows the updated list.

Two turns, two API calls, real work done — all powered by command execution and a single secret. No custom tool was built. No integration was configured. The agent figured out the API calls on its own, guided by its instructions.

This is what tools enable. Now that you have an agent with instructions and tools, the next question is: where do you actually talk to it?

Next: Bots →