Key facts
| Core output | Chatbot: a text reply; agent: a completed task |
| Architecture | Agent adds a tool loop, state and stop conditions |
| System access | Agents read and write systems; most chatbots only read |
| Cost shape | Agent multiplies tokens per turn by the number of turns |
| Risk surface | Agent writes need approvals, limits and audit logs |
| Upgrade path | A chatbot becomes an agent when you add tools and a loop |
| Live API | Function calling, streaming and JSON mode are live |
| Roadmap | Assistants-style managed endpoints are coming soon |
TL;DR
- Chatbots answer; agents act. Decide which one your workflow actually needs.
- Tools plus a loop are the dividing line, not the interface.
- Agents cost more per interaction because every turn consumes tokens.
- Write-capable agents require scoped keys, approvals and audit logs.
- Adding function calling to an existing chatbot is a base-URL-compatible upgrade.
How it works, step by step
- Define the job: does the user need information, or does the system need changing?
- Keep the chatbot for information jobs and measure resolution quality first.
- For action jobs, expose the minimum tools with typed schemas and clear descriptions.
- Add a loop with a turn cap and a stop condition so the agent cannot run forever.
- Gate writes behind human confirmation and log every tool call.
- Evaluate both the reply quality and the actions taken, including cost per task.
- Roll out behind a flag, canary on real traffic, then expand the tool set.
Try it yourself
Open the AI agent comparison →
Chatbot, agent and the space between
Most "AI assistants" in production are chatbots with retrieval: they find relevant context, generate a useful reply, and stop. That is a good product. Agents are different in kind: they do not wait for the next message, they decide what to do next, run the tool, read the result and keep going.
Between the two sits a useful middle ground: a chatbot that calls read-only tools to answer better. It can look up an order, check a balance or query a database without changing anything. That pattern captures much of the value with far less risk, and it is the right first step for most teams.
What actually changes when you add tools
- Cost: each turn resends context and tool schemas, so prompt size grows with history.
- Latency: tool execution adds seconds between turns; streaming keeps the interface alive.
- Failure modes: wrong tool, bad arguments, timeouts, loops and partial completion.
- Security: the agent now holds credentials and can change systems, so least privilege matters.
- Evaluation: you must score trajectories, not just replies.
None of these are reasons to avoid agents. They are reasons to add tools deliberately, one workflow at a time, with measurement attached.
Choosing the smallest thing that works
The cheapest reliable system that completes the job wins. Start with retrieval and one model call. Add read-only tools. Add write tools only behind confirmation. Promote to a full multi-step agent when evaluation shows the extra autonomy earns its cost and risk.
On Plugsky, function calling and streaming are live on the OpenAI-compatible API, so each step of that progression is a code change rather than a provider migration. 30+ models behind one key let you keep a small model on chat traffic and use a frontier model for complex plans. Chat, JSON mode, embeddings, RAG and agents are live; audio, images, moderation, files, batch, fine-tuning, assistants and responses are coming soon. Plans, including free plugsky-micro and plugsky-lite, are on the live pricing page.
Honest comparison
| Capability | Scripted chatbot | LLM chatbot | AI agent |
|---|---|---|---|
| Response quality | Fixed flows | Fluent and contextual | Fluent plus task completion |
| Tools | Hard-coded logic | Optional read-only lookups | Multi-step tool loop |
| State | Session variables | Conversation history | History plus durable run state |
| Actions | None beyond script | Rarely writes | Writes with approval gates |
| Evaluation | Flow completion | Reply quality | Trajectory and task success |
Frequently asked questions
Is ChatGPT a chatbot or an agent?
Both interfaces exist: conversational chat and agentic modes that browse or operate tools. The distinction is whether the system acts on its own to complete a task.
Can a chatbot use tools safely?
Yes, if tools are read-only or tightly scoped. Read-only lookups add most of the value with a fraction of the risk of write access.
Do agents replace chatbots?
No. Chatbots remain the right choice for information and support flows. Agents handle work that would otherwise be done manually across systems.
How much more does an agent cost?
It depends on turns and tools. A ten-turn agent with retrieval can cost many times a single chat call, so measure cost per completed task and cap turns.
What is the first tool I should add?
The lookup your users request most often, exposed read-only with a typed schema and a result size limit.
How do I stop an agent doing something wrong?
Least-privilege tools, argument validation, human approval for writes, rate limits and full audit logs with trace IDs.
Can I use Plugsky for both?
Yes. The same OpenAI-compatible API serves plain chat and function calling, so you can start conversational and add tools when the workflow justifies it.