Lesson 2: The Platforms in Practice
By the end of this lesson, you will be able to:
- Compare the major platforms across capability, limitations, risk profile, pricing, and organisational fit (K8, K9, S25, K7)
- Read each platform family's strengths and limits against the five evaluation questions (K8, K9)
- Recognise how different pricing models (per-task, per-operation, per-user, credit-based) affect real cost at your project's volume (K8, S25)
- Map the features your own project needs against what candidate platforms offer, distinguishing must-haves from nice-to-haves (K8, S27)
How to use this lesson
This lesson is a reference, not a narrative. It works through the five reading questions from Lesson 1 for the platforms in each family:
- What can it do? — its capability
- Where does it stop? — its limitations
- What are the risks? — its risk profile
- What does it cost? — its pricing model
- Who is it for? — its organisational fit
You are not expected to memorise the detail. You are expected to know where to find it, how to read it, and how to apply it to your own project. The comparison tables below are designed to be returned to when you weigh platforms for your own project, not absorbed in one pass. The specifics will change; the structure of the comparison is what stays useful.
A standing caution applies to everything in this lesson. Platform capabilities and pricing change frequently. Every figure here is a snapshot for teaching, and your evaluation must confirm current specifics against each platform's own documentation. The lesson teaches you how to compare. It does not replace checking.
Where the platform runs: cloud, SaaS, self-hosted, and on-premise
Before the family tables, one piece of vocabulary you need to read the risk profile row of every table below. When a platform's terms say your data "passes through their infrastructure", or that a platform "can be self-hosted", they are describing where the software actually runs and where your data physically lives. That is one of the biggest levers on capability, risk, and cost. There are three arrangements worth knowing.
- Cloud-based / SaaS (software-as-a-service). You log in to the vendor's website and use software the vendor runs for you on the vendor's servers. Your data lives on their infrastructure, under their data-processing terms. You pay a subscription or per-usage fee and you cannot modify the underlying tool. This is a third-party solution: a supplier holds and processes your data on your behalf. Zapier, Make.com, Power Automate, and Copilot Studio are all SaaS.
- Self-hosted. The vendor gives you the software (often open-source) and you install and run it on infrastructure you control — typically a server you rent from a cloud provider. Your data lives on your server, you pay for the server rather than per action, and you can usually modify the tool. You take on the responsibility of keeping it running, patched, and backed up. n8n is the main self-hostable platform in this module.
- On-premise. A special case of self-hosting where the server sits on hardware the organisation physically owns and operates, inside its own building or private data centre — nothing leaves the organisation's walls. This gives the tightest data control and is sometimes mandated in highly regulated settings, at the highest infrastructure and maintenance cost.
The clearest way to feel the difference is to read one SaaS platform against one self-hosted platform doing comparable work.
| Power Automate (cloud / SaaS) | Self-hosted n8n | |
|---|---|---|
| Who runs it | You log in to Microsoft's website; Microsoft's computers run your automations. | You rent a small server (e.g. from DigitalOcean for a few pounds a month), install n8n, and your own server runs your automations. |
| Where your data lives | On Microsoft's servers, under Microsoft's data-processing terms. | On your server, under your control. |
| What you pay for | Per action (a "unit" of work), on a subscription. | The server rental only — unlimited automations for a fixed infrastructure cost. |
| Can you change the tool? | No — you use it as Microsoft ships it. | Yes — you can modify n8n's code for custom features. |
| Who keeps it running | Microsoft: uptime, patching, and backups are their responsibility. | You: keeping the server running, patched, and backed up is your responsibility. |
When to pick each. Choose SaaS when you want zero infrastructure hassle, don't mind paying per action, and are comfortable trusting the vendor with your data — most organisations, most of the time. Choose self-hosted (or on-premise) when a compliance or data-residency constraint means the data cannot sit on a third party's servers, when you have enough volume that per-action pricing gets expensive, or when you need to customise the tool itself — and you have the technical capacity to run a server responsibly. The trade is always the same: SaaS buys convenience by handing over control; self-hosting buys control by taking on responsibility.
The workflow-first family
Zapier and Microsoft Power Automate are the two leading workflow-first platforms. Both are built for deterministic trigger-and-action automation, with AI added as a layer.
| Reading question | Zapier | Microsoft Power Automate |
|---|---|---|
| Capability | Very broad connector library (thousands of apps), simple visual builder, AI features added through built-in steps and an agents feature. Built for accessibility above all. | Broad connector library, embedded AI through AI Builder, deep Microsoft 365 integration, desktop automation through Power Automate Desktop. |
| Limitations | Custom logic is limited; complex branching gets awkward. Per-task pricing can escalate at high volume. Fully agentic behaviour is newer and less mature than dedicated agentic platforms. | Fully agentic behaviour is limited; the AI is task-level, not a reasoning core. Strongest only when the organisation is already on Microsoft 365. |
| Risk profile | Data passes through Zapier's infrastructure; review the data processing terms for sensitive data. Vendor dependency is moderate; workflows are not portable. | Data stays within the Microsoft service boundary, which suits Microsoft-committed organisations. Vendor dependency is high once deeply embedded. |
| Pricing model | Per-task pricing on tiered plans; cost rises with execution volume. | Per-user or per-flow plans; cost is predictable for steady-state automation. Often already partly licensed within an M365 subscription. |
| Organisational fit | Small to medium organisations, cross-app automation, teams wanting the fastest path to a working automation. | Organisations already on Microsoft 365 running fixed or AI-augmented workflows. |
You have already watched a workflow-first platform doing exactly this kind of work. The customer-feedback automation in Module 1, Unit 2, Demo 1 was built in Power Automate: a fixed sequence that runs the same path on every record, branching only on a sentiment label computed in advance. It is worth revisiting now as the reference point for what this family does well — a predictable, high-volume process whose steps are known before the workflow runs. Hold it in mind as you read the agentic family below, because the contrast between that fixed path and an agent that chooses its own path at runtime is what separates the two families in practice.
The agentic automation family
Make.com and n8n are the two leading agentic automation platforms. Both place LLM reasoning closer to the centre of execution and support genuine multi-step agent behaviour.
| Reading question | Make.com | n8n |
|---|---|---|
| Capability | Visual scenario builder with strong branching and routing, a dedicated AI Agent module, broad connector coverage. More visual and approachable than n8n while still supporting agentic patterns. | Mature AI Agent node exposing full agent anatomy, custom JavaScript function nodes, self-hosting option. The most flexible of the no-code and low-code agentic options. |
| Limitations | Operations-based pricing can become hard to predict for complex agentic scenarios that make many internal calls. Self-hosting is not available. | Higher skill floor; the flexibility rewards technical fluency. Self-hosting shifts infrastructure responsibility onto your team. |
| Risk profile | Cloud-hosted; data passes through Make.com infrastructure under their terms. Vendor dependency is moderate. | Self-hosting option gives strong data control; cloud option passes data through n8n infrastructure. Open-source core reduces lock-in. |
| Pricing model | Per-operation pricing on tiered plans; an agentic scenario can consume many operations per run. | Execution-based pricing on cloud plans, or infrastructure-only cost when self-hosted. |
| Organisational fit | Teams wanting agentic capability with a more visual, approachable builder. | Teams with some technical fluency building agentic workflows that need flexibility or strong data control. |
The terms "per task", "per operation", and "per execution" sound similar but are charged very differently. A single agentic run can be one execution but many operations — which is why an agentic scenario on operations-based pricing can cost far more than the headline plan price suggests. When comparing costs, always ask what a single realistic run actually costs at your expected volume, not just the plan entry price.
The AI assistant ecosystem family
Microsoft Copilot Studio is the leading example. It puts an AI assistant at the centre, with automation built around the conversation.
| Reading question | Microsoft Copilot Studio |
|---|---|
| Capability | Build custom internal or external agents grounded in your organisation's data through Microsoft Graph. Connects to Power Automate flows as agent actions. Supports generative orchestration, where the agent decides which actions to take. |
| Limitations | Reaches its best only within the Microsoft ecosystem. Credit-based consumption can be hard to forecast for high-traffic agents. Less suited to cross-vendor automation that lives outside Microsoft. |
| Risk profile | Data stays within the M365 service boundary, with admin governance and enterprise data protection. Vendor dependency is high. Governance maturity is strong for Microsoft-committed organisations. |
| Pricing model | Credit-based; a set number of credits per month for a fixed price, consumed as agents run. Forecasting requires estimating agent traffic. |
| Organisational fit | Organisations deeply embedded in Microsoft 365 building conversational AI or internal knowledge agents. |
The AI-native productivity family
Claude Cowork and Google Workspace Studio are the leading examples. The AI capability is the product, oriented around files, documents, and tasks rather than around a built workflow.
| Reading question | Claude Cowork | Google Workspace Studio |
|---|---|---|
| Capability | Agentic file and task management on the desktop for non-developers, able to work across documents, spreadsheets, and connected tools through a conversational interface backed by Claude's models. | AI-native automation and app-building inside Google Workspace, oriented around Docs, Sheets, and Gmail, for organisations already on Google's suite. |
| Limitations | Integration breadth is narrower than a mature workflow-first platform's connector library. Best suited to work dominated by documents and files rather than high-volume system-to-system automation. | Strongest only within the Google ecosystem. Less suited to organisations not already on Google Workspace. |
| Risk profile | Business and enterprise tiers do not train on your data and carry security commitments; confirm the current data terms for your tier. | Data handling governed by Google Workspace terms; business tiers do not train foundation models on your data. |
| Pricing model | Subscription tied to Claude plans; confirm current business and enterprise terms. | Tied to Google Workspace subscription tiers. |
| Organisational fit | Knowledge workers and teams whose automation is dominated by document and file work, especially those already using Claude. | Organisations already on Google Workspace wanting AI-native automation inside that suite. |
Before you fall in love with any platform, check one thing first: can it actually connect to the systems your project depends on? You can pick the perfect family with the ideal pricing and the strongest governance, but if the specific app your automation must touch has no API, no MCP server, and no ready-made connector, the platform cannot reach it — no matter how capable it is. Connectivity is a gate, not a nice-to-have. Put "does a connector or API exist for every system I need?" at the top of your must-have list, and confirm it before anything else.
[MAP IT WITH YOUR COMPANION — 15 minutes] Draft your project's platform feature-map, then make the judgements yourself.
Project — Platform Feature Map
Map the features your real project needs against candidate platforms. Draft it with your Companion, then make the calls yourself. Complete it in one go and save as a md file. Save the md file within the same source folder you've given Evidence Companion access.
⏭️ Up next - Lesson 3: You can now read a platform and match features to needs. The final lesson of this unit adds the piece that decides between two capable platforms: how your sector and context — above all your data sensitivity — set the constraints, and how to curate what your Companion is actually allowed to know.