What Tools Can an AI Agent Use? Inside the Grant Model

An AI agent without tools is a chatbot. It can reason, summarize, and draft, but it cannot check your inbox, update a CRM record, or query a database. Tools are what turn a language model into something that does work. And tools are also where every serious question about agents begins: what can this thing touch, what can it change, and who decided that?

This article walks through how agent tools work in practice, using the grant model in Skopx as the concrete example. Skopx agents can reach nearly 1,000 integrations, but no agent gets any of them by default. Every toolkit is granted per agent, and every grant carries a tier that controls whether the agent acts freely, asks first, or only produces drafts. That structure, not the raw integration count, is what makes tool access workable.

The two halves of "tools": capability and permission

When people ask what tools an AI agent can use, they are really asking two different questions.

The first is capability: which systems can the agent physically reach? An agent platform answers this with its integration catalog. Skopx connects to nearly 1,000 integrations through Composio-backed toolkits, covering Gmail, Slack, Notion, HubSpot, Salesforce, Google Sheets, Google Calendar, Google Drive, GitHub, Linear, Jira, Trello, Asana, Stripe, Shopify, LinkedIn, Airtable, Discord, Outlook, ClickUp, Mailchimp, Reddit, and a long tail beyond those. On top of app integrations, agents can query connected data sources such as Postgres and MongoDB with SQL and aggregations, run web search and web fetch, drive browser tools, and save findings to the Insights Hub.

The second question is permission: which of those systems is this particular agent allowed to use, and how? This is the question the grant model answers, and it is the more important one. A platform that connects to a thousand services but hands every agent the full set is not powerful. It is a liability. The interesting engineering is in the scoping.

If you are still deciding whether an agent is the right shape for your problem at all, what can AI agents do covers the capability side in more depth. Here we focus on how access is structured once you have decided.

Grants: per agent, per toolkit

In Skopx, a grant is a statement of the form: this agent may use this toolkit, at this tier. Grants are made when you build the agent, and they are enforced when the agent runs. An agent you built for inbox triage might hold grants for Gmail and Slack and nothing else. A CRM hygiene agent might hold HubSpot and Google Sheets. Neither can see the other's toolkits, even though both live in the same workspace and both could, in principle, reach the full catalog.

This per-agent scoping matters more than it first appears, for three reasons.

It limits blast radius. An agent that misreads its instructions can only misbehave inside the toolkits it holds. A reporting agent with read access to Postgres and a Slack grant cannot accidentally send an email, because it has no email toolkit at all. The wrong action is not merely discouraged, it is unreachable.

It makes review tractable. When you audit an agent, you audit a short list. "This agent can read Gmail and post to one Slack channel" is a sentence a human can verify. "This agent can use anything the workspace is connected to" is not.

It keeps the model focused. Agents choose their next step by looking at the tools in front of them. An agent holding two toolkits considers two toolkits. Narrow grants produce more predictable runs, which makes debugging agent runs far easier when something does go wrong.

Grants happen at dispatch: when a run starts, the agent receives exactly the toolkits it was granted, at the tiers it was granted them. There is no path for an agent to escalate its own access mid-run.

The tiers: how much autonomy per toolkit

A grant is not just yes or no. Each toolkit grant carries a tier that sets how the agent may use it:

The tiers compose per toolkit, which is the point. A single agent can hold Gmail at drafts only, HubSpot at asks first, and Google Sheets at runs automatically. That mirrors how you would actually delegate: the same assistant might be trusted to update a tracking spreadsheet freely, expected to check with you before touching the CRM, and never allowed to send email under your name without your eyes on it.

One rule sits above the tiers and is worth stating plainly: reads flow without approval even under approval_required. Checking an inbox, listing deals, fetching a page, or running a read-only query never parks for sign-off. Approvals exist to gate change, not observation. An agent that had to ask permission to look at anything would drown you in requests and teach you to rubber-stamp them, which defeats the purpose.

What an approval actually contains

When a write-shaped action hits a toolkit granted at "asks first" (or when an "agent decides" grant escalates), the action parks as a pending approval. The approval shows the exact call and the exact arguments: the specific Gmail send with the full recipient list, subject, and body; the specific HubSpot update with the field values it will write.

Approving executes exactly that parked call, once. Not "the agent continues with your blessing", not "the agent retries with adjustments". The call you read is the call that runs. Rejecting executes nothing. Approvals can also expire, so a stale request from Tuesday cannot fire on Friday when the context has moved on.

This exactness is the difference between an approval system and an approval theater. If approving meant "resume the agent and trust it from here", you would be signing off on future behavior you have not seen. Because approval binds to one concrete call with concrete arguments, your review is of the actual thing that will happen. The broader pattern, including how teams route approvals in practice, is covered in AI agents with human approval.

Drafts-only mode: the training-wheels tier that many teams never remove

Drafts only deserves its own section because it is the most underrated tier. In this mode the agent does the full cognitive work, researching the thread, composing the reply, structuring the update, and stops at the finished artifact. Nothing sends. Nothing commits.

Two use cases dominate.

New agents. The safest way to evaluate a freshly built agent is to let it run its full loop with the consequences removed. Run an email agent in drafts only for two weeks and you get a pile of real drafts against real inbound mail. You read them, you judge the quality, and you promote the grant tier only when the evidence supports it. This beats any amount of prompt-time speculation about how the agent "should" behave, and it is the core technique in testing AI agents safely.

Permanently human-voiced work. Some outputs should carry a human's judgment forever: replies to upset customers, outreach to important accounts, anything with legal weight. For these, drafts only is not a transitional setting. It is the destination. The agent compresses an hour of composition into minutes of review, and a person remains the author of record. Many teams that could safely automate the send still choose not to, and that is a reasonable steady state, not a failure to fully adopt.

Beyond app integrations: data, web, and browser tools

App toolkits get the attention, but three other tool families do a large share of real agent work.

Data sources. Skopx agents can query connected databases, Postgres, MongoDB, and others, using SQL and aggregations. These connections are read-only with bound parameters, which is a deliberate ceiling: an agent can compute your weekly numbers or spot an anomaly in orders, but it structurally cannot mutate production data, and the bound parameters close off injection through cleverly crafted query strings. If your agent's job is reporting or anomaly detection, this family often matters more than any app integration. See AI agents for data analysis for concrete patterns.

Web search and web fetch. For work that lives outside your systems, competitor monitoring, market research, checking whether a claim is still true, agents can search the open web and fetch specific pages. This is how a research agent grounds its conclusions in sources rather than model memory.

Browser tools. Some tasks have no API: a portal with no integration, a page that only renders behind interaction. Browser tools let an agent operate a real browser for those cases. They are slower and more brittle than API calls, so a well-built agent treats them as the fallback, not the default.

Insights Hub. Agents can save findings to the Insights Hub, which gives their discoveries a durable home beyond any single run report. A monitoring agent that spots something notable can file it where the team will actually see it later.

Choosing grants for a real agent: a worked example

Here is a concrete, hypothetical setup to make the model tangible. Suppose you describe this agent in the Skopx chat: "Every Monday at 9:00 UTC, review last week's new HubSpot deals, cross-check the amounts against our Postgres billing database, and post a summary to #revenue in Slack. Flag any deal whose CRM amount disagrees with billing."

A sensible grant sheet:

• HubSpot: runs automatically. The agent only reads deals. Reads flow freely anyway, and there are no writes in the job.
• Postgres: runs automatically. Read-only with bound parameters by construction, so the tier is low-stakes.
• Slack: asks first every time, at least initially. Posting to a shared channel is a write with an audience. After a few weeks of approving accurate summaries, you might promote it to runs automatically, or to agent decides so it only escalates when it found a discrepancy worth a human look before publishing.

Note what the agent does not get: no Gmail, no Sheets, no browser. The job does not need them, so the grants do not include them. When the job grows, you widen the grants deliberately, in the agent's editable instructions and settings, rather than provisioning broadly up front "just in case". Grants are cheap to add later and expensive to regret.

Alongside grants, the same agent would carry budgets, token caps per run and per day, a step limit, and a minute cap, so that even a fully automatic grant operates inside hard resource walls. Grants bound what an agent may touch; budgets bound how much it may do. The two together are the guardrail story, covered end to end in the broader guardrails discussion.

Where the grant model has limits

Candor section. The grant model is a strong structure, not a force field, and it is worth knowing what it does not solve.

Tier granularity is per toolkit, not per action. A grant covers a toolkit. If you want an agent to send Slack messages freely but require approval for channel creation, the tier system's answer is to set the whole toolkit to "agent decides" and rely on instructions to shape which actions it escalates. That usually works well, but it is instruction-shaped, not structurally enforced at the individual action level.

"Agent decides" inherits the agent's judgment. The middle tier is genuinely useful, but its escalation decisions are made by the model. A well-instructed agent escalates the right things; a vaguely instructed one may not. If you cannot articulate when the agent should ask, use "asks first" until you can.

Approvals add latency by design. An agent gated on approvals moves at the speed of its reviewer. That is the correct trade for high-stakes actions, but it means "asks first everywhere" is not free. Teams that gate everything tend to either drown in approvals or stop reading them. Reserve the gate for actions that deserve it.

Untrusted inputs remain untrusted. Webhook payloads are treated as untrusted data, and connected credentials are encrypted, with security controls in place around the toolkit layer. But no grant tier can make an agent immune to a confusing input producing a confused draft. That is what run transparency, step timelines with expandable raw results, and append-only run history are for: you can always see exactly what the agent did and why.

How this compares to other automation models

It helps to place the grant model against the two systems teams usually come from.

In workflow builders of the Zapier style, permissions are effectively per workflow step: you wire step three to a specific Slack action, and that is all it can ever do. Maximum predictability, minimum flexibility. The workflow cannot handle a case its wiring did not anticipate. Skopx has this model too, as workflows, and it remains the right choice for fixed-path jobs; the comparison in AI agent vs workflow automation goes deeper on when each fits.

In script-based automation, permissions are whatever credentials the script holds, usually a service account with broad standing access that nobody has reviewed since it was created. Flexibility without structure.

Agent grants sit between: the agent chooses its path at run time, like a script author would, but inside a toolkit boundary and tier structure declared up front, like a workflow. You get adaptive behavior with reviewable scope.

FAQ

How many tools can one agent hold?

There is no fixed cap on grants, but restraint wins. Every granted toolkit widens what the agent considers at each step and what you must review when auditing it. Most effective agents hold two to five toolkits. If a job seems to need eight, that is usually a sign it is two jobs, and the tradeoffs are covered in the one-agent-versus-many discussion.

Can an agent request access to a toolkit it was not granted?

No. Grants are fixed at dispatch, when the run starts. An agent cannot grant itself a new toolkit mid-run or escalate its own tier. If a run needs a toolkit the agent lacks, the run works without it and the gap shows up in the report, at which point you decide whether to add the grant. Access changes are always a human decision made in the agent's configuration, never an agent decision made inside a run.

Do read actions really never require approval?

Under the approval-required tier, reads flow and writes park. That is deliberate: gating observation buries reviewers in trivial requests and trains them to approve without reading. If a data source is sensitive enough that even reads worry you, the control is at the grant level: do not grant that toolkit or data source to that agent at all.

What happens to pending approvals if I pause the agent?

Pausing an agent is a kill switch for its queued runs, and approvals can expire on their own. A parked approval only ever executes if a human explicitly approves that exact call while it is still valid. Nothing fires by default, and rejecting executes nothing. The mechanics of stopping runs mid-flight are their own topic, but the short version is that stopping always wins.

Is drafts-only mode different from "asks first"?

Yes, and the difference is what exists at the end. Under "asks first", the agent intends to execute and the action runs the moment you approve it. Under drafts only, there is no pending execution at all: the agent produces the artifact, a draft email, a proposed update, and a human takes it from there in their own tools. "Asks first" is a gate on the agent's action. Drafts only removes the action entirely.

Start narrow, widen with evidence

The practical summary fits in four moves. Grant only the toolkits the job needs. Start write-capable toolkits at drafts only or asks first. Read the run reports and the parked approvals for a couple of weeks; they are the evidence. Then promote tiers where the evidence supports it, and leave human-voiced work in drafts permanently.

Skopx agents are built by describing them in chat at Create Agent, no code and no canvas, and the grant sheet is part of that conversation from the first message. If you want the full picture of what these agents are and how they run, the overview at skopx.com/agents is the place to start, and pricing covers the $16 per seat Team plan and bring-your-own-key options across eight model providers.

The integration count gets an agent platform noticed. The grant model is what makes it usable. A thousand tools behind a structure you can read, tier, and audit beats a thousand tools behind a single on switch, every time.