Lesson 1: The Four Platform Families and How to Read Any Platform

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

• Name the four platform families and describe the design philosophy that distinguishes each (K8, K9)
• Read an unfamiliar platform by asking a consistent set of practitioner questions rather than relying on its marketing (K8, S25, K7)
• Match the four-family framework to your own project, using your Companion as a thinking aid rather than the subject of the analysis (K8, K9, S27)
• Explain why platform choice is a consequential, hard-to-reverse commitment (K8, K9)

Reading a platform by what it was built for

Unit 1 looked at the model layer, the LLM that reasons inside your automation. This unit turns to the platform layer that wraps it. There are many ways to sort the platform landscape, but the one that matters most for selection is what each platform was built to do. That design philosophy tells you where a platform will excel and where it will struggle more reliably than any feature list, including features added long after the platform's original purpose.

This unit uses a four-family framework for exactly that purpose. Each family groups platforms by the kind of work they were designed around. Knowing a platform's family is the fastest way to predict whether it fits your project, often before you have read a single page of its documentation.

The four families

The families are not a ranking. If you find yourself wanting to know which one wins, redirect that instinct — the skill here is matching a family to your project's needs, not scoring them against each other. Each family is the best choice for a particular kind of work and a poor choice for others.

Workflow-first platforms were built for deterministic, trigger-and-action automation. Something happens (an email arrives, a form is submitted, a record changes), and the platform runs a fixed sequence in response. AI capabilities were added as a layer on top of this foundation rather than built into the core. These platforms are strongest for reliable, high-volume process automation where the inputs and outputs are predictable. Zapier and Microsoft Power Automate are the leading examples. If your project is a fixed workflow, or a fixed workflow with a few embedded AI steps, this family is usually where you start.

Agentic automation platforms were built or significantly extended for genuine multi-step agent behaviour, with LLM reasoning at the centre of execution rather than bolted on. These platforms are strongest for adaptive, goal-driven automation where the path cannot be fully defined in advance. Make.com and n8n are the leading examples. If your project is an agentic workflow, this family is where the capability you need actually lives.

AI assistant ecosystems put an AI assistant at the centre as the primary interface, with automation built around it. The assistant is what the user talks to; the automation happens behind that conversation. These platforms are strongest for conversational AI, internal knowledge agents that answer staff questions from company documents, and organisations already deeply embedded in their surrounding software suite. Microsoft Copilot Studio is the leading example, and its natural home is an organisation already running on Microsoft 365.

AI-native productivity tools are products where the AI capability is the entire point, not a feature added to something else. These tools are strongest for file and task management automation, document generation, and organisations already working inside the matching productivity suite. Anthropic's Claude Cowork and Google Workspace Studio are the leading examples. Where an AI assistant ecosystem is built around a conversation, an AI-native productivity tool is built around getting work done with files and tasks.

Click to enlarge

Did you know?

Microsoft Copilot Studio and Microsoft Power Automate are made by the same company yet sit in different platform families. Power Automate is workflow-first; Copilot Studio is an AI assistant ecosystem. They are designed to work together, and a single project can use both. This is a useful reminder that families describe design philosophy, not corporate ownership.

How to read any platform

The six or so platforms in this module are a snapshot. New platforms appear constantly, and the ones covered here will change their capabilities and pricing while you are still on the programme. A practitioner who has memorised today's feature lists has learned something with a short shelf life. A practitioner who has learned how to interrogate any platform has learned something durable.

For any platform you evaluate, ask the same five questions. You will recognise these as the structure the next lesson uses to compare the platforms in detail.

What can it do? Its capabilities. What kinds of automation is it built for? Does it support agentic behaviour, and if so, how mature is that support? How broad is its library of connectors to other systems? This is the question marketing answers most loudly, so treat the marketing as a starting point and confirm specifics against documentation.

Where does it stop? Its limitations. Every platform has an edge where it stops being the right tool and you need a workaround or a different platform. Knowing the edge in advance is more useful than discovering it mid-build. A platform that does ninety per cent of what you need cheaply may still be the wrong choice if the missing ten per cent is the part that matters most.

What are the risks? Its risk profile. How does it handle your data? Where is that data stored, and under whose terms? How dependent would you become on this single vendor? How mature is its governance and security posture? What happens when a workflow fails partway through?

What does it cost? Its pricing model. How does it charge: per seat, per task, per execution, per token, per credit? What does a realistic monthly bill look like at your project's actual volume, rather than at the headline entry price? Pricing models differ so much between families that a platform that looks cheap at low volume can become the most expensive option at scale.

Who is it for? Its organisational fit. What kind of project and what kind of organisation does it suit best? A platform that is technically capable but needs skills your team does not have is not a practical choice, however impressive it is.

🔑 The five reading questions: capability, limitations, risk profile, pricing, and organisational fit. These five questions work on any platform, including ones that do not exist yet. Learning the questions matters more than learning any single platform's current answers.

One use case, two families

The fastest way to see the five questions working is to watch them applied. The artefact below takes a single use case — the customer feedback automation from Unit 1 — and reads it through all five questions against two platforms from different families: Microsoft Power Automate (workflow-first) and n8n (agentic). Read down a single question and compare the two columns: the same question produces a different answer depending on what each platform was built for. The next lesson does this thoroughly for the full set of platforms; this one is a demonstration of method.

Notice that neither read concludes "this is the best platform". Each concludes "this is what it is for" — exactly the judgement the five questions are designed to produce.

Why platform choice has consequences

Reading a platform well matters because the choice is not a casual one. Once a project is built on a platform, several things become hard to undo.

Skill investment. The team's learning curve was spent on that platform's conventions, its expression language, its debugging tools, and its quirks. Switching means relearning. This is true even between two platforms in the same family. Power Automate and Zapier are conceptually similar but practically different enough that productive use in one does not transfer wholesale to the other. Multiply that effect across a team of five practitioners and the switching cost is significant.

Data location. The data that flows through the platform (customer records, transaction history, internal documents) lives in that platform's storage, in that platform's region, under that platform's data processing terms. Migrating means moving the data, which means new contracts, new security reviews, and new compliance work.

Workflow lock-in. Workflows built in a no-code platform are not portable. There is no standard format for an automation that other platforms can import. Migration usually means rebuilding from scratch, with the original platform running in parallel until the rebuild has been validated.

Integration coupling. Once a platform is the connective tissue between three other systems, those three systems have effectively been re-architected around the platform's APIs. Replacing the platform means rewriting those integrations and re-testing every dependency.

None of this is a reason to avoid choosing. It is a reason to choose deliberately, knowing that the choice is the start of a multi-year relationship with whichever platform you pick, not a casual selection. This is exactly why the five reading questions are worth applying before you commit, not after.

Put your Companion to work: which family fits your project?

From here on, your Evidence Companion changes role. In Unit 1 you built and configured it; from now on it is the assistant you think with as you work on your real project — the one you defined back in Module 1. Every decision from this point is about your project, not about the Companion. (For the record, the Companion is the assistant you think with, not the subject of this analysis: the thing under evaluation is your real project and which platform family fits it, not the tool you happen to be using to reason about it.)

So make the framework earn its place on something real. Which of the four families is the natural home for your project, given the shape you defined in Module 1?

Already finished your Module 1 project? You have a choice. You can run this platform analysis on that same project — re-evaluating and reconfirming the platform choice is still a worthwhile exercise, and often surfaces things you would do differently. Or, if you would rather work on something fresh, pick another candidate from your Module 1 shortlist and carry that one through the rest of the module. Either path works.

[TRY IT WITH YOUR COMPANION — 10 minutes]

Step 1 — Give your Companion your project context. Your Companion can only reason about your project if it can see it. Save or export the project documentation you already have — your Module 2 workbook (the Project Definition Pack), or an individual workbook such as your Module 1, Unit 5 work — and upload it into your Companion's knowledge (the files you connect to Claude Cowork, or a Copilot agent's knowledge). This becomes the Companion's knowledge base for the rest of the module. If you are on a consumer tier, or unsure about anything in the document, upload a high-level or redacted version for now — you will apply a full "safe to upload / never upload" check in Lesson 3.

Step 2 — Ask which family fits, then push back. Adapt the prompt below to your project, copy it into your Companion, and read its answer critically. You are not accepting its verdict; you are using it to sharpen your own thinking.

Keep the Companion's family recommendation and your own view of it — you will bring both into the five-dimension assessment in Unit 3 and confirm the choice with your consultant if you haven't already done so.

💬 Reflection prompt: For your own project, which single fact about it — the predictability of the process, the sensitivity of the data, or the systems it must touch — most strongly pulls it toward one family and away from another? If you cannot yet name that fact, that is the gap to close before Unit 3.

Quick Check

⏭️ Up next - Lesson 2: The next lesson answers the five reading questions for every platform across all four families, turning the framework into a side-by-side comparison you can return to during your shortlisting activity.