Agentic workflows and multi-agent systems.

Workflows and agents

"Agentic AI" covers a range of designs. It helps to separate two ends of that range:

• A workflow follows a path that you define in code. The language model does the thinking at each step, such as reading, classifying or drafting, but your code decides what happens next.
• An agent decides its own path. The model chooses which tool to use, looks at the result and decides the next step, within the limits you set.

Most real systems sit between the two: a fixed workflow with an agent inside one step, or an agent that must follow set stages.

The choice matters. Workflows are predictable, cheaper and easier to test and audit. Agents are flexible when the path varies from case to case, but they are harder to predict. Start with the simplest design that does the job. Add freedom only where it clearly pays for itself.

Common design patterns

Most agentic systems are built from a few patterns:

• Chaining: the task is split into fixed steps, and each step's output feeds the next, with checks in between. Example: extract the facts from a document, then draft a summary, then check the summary against the facts.
• Routing: a first step classifies the request and sends it down the right specialised path, such as billing, technical fault or complaint.
• Parallel work: independent parts run at the same time. Or the same task is run several times and the results compared, to catch unreliable answers.
• Orchestrator and workers: a coordinating model splits the task into parts, gives each part to a worker, then merges what comes back. It suits tasks where you cannot list the parts in advance.
• Draft and review: one step produces a result, another checks it against clear criteria, and the draft is revised until it passes or a limit is reached.

These patterns combine. A support system might route each request, chain the steps for a routine one and use an orchestrator for a complex investigation.

Multi-agent systems

In a multi-agent system, several agents each have a narrow role and pass work between them. For example, one gathers evidence, one drafts a report and one checks it.

Splitting the work can help:

• each agent has fewer tools and simpler instructions, so it is easier to get right;
• each role can have its own account and permissions, with only the access its job needs (least privilege);
• a separate checking agent, with its own instructions, can catch errors the drafting agent missed.

It also has costs:

• More model calls, so more cost and more waiting.
• Hand-over errors: context is lost or misread when work passes between agents.
• Spreading failures: one agent's wrong output becomes the next agent's input, so a single error can travel through the whole system.
• Harder debugging: when the result is wrong, it takes longer to find which agent went wrong and why.

Clear hand-over formats help: agents pass structured messages with named fields, not loose text. A shared record of the task, which every step writes to, also helps and becomes the audit trail. Use several agents when the roles are truly different, not because it looks sophisticated.

Where people fit in

Agentic systems work best when people are placed deliberately, not added as an afterthought:

• Approval checkpoints before actions that are hard to undo: payments, account changes, messages to customers, deleting data.
• Escalation when the system is unsure, the case is unusual or a rule says a person must decide. The system should know when to stop, and say why.
• Review of samples of routine work. This catches drift: quality slowly getting worse, for example after a model update, even when nothing looks broken.
• Clear ownership: a named person for each system, who can change its rules and switch it off.

Watch for rubber-stamping. A reviewer facing hundreds of proposals a day may start approving without really looking. Show reviewers the evidence behind each proposal and keep volumes realistic. Track how often they reject or change proposals; a rate close to zero is a warning sign.

Some decisions need a person by law or by regulation. In Kenya, section 35 of the Data Protection Act, 2019 gives people rights over decisions based solely on automated processing that significantly affect them. Where that applies, design the system to prepare the decision well and let a person make it.

Designing for failure

In a system with many steps, something will fail: a tool times out, a model returns something unexpected, a service is down. Good design assumes this:

• Timeouts and retries with limits, so one slow step does not hang everything.
• Safe retries: an action repeated after a failure, such as "send payment", must not happen twice. Give each action a unique identifier and have the receiving system ignore repeats. Engineers call this making the action idempotent.
• Checks between steps: validate each output before the next step uses it, and stop the chain when a check fails.
• Fallbacks: when the system cannot finish, it hands the case to a person with everything gathered so far, rather than guessing.
• Budgets on steps, time and cost for the whole task, not only for each agent.
• A full record of every step, input, output and decision, so failures can be traced and explained.

Judge a design less by how it behaves when everything works, and more by what happens when one part goes wrong.

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.