A product-management agent can draft a roadmap recommendation, but it cannot check current customer feedback, update the roadmap, or email a stakeholder through language generation alone. A tool gives the agent a way to reach beyond the model: it can retrieve information, run an operation, or change an external system. Tools are commonly exposed as functions or APIs that a language model can select and call. section 9.1 section 9.1.3
Choose tools for the job the agent must perform, and distinguish reading from acting:
- Retrieve information from sources such as the web or a database so the agent can work with relevant evidence. section 9.1 section 9.1.3
- Analyze data with a specialized capability, such as a calculator or segmentation model, when the language model cannot reliably handle the work itself. section 9.1.1
- Write to an external system, such as updating a roadmap or sending an email. Write access increases usefulness but also raises the consequences of mistakes. section 9.1.1 section 9.1.4
Keep the initial tool set lean. The agent must identify the right tool from its description, and that choice can fail; specific descriptions improve its chances. More numerous or complex tools create more opportunities for error, so test third-party tools for quality, reliability, and safety before relying on them. A practical starting point is a couple of tools, expanding as the task and evidence justify it. For a larger set, consider specialized agents rather than giving one agent every capability. section 9.1.4 section 9.1.3 section 9.5
Tool access is one part of an agent, not a guarantee of dependable automation. Planning and memory may help with multistep work, while human review remains important when confidence is low or a wrong action could have serious consequences. section 9.2 section 9.5
