Your AI agent only knows what you paste into the chat, so every useful answer starts with copying text out of Slack, Jira, or HubSpot. Give it tool access, and it can look things up and make changes on its own. So what stops it from deleting something in a live system?
This guide shows you how to build an AI agent with tools in AgentSpot, one setup decision at a time. Along the way, you'll see how per-action permissions and the tool-call log keep you in charge of everything your agent touches.
Anything your agent does beyond the chat window counts as a tool: searching Confluence, sending a Slack message, creating a record, or reading a file. Without tools, an agent can only reason over the text you hand it. Think about forwarding a colleague a thread versus asking them to read the channel themselves: which one actually saves you time?
That second version is what tool access gives you. Once your agent can reach Slack, Jira, and HubSpot, it can check what's happening right now and act on it.
Want the longer case for why that matters? Read why AI agents need tools, or start with what an AI agent is if you're newer to agents.
So which apps can you actually plug in?
Which Apps Can Your AgentSpot Agent Use?
Your AgentSpot agent can use 15-plus enterprise app connectors out of the box, including Slack, Google Workspace, Atlassian, HubSpot, Zapier, Monday.com, Notion, Zendesk, Clay, Stripe, Asana, Gusto, and Wiz.
Each connector exposes specific actions; many of them write as well as read. Take Google Workspace: a single connector lets your agent read a doc, write to a spreadsheet, or build a deck.
Why does the read and write split matter so much? A read action fetches information for you, while a write action changes something inside a system you rely on every day. If you live in Jira or Confluence, look for the Atlassian connector.
Once you know which apps the job touches, connecting them happens in the same place you describe the agent.
You connect tools in the same builder where you describe the agent, and AgentSpot drafts the first pass for you. Here's the sequence:
Open your agent in the builder and describe the job in plain language.
Review the draft, which includes instructions, context, and a first pass of tools based on your description.
Open the Connectors panel and authenticate each app there, without leaving the conversation.
Pick only the apps the task touches; a deal-risk agent needs your CRM and Slack, while a finance agent needs your ERP and Gmail.
Check the pre-selected tools, and add or remove any before you save.
Test with a plain-language ask, like "check the #support channel for anything mentioning our biggest account."
Step five is where your safety work really starts. Why? The builder works from your description, and you know better than any model which actions this job should never take.
Picking tools is your first guardrail, and permissions are your second.
You set per-action permissions in Admin settings, where you can turn off individual actions within a connector. For example, you could disable Jira ticket creation and keep Jira search on, so your triage agent reads the backlog without adding to it.
How strict should you be? If a connector exposes 10 actions and your agent uses two, turn off the other eight. A least-privilege setup, the same principle of least privilege your security team already applies to people, looks like this:
Begin with read-only actions, such as searches and lookups.
Add write actions one at a time, after the agent handles reads reliably.
Turn off every action the job doesn't need, even ones that look harmless.
Revisit permissions whenever you widen the agent's job.
As you build multi-agent systems, where one agent hands work to the next, tight permissions matter even more. Each handoff is another point where an action can fire without a person watching; a short list of allowed actions keeps any mistake small. Since a chain of agents can take on bigger workflows, each one should carry only the actions its step needs.
Permissions decide what an agent can do. How do you find out what it actually did?
You audit tool calls through AgentSpot's tool-call log, which records every call your agent makes. Filter the log to see what an agent touched and when.
Need to share that record with your security team? Export it to CSV.
Running several agents? Put their logs side by side for a simple form of multi-agent analytics. You'll see which agents reach into which apps, how often, and whether any of them called an action you expected them to skip. That record also answers the question nobody wants to guess at in a Monday meeting: what did the agent change, and where?
For a look at how the team behind AgentSpot approached connector governance and logging, read how AgentSpot was built.
The log is your after-the-fact view, while testing is how you catch problems before anything goes live.
You test each tool by asking the agent something it can only answer by calling that tool. Here's a Slack example: ask about a message you know exists in a specific channel. If the agent invents a Slack message instead of returning a real one, the connector isn't set up right.
Run through this checklist for every connector:
Ask one question per tool that only that tool can answer.
Compare the answer against the source app yourself.
Check the tool-call log to confirm the call actually happened.
Try a write action only after its matching read action passes.
Does that feel like a lot of testing for one agent? It takes far less time than cleaning up a record your agent created by mistake in a live system.
