Agents vs Chatbots: When Do You Need an Agent?
On this page
A Chatbot Isn’t Always Enough
You have likely already used the Mistral Chat Completions API to build conversational assistants. For many use cases, this is more than sufficient. The temptation to switch everything to agents just because the technology is newer can be costly in terms of both latency and tokens. However, some tasks require more than a simple text response. This lesson gives you the decision criteria: how to recognize situations where a call to chat.complete() does the job, and those that truly justify moving to the Agents API.
Chat Completions — The Classic Model
With chat.complete(), you send a list of messages and receive a response. The mechanism is stateless: the model has no memory between calls, and you must reconstruct the history for every request.
from mistralai.client import Mistral
client = Mistral(api_key="your-key")
response = client.chat.complete(
model="mistral-large-latest",
messages=[
{"role": "user", "content": "What is the capital of France?"}
]
)
print(response.choices[0].message.content)
This pattern remains the right choice for simple Q&A, general text generation—summaries, translations, writing—classification, information extraction, and one-off function calling. These tasks share a common trait: they are text-to-text transformations resolved in a single reasoning pass, without the model needing to fetch anything from the outside.
Agents API — The Autonomous Model
With the Agents API, you create a persistent agent equipped with instructions, tools, and behavior defined once and for all. The agent maintains its state across conversations and can act autonomously.
agent = client.beta.agents.create(
model="mistral-large-latest",
name="Research Assistant",
instructions="You are a research assistant. Use web search to answer with sources.",
tools=[{"type": "web_search"}]
)
When to Switch to Agents?
Any one of the following signals justifies the switch. The most frequent is the need for tools: as soon as your assistant must search the web, execute code, or query a document corpus, Chat Completions forces you to wire the execution yourself. Next comes state persistence: if you want the model to remember previous exchanges without you resending the entire thread with every request, the agent handles this natively. The number of steps matters just as much: a response requiring a chain of reasoning with intermediate actions implies a loop, and the Agents API implements precisely that loop. Multiple specialties push in the same direction: a financial agent delegating to a web search agent, then to a calculation agent, falls under multi-agent orchestration. Finally, consider the execution environment—with agents, tools run in the Mistral cloud, not on your infrastructure.
Conversely, stick with a classic chatbot if the task is a simple text-to-text transformation, if you already manage history on the client side to your liking, if no built-in tools are required, and if a single reasoning pass suffices to produce the expected answer.
The Complexity Spectrum
It helps to view these choices as a continuum rather than a binary alternative. At the first level, simple chat: a question, an answer, via Chat Completions. At the second, tool-equipped chat: the question triggers a function call before the answer, still using Chat Completions and function calling. At the third, the single agent: the request leads to planning, then multiple actions, then an answer—this is the domain of the Agents API. At the fourth, multi-agents: a router agent distributes the request to specialized agents whose outputs are then synthesized, which requires the Agents API and handoffs.
The rule derived from this spectrum is simple: use the simplest level that satisfies your need. Do not deploy a multi-agent system to answer FAQs.
Comparative Example
The difference is clearer with a concrete example. With Chat Completions, you manage everything manually, and the model remains confined to its training knowledge.
# You manage everything manually
messages = [{"role": "user", "content": "What is the weather in Paris?"}]
response = client.chat.complete(model="mistral-large-latest", messages=messages)
# The model CANNOT search the web—it hallucinates or says it doesn't know
With an agent equipped with web search, the same question triggers a real search and a sourced response, without you writing a single line of orchestration code.
# The agent has access to web search
agent = client.beta.agents.create(
model="mistral-large-latest",
name="Weather Agent",
instructions="Answer weather questions using web search.",
tools=[{"type": "web_search"}]
)
response = client.beta.conversations.start(
agent_id=agent.id,
inputs="What is the weather in Paris?"
)
# The agent automatically searches the web and cites its sources
Cost and Latency
This power comes at a price, and you must anticipate it before production. Latency increases because the agent may perform multiple internal turns—search, then reasoning, then drafting—whereas Chat Completions performs only one. Token consumption also rises, since system instructions and conversation context are sent back to the model at every turn. Finally, conversations persist on the Mistral side, a behavior you can disable with store=False if your privacy constraints require it.
This overhead is perfectly justified when the task demands it. For a simple FAQ chatbot, it is not: stick with Chat Completions.
Key Takeaways
- Chat Completions is stateless and sufficient for simple tasks
- The Agents API adds persistence, built-in tools, and multi-agent orchestration
- Always use the lowest complexity level that satisfies your need
- Switching to agents is justified when you need tools, persistence, or multi-agents