From chatbot to Agent
An ordinary chatbot is best at generating a response from input text. An Agent adds the ability to act: it can inspect its environment, call tools, adjust the next step from the result, and continue until it produces something that can be checked.
A simple comparison
If you ask an ordinary chatbot, “Why does this project fail to start?”, it can infer only from the information you paste. If you give the same question to an Agent in the project, it can, when permissions allow:
- inspect dependencies and startup configuration;
- search relevant code;
- run a diagnostic command;
- read the command result;
- modify a file or propose a fix;
- run tests and report the evidence.
This does not make an Agent inherently more correct. It simply has more ways to gather evidence and affect the environment, so it also requires stricter permissions and verification.
Four components of an Agent
Model
The model understands the objective, chooses the next step, and generates text. It is not a database and does not automatically know the files on your computer or the current contents of a webpage.
Context
Context is the information visible to the current model request, including task instructions, a conversation-history summary, relevant file results, and Tool descriptions. Context has a capacity limit, so the system must select, measure, and compact it.
Tools
Tools let the model read files, search code, run commands, research online, or call an MCP Server. The model only proposes a call; the Host still validates parameters, permissions, and approvals.
Loop
An Agent usually does not finish after one request. The model calls a Tool, observes the result, and chooses the next step until it produces a final answer, waits for approval, fails, or is canceled. This is the Agent Loop.
“Can act” does not mean “can be trusted with everything”
An Agent may misunderstand the task, choose the wrong Tool, be influenced by untrusted text on a webpage or in a project, or be unable to determine whether an external action succeeded after a timeout. Safe use requires three layers:
- You state the objective, boundaries, and completion criteria.
- The system enforces permissions, approvals, path checks, and parameter checks.
- You verify the result with files, tests, sources, and external state.
The most mature way to use an Agent is therefore not to hand over all control, but to treat it as a collaborator that can investigate and execute continuously.
The corresponding concepts in Captain Who
- A project defines the local workspace scope.
- A conversation stores the long-term exchange between you and the root Agent.
- One send normally starts a Run.
- A Run may include several model–Tool exchanges.
- When a human decision is required, the Run can pause for approval.
- Multi-Agent lets the root Agent delegate independent work to subagents.
- Scheduled Automation starts a root Agent Run on a schedule.
You can look up these terms at any time in the Glossary.