Lesson 1: What We Mean by AI, and How Workflows and Agents Differ

Unit 1 | Lesson 1 of 4

By the end of this lesson, you will be able to:

• Distinguish between predictive AI, generative AI, rule-based automation, and agentic AI, and identify where this module focuses (K9, K7)
• Describe the difference between workflow automation and agentic AI behaviour, with reference to your own project context (K9)
• Map the five components of agent anatomy to their equivalents in a no-code platform interface (K9)
• Identify the platform configuration questions that follow from understanding agent anatomy (K9, K25)
• Build the first version of your Evidence Companion — the assistant you will build and improve across Modules 3–8 — write its first system prompt, and place its job on the workflow spectrum (K9)

Meet your Evidence Companion

Module 3 introduces something you will carry through the rest of the programme: your Evidence Companion. Over Module 3 you will build this small AI assistant, and from Module 5 through Module 8 you will keep improving it. It takes the place of the workbooks you used in earlier modules — from here on, the Companion and the evidence you build with it are the assessment artefact you develop across Modules 3–8. (Note this is a separate thing from the real-world project you defined back in Module 1; the Companion is the assistant you build, and your Module 1 project is the work you use it to reason about.)

Your Evidence Companion is not your workplace automation or project solution. It is a separate AI assistant that helps you work with the evidence from your project — it does not build, run, operate, or monitor that project. You give it access to project materials you have already saved: notes, data, prompts, screenshots, process documents, testing results, recordings. It can then help you remember what you did, find relevant evidence, and structure your experience against assessment criteria. If your project's automation sends a stock alert or triggers a workflow step, the Companion has no part in running that — it only helps you evidence that you built, tested, and reasoned about it.

✅ Good Companion request: "Based only on my saved project evidence, help me identify examples of how I tested and debugged my automation workflow."

❌ Not the Companion's job: "Monitor my inventory and notify me when stock is low." That is a requirement of the workplace automation itself — something your project might do — not something the Evidence Companion ever does.

Its job is to help you capture evidence of your own AI-transformation work: drafting short evidence entries, summarising a workflow you have improved, and reflecting on how each new skill applies in your workplace. You build it by configuring a no-code assistant — in Claude Cowork or a Microsoft Copilot agent — which is itself one of the core skills a transformation specialist needs.

You only need to build in one of the two tools; whichever you already have access to. Throughout the module you will see the same steps demonstrated in both Claude and Copilot, so you can follow along whichever you choose — and by Unit 3 you will be able to reason about which one you would actually recommend. If the only tool you have is ChatGPT, you can still follow along: create a ChatGPT Agent and apply the same steps — the concepts are identical, even though we do not demonstrate them in ChatGPT. One practical note: Claude Cowork and ChatGPT Agent are both paid-plan features (as is a Microsoft Copilot agent, through a work licence), so use whichever your existing access already covers.

Crucially, the Companion is a drafting and thinking aid, not a ghostwriter. The evidence it helps you produce must be your own work and your own judgement. Its value is in helping you structure and sharpen what you did — never in inventing it for you.

Treat every Companion output as a first draft to interrogate, not a finished answer to submit. Your learning — and your assessment — depends on the reasoning being yours. A good habit from day one: start every request with your own rough notes ("here is what I actually did…") and ask the Companion to help you shape them, never to conjure evidence from nothing.

Each lesson from here adds one decision to your Companion. This lesson's decision is the first and most fundamental: what kind of system is it, and what is its one job? To answer that well, you need the two ideas the rest of this lesson builds — the workflow spectrum and the anatomy of an agent.

Revisiting what we mean by AI

You met the AI landscape in Module 1; here we revisit it with the distinctions that matter for platform selection. You will hear the term "AI" used to describe many different things. A bank uses AI to detect fraudulent card transactions. A streaming service uses AI to recommend the next programme. Your phone uses AI to autocorrect the message you are writing. The customer service chatbot on a retailer's website also uses AI. These systems are all AI, but they do not work in the same way and they do not raise the same design questions.

For this module, it helps to hold four terms separately in mind.

Predictive AI, sometimes called classical machine learning, looks at historical data, finds patterns, and uses them to produce a prediction or a classification. Fraud detection (is this transaction likely to be fraudulent?), demand forecasting (how many of these will we need next month?), and recommendation engines (which film is this user likely to enjoy?) sit here. These systems are powerful, often invisible, and rarely the centre of an AI automation project. You will meet them at awareness level only in this module.

Generative AI is the family of large language models you have heard described as GPT, Claude, Gemini, or Llama. Where predictive AI produces a label or a number, generative AI produces new content: a written paragraph, a structured table, a code snippet, an image, or an audio file, based on patterns learned from very large bodies of text and other media. When this module talks about AI, this is almost always what it means. Generative models sit at the centre of every platform you will study from Unit 2 onwards.

Automation, the rule-based and deterministic kind, is older than AI by several decades. "When this email arrives, save the attachment to that folder" is automation. It is not AI. The interesting work in this module begins where automation and generative AI combine into a single workflow.

Agentic AI is what you get when a generative AI model is given a goal, a set of tools it can use, and the freedom to decide its own path to the goal. An agent is not a new kind of model. It is a way of using a model that gives it more autonomy than a standard prompt-and-response.

These four are not in competition. A mature AI automation project will frequently combine them. The design questions, the risks, and the platform choices differ depending on which one you are working with. The rest of this lesson focuses on the distinction that matters most for platform selection: workflow versus agent.

The workflow spectrum

In Module 1 you met the basic distinction between rule-based automation and agentic AI. This lesson takes it further by placing the two on a spectrum and naming a third, middle position that covers most real-world implementations.

The honest framing is that "workflow" is a generic word. Any orchestrated sequence of automated steps is a workflow, including the agent-driven ones you will hear called "agentic workflows" in industry conversation. What differs across workflows is not whether they are workflows, but how much of the sequence is decided by the designer in advance and how much is decided by an LLM at runtime.

A fixed workflow is one where the designer specifies every step in advance. What happens first, what happens next, and what happens if a particular condition is met or missed is determined when the workflow is built. The result is reliable, predictable, auditable, and brittle when something unexpected occurs. A Power Automate flow that watches an inbox, extracts an invoice number, looks it up in a finance system, and flags any mismatch is a fixed workflow. Most use of no-code platforms since the category began has been of this kind.

An AI-augmented workflow is a fixed workflow with one or more LLM steps embedded inside it. The overall path is still specified in advance, but at certain points the workflow hands a task to a language model: classify this email, summarise this document, draft this reply, extract these fields. The model does its task, returns a result, and the workflow continues along its pre-defined path. Microsoft's AI Builder, used inside Power Automate, is designed for exactly this pattern. The path is fixed; specific cognitive tasks within the path are delegated to an LLM.

An agentic workflow is one where an LLM, given a goal and a set of tools, decides the sequence itself. The designer specifies what the agent is trying to achieve and what it has at its disposal. The agent decides which tools to use, in what order, and when it has done enough. The result is adaptive, capable of handling ambiguity, harder to audit, and more expensive to run. Anthropic's Claude Cowork is one example: handed a goal like "work through this feedback inbox and draft suitable responses," it decides for itself which steps to take and in what order, rather than following a path you laid out in advance.

🔑 Three positions on the workflow spectrum: A fixed workflow is built entirely by the designer. An AI-augmented workflow is a designer-built sequence with LLM tasks embedded inside it. An agentic workflow has the LLM deciding the sequence within the boundaries the designer sets.

Most real-world implementations sit on this spectrum rather than at one of its ends. The same project can have one fixed part, one AI-augmented part, and one agentic part. Learning to recognise where each piece of your project sits, and why, is a core practitioner skill that you will practise throughout this module, beginning with the Evidence Companion you design at the end of this lesson.

Take the customer feedback automation you met in Module 1. As a fixed workflow, it might receive feedback, route it by keyword match (the word "complaint" or "thank you" appearing in the body) to either a templated reply or a human review queue. As an AI-augmented workflow, the same flow uses an LLM step to classify sentiment more accurately than keyword matching, and a second LLM step to draft a personalised reply rather than send a template. As an agentic workflow, the system receives a higher-level goal: respond appropriately to this customer's feedback. The agent might look up the customer's order history, decide that a particular complaint requires escalation, draft an acknowledgement, or recommend a discount, depending on what the situation calls for.

The three versions are not three quality levels with "agentic" at the top. They are three design choices with different costs, different risks, and different fit to the use case. The choice between them is rarely about which is most impressive. It is about how much of your use case can be specified in advance and how much benefits from being decided at runtime.

Agent anatomy in plain language

When you work with an agent inside a no-code platform, you are not interacting with one thing called "the agent". You are configuring five components that work together. Knowing what each component does makes the platform interface much easier to read.

The orchestration loop is the most technically complex of the five components. If this is your first time encountering it, slow down here. The text below walks through it step by step — read it twice if you need to before moving on.

1. The LLM core is the reasoning engine. It receives a prompt that includes the agent's instructions, the goal, the available tools, and the conversation so far. It returns a decision: either a final answer or a request to use one of the tools. This is where the generative AI lives. Every other component exists to serve this loop.

2. The tool layer is the set of actions the agent can take. A tool might be a web search, an API call to a CRM, a database lookup, a calculation, or a hand-off to another workflow. The designer decides which tools the agent has access to. The agent decides when to use them. Tools are the single most consequential configuration choice you will make: an agent without the right tools cannot do its job, and an agent with too many tools spends too much time deciding which one to pick.

🔑 A few terms that come up around tools:

• API (application programming interface) — the standard way one piece of software talks to another, so "an API call to a CRM" means the agent programmatically asks that system to do something or hand back data.
• CRM (customer relationship management system, e.g. Salesforce or HubSpot) — where an organisation stores its customer records.
• MCP (Model Context Protocol) — a newer, standardised way of giving an AI model access to tools and data sources; increasingly the main way we connect an agent to the tools it needs. We will come back to this term in the future modules.

3. Memory is the in-context history of what has happened in this run. The agent remembers what it has tried, what each tool returned, and what conclusions it has reached so far. This is different from long-term memory across sessions, which most no-code agents do not have by default. Each run typically starts fresh.

🔑 Memory in this context: the agent's working knowledge of what has happened so far in the current run. It is not the same as memory of past conversations or organisational data.

4. The orchestration loop is the cycle that holds the whole thing together: the platform submits the current state to the LLM, receives a decision, executes the chosen tool if there is one, feeds the result back to the LLM, and repeats. You rarely write this loop yourself. The platform manages it. Understanding that it exists, though, explains why every agent needs the final component.

5. The iteration limit is the maximum number of times the loop can run before the agent is forced to stop. Set it too low, and the agent will sometimes stop before reaching a useful conclusion. Set it too high, and a confused agent can burn through hundreds of model calls trying to recover from a problem it cannot solve. Setting this number, or the platform's equivalent setting, is one of the decisions that determines whether an agent stops too early or runs too long.

Note: How explicitly you will meet this setting depends on the platform you are using. In n8n's AI Agent node it appears as a numeric field labelled Max iterations, visible the moment you open the node configuration. In Microsoft Copilot Studio the same concept is split across the maximum conversation length setting and per-turn token limits, and tends to surface only when a learner is debugging an agent that stops before producing a useful answer. In Power Automate cloud flows that use AI Builder for one-shot tasks such as text classification or entity extraction, the iteration limit does not apply at all, because those flows do not loop. Knowing that the concept exists is what lets you ask the right diagnostic question when an agent in any platform behaves unexpectedly, even when the platform's label for the setting is different from anyone else's.

Click to enlarge

Did you know?

The iteration limit being reached is one of the most common reasons an agent run fails in production — yet it rarely gets attention. Most troubleshooting guides focus on prompt design. In practice, a misconfigured iteration limit causes just as many silent failures, and it is one of the first things worth checking when an agent returns an incomplete result.

What this looks like in a real platform

In Make.com, the AI Agent module brings several of the agent anatomy components into one configuration panel, but the mapping is not perfectly one-to-one. The model dropdown and reasoning effort setting represent the LLM core: this is the reasoning engine that interprets the current state and decides what to do next. The Instructions field sets the agent’s role, goal, workflow steps and behaviour. The Input, Input files, Conversation ID and Maximum conversation history fields shape the context the agent can use during a run, including what it receives now and how much recent interaction history it can refer back to.

The tool layer appears outside the main settings list, through options such as Add tool and Add MCP. These are the actions and external capabilities the agent can use, such as calling another module, searching data, or interacting with another system.

The orchestration loop is not shown as a single field. Make.com manages it behind the scenes: the platform sends the current state to the model, receives a decision, executes a tool if needed, feeds the result back, and repeats until the agent completes the task or reaches a configured limit. In the current interface, settings such as step limits, conversation history and step timeout act as runtime controls. Step timeout is not the same as an iteration limit; it limits how long an individual step can run. If your Make.com interface exposes a “steps per run” or equivalent setting inside Model configuration, that is the closest match to the iteration limit.

Click to enlarge

The point of showing this example is not to teach Make.com specifically. It is to make the anatomy concrete. Every no-code platform with agent capability exposes these components in some way, even if the labels and the layout differ or not as visible to users. Once you can read one platform's agent configuration in anatomy terms, you can apply the knowledge to other platform's.

Build your Evidence Companion (first version)

You now know the two ideas that shape a good Companion: the workflow spectrum and agent anatomy. Time to turn that into a working assistant. This first version is deliberately simple — you will refine it in every lesson that follows. A system prompt is the persistent instruction that steers everything it does — you will see exactly why small changes in its wording change its behaviour once you know how the model underneath it works, in the next lesson.

A normal chat vs an agent

You have almost certainly already had a normal AI chat conversation — in Claude.ai, ChatGPT, or Copilot Chat. That works, but you have to re-explain your context every time you open a new chat. An agent (a Claude Cowork project, a Copilot agent) is different: it carries persistent instructions — the system prompt you are about to write — and can hold a defined knowledge source it can refer back to, so its answers stay consistent and project-specific instead of starting from zero each time. That does not make it automatically reliable. You still check what it produces against your own evidence, the same as you would a normal chat — the difference is convenience and consistency, not trustworthiness.

Your organisation's settings may limit which knowledge sources you can add. File upload, OneDrive, SharePoint, and Copilot agent features can all require a specific licence or IT approval. If an option is unavailable, blocked, or asks for a Microsoft 365 Copilot licence you don't have, do not spend excessive time troubleshooting it. Keep saving your evidence to your shared project folder (see Lesson 1) and return to agent setup once your access is sorted.

A few terms that come up from here on, kept separate on purpose:

• Save as Markdown — downloads this activity's answer as a file, for you to keep in your project evidence folder.

🔑 Markdown (.md file): a plain-text file that uses a few simple symbols to add structure — # for headings, - for bullet points, ** for bold. Think of it as a notepad file that can still show formatting, and it opens in any text editor on any device. It is a favourite format for working with AI: because the structure is written in plain text rather than the hidden formatting code inside a Word document or PDF, a model can read it cleanly and uses far fewer tokens to take in the same content.

• Copy to clipboard — copies text, such as an agent instruction, ready to paste into your agent's configuration.
• Shared folder — where you save and organise your evidence. This remains the source of truth for your files; the agent does not replace it.
• Agent knowledge source — an optional connection that lets the agent read evidence you have already saved. It is a way of pointing the agent at your folder, not a second place where your evidence lives.

Setting up in Claude Cowork

Claude Cowork is Anthropic's agentic workspace — a dedicated environment where Claude works alongside you on your own files rather than just answering questions in a chat window. In this walkthrough, you will see how to create a project, give your Evidence Companion its first system prompt, and then hand it a real goal to work towards. The key moment to watch for is the planning step: before the agent touches any file, it lays out what it intends to do so you can review its approach first.

Setting up in Microsoft Copilot

If your project work already lives in Microsoft 365, a Copilot agent lets you build the Evidence Companion right where your files sit — no code required, and reusable across the tools you already use. This walkthrough shows how to create the agent, give it the system prompt you drafted above, attach your OneDrive knowledge, and then use it the way its instructions describe.

[BUILD IT — 15 minutes] Create your Companion and write its first instructions

1. Create the assistant. In Claude, set up Claude Cowork; in Copilot, create a new agent. You only need one. Name it, and if you are prompted for a description, use the "one job" sentence you just wrote above.
2. Write its system prompt. This is the instruction that shapes everything it does. Copy the one you just assembled above
3. Test it. Give it a few genuine rough notes from your own work and read how it responds.

If you are blocked:

• Agent setup itself blocked? Complete this lesson's artefacts on paper, save them, and revisit the agent build once your access is available.
• Lack of agent access is never a reason to stop collecting evidence — only a reason to keep it in your shared folder for now.

Quick Check

⏭️ Up next - Lesson 2: What happens inside that LLM core, and why it sometimes produces confidently incorrect answers, sets up everything that follows in this module.