How to Use an AI Agent: A Practical Guide
How to Use an AI Agent
Using an AI agent means giving a language model a goal, the tools it needs to act on that goal, and enough context to make good decisions along the way — then checking its work. That's the whole idea in one sentence. The rest of this article breaks down what that looks like in practice, whether you're using an agent as an end user through a chat interface or building one into a product.
The short version: pick a model with tool-use support, define a narrow task, connect it to the systems it needs (search, a database, an API, a code interpreter), and set boundaries on what it's allowed to do without asking you first. Agents work best when the task is well-scoped, not when you ask them to "handle everything."
What an AI Agent Actually Does Differently
A regular chatbot answers a question. An agent does three things a chatbot doesn't:
- Plans — breaks a goal into steps
- Acts — calls tools, APIs, or functions to do something in the real world (or your codebase)
- Observes and adjusts — looks at the result of each action and decides what to do next
This loop — plan, act, observe, repeat — is what people mean when they say "agent" instead of "assistant." If a system just replies to messages with no ability to take action between turns, it's not really agentic yet.
Step 1: Pick the Right Model and Access
Not every model handles tool use equally well. You want a model that reliably:
- Decides when to call a tool versus answer directly
- Formats tool calls correctly (valid JSON, correct parameter names)
- Uses the tool's output to inform the next step instead of ignoring it
Claude models are strong here, which is why a lot of agent tooling is built around them. If you're building a product on top of Claude rather than just chatting with it, you'll want programmatic access — an API key, not a browser session. That's the layer SubToAPI sits at: it turns your existing Claude access into a standard HTTPS API with sub_live_... keys, so your agent's code can call /v1/messages the same way it would call any other LLM API, with support for streaming and tool use built in. See /docs/quickstart if you're setting this up for the first time.
Step 2: Define a Narrow, Checkable Task
Vague goals produce vague agent behavior. "Manage my inbox" is too broad. "Draft replies to emails tagged 'support', using our FAQ doc as reference, and flag anything that mentions a refund" is a task an agent can actually execute and that you can verify.
Good agent tasks share three traits:
- A clear success condition you can check against
- A bounded set of tools — not "access to everything"
- A defined stopping point, so the agent doesn't loop indefinitely
Step 3: Give It Tools, Not Just Text
Tool use (also called function calling) is what turns a language model into an agent. You describe a function — its name, parameters, and what it does — and the model decides when to call it based on the conversation.
{
"name": "search_orders",
"description": "Look up a customer order by ID",
"input_schema": {
"type": "object",
"properties": {
"order_id": { "type": "string" }
},
"required": ["order_id"]
}
}
When the model decides to use this tool, your application runs the actual lookup and sends the result back. The model then decides what to do next — answer the user, call another tool, or ask a clarifying question. This request/response loop is documented in detail at /docs/tools if you're implementing it against SubToAPI's /v1/messages endpoint.
A minimal streaming call using SubToAPI looks like this:
curl https://api.subtoapi.app/v1/messages \
-H "Authorization: Bearer $SUBTOAPI_KEY" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-4-5",
"max_tokens": 1024,
"stream": true,
"tools": [{
"name": "search_orders",
"description": "Look up a customer order by ID",
"input_schema": {
"type": "object",
"properties": { "order_id": { "type": "string" } },
"required": ["order_id"]
}
}],
"messages": [{ "role": "user", "content": "Where is order 48213?" }]
}'
Streaming matters for agents with multiple steps — you want to show progress instead of a silent multi-second wait while three tool calls happen in sequence. Details on setting that up are in /docs/streaming.
Step 4: Set Permissions and a Human Checkpoint
The riskiest part of using an agent isn't the reasoning — it's giving it write access to something important without a review step. Practical guardrails:
- Read-only by default. Let the agent look things up freely; require confirmation before it sends emails, writes to a database, or spends money.
- Rate-limit tool calls. Cap how many actions an agent can take per task to prevent runaway loops.
- Log everything. Every tool call and its result should be recorded so you can debug why the agent made a decision.
- Add a timeout or step limit. If it hasn't converged on an answer after N steps, stop and hand off to a human.
Step 5: Watch Usage and Cost
Agents make more model calls than a single chat turn — often several per task, since planning, tool calls, and final answers each consume tokens. Track token usage per task type so you know which agents are expensive to run. If you're running this across a team, per-key usage metadata (available through SubToAPI's dashboard, alongside seat management for Team and Scale plans) makes it easier to see which workflows are worth the cost and which need tighter scoping. Plans start at /pricing, with a free trial at /signup if you want to test an agent workflow before committing.
A Simple Agent Loop in Practice
- User states a goal
- Agent decides: answer directly, or call a tool
- If a tool is called, your code executes it and returns the result
- Agent reads the result and decides the next step
- Loop continues until the agent produces a final answer or hits a limit
- You log the full trace for review
This loop is the same whether the agent is answering support tickets, summarizing documents, or writing code — only the tools and the task definition change.
Questions
Do I need to write my own agent framework? No. You need a model with reliable tool use, a small set of well-defined functions, and a loop that passes results back to the model. Frameworks add convenience, not capability.
How is an AI agent different from a chatbot? A chatbot replies to messages. An agent can call tools between turns, observe the results, and take further action without a human typing the next instruction each time.
What's the biggest mistake people make using agents? Giving them tasks that are too broad and too much unsupervised write access at the same time. Narrow the task and gate risky actions behind confirmation first — expand scope once you trust the behavior.