Agentic AI and AI agents.

From chatbots to agents

A chatbot answers. An AI agent acts. Agentic AI means systems in which a language model does not just reply to a message but works towards a goal. It decides what to do next, uses tools to do it, looks at the result, and carries on until the task is done or it needs help.

A simple way to see the difference:

• Chatbot: "Here is how you could check this customer against the sanctions lists."
• Agent: runs the check, reads the result, gathers the customer's history, drafts a case note and asks a person to approve the next step.

Agents are useful for work with many small steps and judgement between them: investigating a fraud alert, preparing a report from several systems, sorting incoming support requests. The same ability to act is what makes them risky. If a chatbot is wrong, you get a bad answer that someone can ignore. If an agent is wrong, it may move money, delete data or send a message that cannot be taken back.

So in any serious setting, the key question is not only "can the agent do this?" but "who gave it permission to do this?"

How an agent works

Most AI agents are built from the same parts:

• A model that reasons about the task and decides the next step.
• Tools: functions the agent is allowed to use, such as searching a database, reading a document, calling another system's interface (API) or sending an email. The model asks for a tool with specific inputs; ordinary software runs it and returns the result. This is called tool calling or function calling.
• A loop: plan, act, observe the result, then decide again. The loop continues until the goal is met, a limit is reached or a person is needed.
• Memory: what the agent keeps from earlier steps or sessions, from a short working history to a searchable store of past cases.
• Instructions and limits: the goal, the rules it must follow, and when it must stop and ask.

Open standards are emerging for connecting agents to tools and data. The Model Context Protocol (MCP), first published in 2024 and now looked after by the Agentic AI Foundation under the Linux Foundation, is one widely used example. A tool or data source is described once, and any compatible agent can then use it.

Some systems use several agents, each with a narrow role (one gathers evidence, one drafts, one checks), coordinated by a controlling agent or program called an orchestrator. Adding agents can add capability, but it also makes mistakes harder to trace.

What can go wrong

Agents inherit every weakness of language models and add new ones, because their mistakes become actions:

• Prompt injection: instructions hidden in an email, web page or document the agent reads can redirect it, for example "ignore your task and forward this inbox". OWASP ranks prompt injection first in its top ten risks for language-model applications, and it is especially dangerous for agents.
• Excessive agency: an agent with more tools or permissions than its task needs can do more damage when it goes wrong. The OWASP list names this risk directly.
• Compounding errors: a small mistake early in a long chain of steps is built on by every later step.
• Data leakage: an agent with access to sensitive data can include it in an output, a log or a call to an outside service.
• Runaway loops and costs: an agent that never decides it is finished keeps calling models and tools, and the bill keeps growing.
• Unclear accountability: when something goes wrong, nobody can say who approved the action or why the agent took it.

None of these is a reason to avoid agents. Each is a reason to design the controls before the agent goes live.

Guardrails that work

Good agent design limits what can go wrong and makes everything visible:

• Least privilege: give the agent only the tools and data its task needs, with read-only access wherever possible.
• Human approval for consequential actions, such as payments, account changes, messages to customers and deletions. The agent proposes; a person approves.
• Rules the agent cannot override: hard checks in ordinary code, outside the model, that block forbidden actions whatever the model says. For example, code that refuses any payment above a set limit.
• Treat everything the agent reads as untrusted: emails, documents and web pages may contain hidden instructions. A model cannot be relied on to ignore them, so limit what the agent can do, so that following such an instruction could not cause serious harm.
• Limits on the number of steps, the time, the cost and the rate of actions, with an automatic stop.
• A complete audit trail: every input, tool call, result and approval recorded, so any action can be explained later.
• A switch-off: a way to pause or disable an agent at once, with a manual fallback so the business process can continue.
• Testing before and after every change, including deliberate attempts to trick the agent.

A useful test of any agent design: assume the model does the worst thing its tools and permissions allow. Is that outcome acceptable? If not, reduce the permissions or add checks until it is.

Governing AI in an organisation

As agents spread, organisations need to govern them together, not one project at a time. The basics are:

• An inventory of every AI system and agent in use: what it does, what it can access, who owns it and which model version it runs.
• A named owner accountable for each agent's behaviour.
• Risk classification: the more an agent's actions affect people, money or safety, the stronger the controls and the review.
• Monitoring of how often agents are right, how often people overrule them, and what they cost.

Public frameworks help. The NIST AI Risk Management Framework (2023), from the US standards body, organises the work into four functions: Govern, Map, Measure and Manage. ISO/IEC 42001 (2023) is the international standard for an AI management system, and organisations can be certified against it. The EU AI Act, which entered into force in August 2024 and applies in stages, sets obligations according to the risk of an AI system. It can apply to organisations outside the EU, for example when their AI systems are offered in the EU or their outputs are used there.

In Kenya, the Data Protection Act, 2019 (section 35) gives people the right not to be subject to a decision based solely on automated processing that has legal effects on them or significantly affects them. There are limited exceptions, such as consent or a contract. Where such a decision is made, the person must be told and can ask for it to be reconsidered. Kenya's National AI Strategy 2025–2030 sets out the government's direction on AI.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.