Key facts
| Interaction | Assistant: one request, one answer |
| Goal handling | Agent: a loop that continues until the goal is met |
| Tools | Agents call functions; most assistants do not |
| Cost shape | Assistant: one call; agent: turns plus tool calls |
| Risk surface | Agents need permissions, budgets and approvals |
| Memory | Agents benefit from short- and long-term memory |
| Platform fit | Assistants-style endpoints are coming soon; the agent loop is live |
| Models | Both run on the same 30+ model catalogue |
TL;DR
- The dividing line is the loop: an assistant answers, an agent acts until done.
- Ship an assistant when the job is information; use an agent when the job is work.
- Agents multiply cost and risk by the number of turns and tools they use.
- Constrain agents with scoped tools, turn caps and human approval for writes.
- You can start as an assistant and add tools later without re-platforming.
How it works, step by step
- Write down the user job and mark whether it ends in an answer or a completed task.
- If it ends in an answer, build an assistant first and measure whether that is enough.
- If it needs systems changed, add tools and turn the assistant into an agent loop.
- Define which tools are read-only and which write, and gate the writes behind approval.
- Add memory only where continuity matters, with retention and privacy rules.
- Cap turns and set budgets, then evaluate both quality and cost per task.
- Route routine requests to small models and reserve frontier models for complex tasks.
Try it yourself
Open the AI agent comparison →
The line is the loop
An assistant is a stateless-ish conversation: the user asks, the model answers, the turn ends. It may retrieve context, but it does not keep going on its own. An agent adds three things: a goal it pursues without a new user message, tools it can call, and state that survives between calls. That loop is what makes the difference visible in both capability and cost.
The distinction is architectural, not a marketing label. If your system decides to call a function, observes the result and calls another function to reach an outcome, it is an agent regardless of what the product page calls it.
When an assistant is the right choice
Assistants are excellent value for question answering, drafting, summarising, translation and classification. They are cheaper because they make one model call, easier to evaluate because there is a single output, and simpler to secure because they do not hold write credentials. For many products, a well-retrieved assistant with good prompts outperforms a half-built agent on user satisfaction and cost per interaction.
Choose an assistant when the work ends with information going to a human, and the human performs the action. Choose an agent when the action itself is the bottleneck.
When you actually need an agent
Agents earn their complexity when tasks are multi-step, tool-dependent and repetitive: reconciling records, triaging tickets, preparing research briefs, running checks across systems. The gain is that the model handles variation in the middle of a process, not just at the start.
Adopt them with guardrails. Give each agent a scoped identity and an allowlisted tool set, cap turns, require approval for irreversible actions and log every call. On Plugsky, function calling, streaming, JSON mode, embeddings, RAG and agents are live on one OpenAI-compatible API with 30+ models, so an assistant can become an agent by adding tools rather than re-platforming. Managed assistants-style endpoints are coming soon. Plans, including the free plugsky-micro and plugsky-lite tier, are on the live pricing page.
Honest comparison
| Dimension | Assistant | Agent | Hybrid |
|---|---|---|---|
| Output | Answer or draft | Completed task | Draft plus confirmed action |
| Turns | Usually one | Multiple until done | Agent runs, human confirms |
| Cost | One model call | Turns plus tools | Turns capped by approval point |
| Risk | Low: no side effects | Higher: writes and spend | Bounded by confirmation |
| Best for | Questions, summaries, drafting | Repetitive multi-step work | Sensitive workflows |
Frequently asked questions
Is an agent just a chatbot with tools?
Partly. A chatbot with tools that only answers is still conversational. An agent keeps working toward a goal without new user messages, which is the meaningful difference.
Are agents always better?
No. They cost more, fail in more ways and are harder to evaluate. If a human performs the action after reading an answer, an assistant is usually the better product.
Can I add tools to an assistant later?
Yes. Function calling is live, so tools can be introduced behind a feature flag while you keep the same endpoint, models and evaluation harness.
What is an assistants API?
A managed endpoint that stores conversation state and tool configuration server-side. On Plugsky, assistants-style endpoints are coming soon; the tool loop is live today.
Do agents need memory?
Only where continuity matters. Short-term memory is the message history; long-term memory is a store you choose, with explicit retention and privacy rules.
How do I control agent cost?
Cap turns, trim context, route routine steps to small models and measure cost per completed task rather than per token.
Which Plugsky models support tools?
All modern models in the 30+ catalogue support function calling; check the model reference for per-model details.