What Is an AI Agent and How It Differs from a Chatbot

An AI agent is a program built on a language model that receives a goal, plans its own steps and carries them out in the company’s business systems: the task tracker, CRM, email, knowledge base. Unlike a chatbot, an agent doesn’t just answer; it acts through connected tools, checks the result and tries again. So the main question when implementing an agent isn’t “which model is smarter” but what access it has and who oversees its actions.

This article is for founders, IT managers and COOs of IT companies in Kazakhstan who keep hearing about AI agents from every direction and want to understand where they’re actually useful. We cover how an agent works, how it differs from a chatbot, a script and an assistant, where it delivers value in an IT company, what risks it carries, what MCP is and how to launch a first scenario without unnecessary risk.

How an AI agent works

At the core of an agent is a language model, the same technology behind ChatGPT or Claude. On its own, a model can only read and write text. What turns it into an agent is a working loop and a set of tools.

The loop looks like this:

1. Goal. A person or an event in a system sets a task: “sort the new support requests,” “prepare a summary of this week’s deals.”
2. Plan. The model decides which steps are needed and in what order.
3. Action. The agent calls a tool: it searches for tasks in the tracker, reads a deal record, creates a draft.
4. Check. The agent looks at the result and decides whether the goal has been reached, whether another step is needed or whether it’s time to hand the task to a human.

This loop repeats until the task is done. That’s exactly why an agent can handle work that can’t be described by a rigid algorithm: a client’s email is written differently every time, yet the agent still understands what it’s about and where it belongs.

The flip side: an agent acts probabilistically. Most of the time it will behave sensibly, but sometimes it will be confidently wrong, and it’s not always clear in advance when. A good agent architecture is built around this trait rather than pretending it isn’t there.

How an AI agent differs from a chatbot, a script and an assistant

These terms are often mixed up, and as a result companies expect a tool to do something it can’t.

Tool	What it does	How it makes decisions	Where it breaks
Script or automation rule	Runs a set sequence when an event occurs	Rigid “if-then” logic	The input differs from what’s expected
Chatbot	Replies to messages in a conversation	Following a script or using a model	An action in a system is needed, not a reply
AI assistant	Helps a person: writes, summarizes, searches	A model, but a human takes the action	Work without human involvement is needed
AI agent	Carries out steps in systems on its own toward a goal	A model plus tools and rules	Broad permissions without oversight, an unclear goal

A practical rule: if a task can be described as “if X, then Y” with no exceptions, regular automation is enough, and it’s more reliable. An agent is needed where the input is unstructured and the decision depends on the meaning of the text. We wrote more about choosing between rules, scripts and agents in a tracker in Task tracker automation: rules, scripts or AI agents.

What an agent is made of

Any agent, from one built into a task tracker to one assembled by your team, consists of five parts. It’s useful for a manager to know them, because each requires a separate decision.

Component	What it is	The question you need to answer
Model	The language model that understands and plans	Where it runs and what data is sent to it
Tools	Actions the agent is allowed to call	What the agent can and can’t do
Access	An account and permissions in systems	Whose name the agent acts under and with what permissions
Memory	Context: task history, knowledge base, past decisions	What data the agent sees and how long it keeps it
Rules	Instructions, limits, confirmation points	What the agent does on its own and what only after human approval

Companies most often spend their time choosing a model and forget about the last three rows. In practice, it’s the tools, access and rules that determine an agent’s quality. A strong model with vague instructions and admin rights is more dangerous than an average model with a narrow role and clear rules.

A word on rules. Instructions for an agent are written the same way as a job description for a new employee: what’s included in the task, what isn’t, which sources to treat as reliable, when to stop and call a human. A vague “help the team with tasks” produces a vague result. A specific “once a day, sort incoming requests, determine the type from a list of five categories, and if in doubt, add a label for manual review” produces a result you can measure.

Memory is a similar story. An agent needs context: a knowledge base, past decisions, product rules. But the more data it sees, the higher the risk that something irrelevant ends up in its answer. Context should be limited to what the scenario needs.

Where agents are genuinely useful in an IT company

We look at scenarios through two filters: the work repeats often, and the result is easy to check. Here’s where the two meet.

Support. The agent reads incoming requests, determines type and urgency, finds similar resolved cases, drafts a reply and creates a task in the tracker for development if it’s a bug. A human reviews and sends.

Task management. The agent turns notes and conversations into task drafts, sorts the inbox, finds duplicates, summarizes long discussions and flags tasks that haven’t moved. For example, since September 2026 Plane has had AI agents that work inside the workspace, and Atlassian has Rovo. We covered what already works in AI agents in task management.

CRM. After a call, the agent prepares a summary and suggests the next step and a deal stage update. The manager confirms the changes rather than writing them from scratch. The agent also finds deals with no next step and sends reminders about them.

Reports. A weekly summary of projects, sales or incidents from several systems. The agent gathers the data, writes the text and flags deviations, and the manager gets a ready-made document for the planning meeting.

Where agents still fall short

Estimating timelines and complexity, prioritizing in line with company policy, communicating with clients without human review, and any decision someone has to be accountable for. In these tasks, a model gives a plausible answer but doesn’t know the context the team carries in its head: agreements with the client, the project’s history, internal priorities. An agent can prepare material for such a decision, but a human should make it.

Another weak spot is working with bad data. If half the deals in the CRM have no stage and tasks in the tracker have no descriptions, the agent will draw conclusions from garbage. Order in your systems is a prerequisite, not a nice bonus.

Off-the-shelf agent or your own

There are three ways to get an agent, and for a first scenario, choosing the path matters more than choosing the model.

A built-in agent in a system you already use. Task trackers, CRMs and office suites are adding AI features and agents right into their interfaces. Pros: no integration needed, permissions are inherited from the system, launch takes days. Cons: the agent works only inside one system, and the vendor decides which scenarios are available.

An agent assembled from ready-made blocks. A provider’s model, connections to systems via MCP or API, instructions and rules. Such an agent can work across systems: read a request in email, find the client in the CRM and create a task in the tracker. You need someone who understands both processes and integrations.

An agent on your own infrastructure. A local model on the company’s server, your own tools and log. This is the path for companies whose data must not leave their environment. It takes longer to launch and requires an engineer to maintain the model and the server.

In our experience, it makes sense to start with the built-in capabilities of systems the company already has. A custom agent is justified when a scenario spans several systems and built-in features don’t cover it.

Risks and access rights

An agent’s risk is directly proportional to its permissions. An agent without access to systems can only make mistakes in text. An agent with CRM admin rights can bulk-change hundreds of deals in a minute.

The basic rules we apply:

• A separate account. The agent doesn’t work under an employee’s login; otherwise its actions can’t be told apart from a human’s in the log.
• Minimal permissions. Only the projects and actions needed for one scenario.
• Human confirmation. Deletions, bulk changes, messages to clients, changes to deal amounts and stages go through approval.
• A log. You can see what the agent did, at whose request and whether there was a confirmation.
• Expansion based on the pilot. Permissions are added once it’s clear where the agent makes mistakes, not in advance.

A detailed model of roles, delegation and oversight is described in AI agent permissions: RBAC, MCP and delegation.

Kazakhstan context. The data an agent reads — client requests, deal records, conversations — almost always contains personal data. If the agent uses a cloud model from a foreign provider, you need to understand which pieces of data go out in requests and where they’re stored. If it matters that data stays in Kazakhstan, or the environment is sensitive, there is a path with a local model on your own server: for example, Plane Airgapped supports a local AI model without internet access.

MCP in plain words

MCP (Model Context Protocol) is an open standard by which AI applications connect to external systems. Previously, every “model plus CRM” or “model plus tracker” connection was built separately. With MCP, a system publishes a set of tools once, and any compatible AI client can use them. The protocol’s creators compare it to a USB-C port for AI applications.

What matters for a manager:

• MCP is a channel, not a safeguard. The agent gets exactly the capabilities granted by the connection token.
• Many systems already support MCP. For example, Plane has MCP connectors through which external AI tools work with tasks.
• Before connecting, ask which tools the MCP server exposes, which account it runs under and whether calls are logged.

In practice, MCP noticeably speeds up a pilot: you don’t need to build an integration from scratch; it’s enough to connect a ready-made server and restrict its permissions.

How to start with one scenario

Most companies make the mistake of starting with an “AI strategy” for the whole organization. The reverse works: one scenario, one team, a clear metric.

Stage	What we do	Result
Choosing a scenario	Look for frequent, repetitive work with text that’s easy to check	One scenario with an owner
Description	Write down the input, the expected result, error criteria and confirmation points	Instructions for the agent
Draft mode	The agent suggests, a human confirms each action	It’s visible where the agent makes mistakes
Evaluation	Compare time and quality with the work before the agent	Decision: expand, refine or stop
Expansion	Move some actions to automatic mode, add permissions	A working scenario in production

What to measure during the pilot. The time a person spends on the scenario before and after the agent. The share of drafts accepted without edits, accepted with edits and rejected. The number of errors that would have reached a client or the data without review. If drafts have to be rewritten almost entirely, the agent isn’t saving time, and the scenario needs to be narrowed or changed.

Good first scenarios: sorting incoming requests, summarizing calls into the CRM, a weekly project summary. Bad ones: automatic replies to clients, timeline estimates, bulk data changes. If automation in your company is just getting started, it’s worth putting processes and systems in order first; see Business automation: where to start. An agent on top of chaos accelerates chaos.

How we do it

We start with a diagnostic: we look at what systems the company has, where people spend time on repetitive work with text and what data can be passed to a model. We choose one scenario, define permissions and confirmation points, and launch a pilot with one team in draft mode. After the pilot, we show where the agent saved time and where it made mistakes, and only then expand permissions and scale to other teams.

How the work is organized and what the result includes is described on our service page for business automation and AI agent implementation.

---

Sources. MCP protocol overview: modelcontextprotocol.io. Plane: plane.so/pricing and GitHub repository.

Terms in plain words

AI agent

A program built on a language model that receives a goal, plans its own steps and carries them out in connected systems. Unlike a bot, it acts rather than just answers.

Language model (LLM)

A neural network trained on large volumes of text that understands requests and generates responses. It's the agent's 'brain', for example the models behind ChatGPT or Claude.

Agent tools

Specific actions an agent is allowed to call: create a task, find a deal, send an email draft. The set of tools defines what the agent can do at all.

MCP (Model Context Protocol)

An open standard for connecting AI applications to external systems. It lets you describe a system's tools once and use them from different AI clients.

RBAC (role-based access control)

A permissions model where access is granted through a role rather than to each person individually. For an agent, the role is made as narrow as possible for a specific scenario.

Human-in-the-loop

A rule under which a risky agent action is carried out only after a human confirms it. It protects against mistakes that are hard to undo.

Prompt and system instructions

Text rules that define the agent's role, limits and way of working. They are the equivalent of a job description and should be written just as specifically.

Local model

A language model that runs on the company's server without sending data to an external provider. It matters when data can't leave the country or the company's environment.