Quick Navigation
- Why the landscape feels overwhelming — and how to fix that
- Layer 1 — Foundation models: the engines underneath
- Layer 2 — AI assistants: the interface most people use
- Layer 3 — AI-native apps: purpose-built for one job
- Layer 4 — AI-embedded tools: what you already pay for
- Layer 5 — Platforms and APIs: building your own
- How to choose — four questions in order
- Building a team stack that actually holds together
- The selection framework in one diagram
- Cheat sheet
Why the landscape feels overwhelming — and how to fix that
A new AI tool launches approximately every forty-eight hours. Each one claims to be the best. Each one has a wait list, a viral demo, and a LinkedIn post calling it a "game changer."
Most people respond to this one of two ways. They either chase every new release, ending up with fifteen tools they half-know how to use. Or they pick one tool early, stay loyal to it, and miss things that would genuinely help them.
Neither is a good strategy. And both stem from the same problem: no mental map.
The thing is, the landscape only looks chaotic from the outside. Once you see the structure underneath it, it becomes manageable. Almost every AI tool that exists fits into one of five layers. New tools don't add chaos to the landscape — they just fill in a slot in a layer you already understand.
Here's the map:
flowchart TD
A["The AI Tools Landscape"] --> B["Layer 1: Foundation Models\nThe engines underneath everything else"]
A --> C["Layer 2: AI Assistants\nGeneral-purpose chat interfaces"]
A --> D["Layer 3: AI-Native Apps\nBuilt for one specific job"]
A --> E["Layer 4: AI-Embedded Tools\nYour existing tools, with AI added"]
A --> F["Layer 5: Platforms and APIs\nFor building custom AI solutions"]
Most people only interact with Layer 2 or Layer 4 — and occasionally Layer 3. But without understanding Layer 1, they make tool choices based on brand rather than substance. And without knowing Layer 5 exists, they don't know when to escalate from "use an existing tool" to "we need to build something."
The rest of this guide walks through each layer in turn, then gives you a framework for choosing between them.
Try it yourself — Your current tool inventory
List every AI tool you or your team currently uses — officially or unofficially. For each one, which layer does it belong to? How many tools are in your shadow inventory? That number tells you how much unmanaged AI adoption is happening.
| Tool | Layer (1-5) | Who uses it? | Approved or shadow? |
|---|---|---|---|
| e.g. ChatGPT | Layer 2 | Marketing team | Shadow |
If your shadow column is longer than your approved column, you've got a governance problem waiting to happen.
Layer 1 — Foundation models: the engines underneath
Here's something that confuses a lot of people. When ChatGPT launches a competitor, is that a new AI? When a startup says they built their own AI assistant, is it actually their AI?
Usually, no. Most AI products you interact with are interfaces — they're built on top of a small number of foundation models that do the actual work. Understanding which models exist, and what they're actually good at, is the most important piece of the puzzle that most people are missing.
The major model families right now:
flowchart TD
FM["Major Foundation Model Families"]
FM --> OAI["OpenAI\nGPT-5 · o3 · o4-mini\nBroadest ecosystem\nStrong across almost all tasks"]
FM --> ANT["Anthropic\nClaude 4 Opus · Claude 4 Sonnet\nStrong reasoning and long documents\nBuilt with safety as a design priority"]
FM --> GOO["Google DeepMind\nGemini 3 Pro · Flash\nDeep Google integration\nNatively multimodal"]
FM --> META["Meta\nLlama 4 — open source\nFree to use and fine-tune\nCan be self-hosted"]
FM --> MIS["Mistral\nMistral Large — open source\nEfficient · European data residency option"]
| Model family | Strongest at | Consider it when... |
|---|---|---|
| OpenAI GPT-5 / o3 | Broad capability, reasoning, coding, vision | You want a reliable general-purpose workhorse |
| Anthropic Claude 4 | Long documents, nuanced writing, careful instruction-following | You're working with lengthy material or need precision |
| Google Gemini 3 | Multimodal tasks, massive context, Google Workspace integration | You live in Google's ecosystem or need image/audio/video understanding |
| Meta Llama 4 | Open-source flexibility, self-hosted deployment | Your org needs full data control or can't send data to a vendor |
| Mistral | Efficient performance, EU data residency | You're in a European compliance context or optimising for cost |
For most everyday workplace tasks — drafting, summarising, explaining, brainstorming — the major models perform comparably. The decision between them usually comes down to integration, data residency, cost, and specific task requirements. Brand loyalty is a poor basis for the choice.
One distinction that matters more than most people realise: proprietary vs. open source.
Proprietary models (OpenAI, Anthropic, Google) are managed by the vendor — you access them via API or consumer product, you don't control the infrastructure, and your data handling depends on your agreement with that vendor. They tend to perform better on complex tasks out of the box.
Open-source models (Llama, Mistral) can be downloaded, modified, and run on your own servers. That means full data control, no vendor dependency, and the ability to fine-tune for your specific domain. The trade-off is that you're responsible for the infrastructure — and on many complex tasks, they still trail the frontier proprietary models.
For organisations with strict data residency requirements or sensitive proprietary data, open-source self-hosted deployment is sometimes the only compliant option. For everyone else, the managed proprietary models are typically the faster path.
Layer 2 — AI assistants: the interface most people use
This is the layer most people think of when they say "AI." ChatGPT, Claude, Gemini, Copilot — these are all AI assistants: chat interfaces that wrap a foundation model with memory features, tool access, and a consumer-friendly experience.
Understanding what's different between them — beyond branding — helps you pick the right one and stop wondering whether you're missing out on something better.
flowchart LR
ASS["Major AI Assistants"]
ASS --> CG["ChatGPT\nOpenAI · GPT-5\nLargest user base\nCode interpreter built in\nStrong plugin ecosystem"]
ASS --> CL["Claude.ai\nAnthropic · Claude 4\nLongest context window\nStrong on long documents\nCareful, nuanced reasoning"]
ASS --> GG["Google Gemini\nGemini 3\nNative Google Workspace integration\nMultimodal from the start\nReal-time web access"]
ASS --> MC["Microsoft Copilot\nGPT-5 via Microsoft\nBuilt into Windows and M365\nEnterprise compliance by default\nStays within your M365 tenant"]
ASS --> PP["Perplexity\nMultiple models\nSearch-first — finds sources first\nCitations on every answer\nBest for research tasks"]
Which one to reach for:
| What you need | Best choice |
|---|---|
| General daily use — writing, thinking, drafting | ChatGPT or Claude.ai |
| Analysing a document over 50 pages | Claude.ai — it holds more in context |
| Current information with verifiable sources | Perplexity |
| Working inside Google Docs, Gmail, or Sheets | Google Gemini |
| Working inside Word, Excel, Outlook, or Teams | Microsoft Copilot |
| Sensitive work data under enterprise compliance | Microsoft Copilot (M365 tenant) |
| Nuanced writing that needs to follow complex instructions | Claude.ai |
| Data analysis with code execution | ChatGPT with Code Interpreter |
One thing worth being explicit about: the tier you use matters more than the tool you pick.
Free tier assistants at most platforms are trained on older models, have lower usage limits, and — critically — may use your inputs to train future models. For any work involving sensitive data, client information, or proprietary content, the free tier is not appropriate.
Paid personal tiers (roughly $20/month) give you the latest model, higher limits, and file upload. Enterprise tiers go further — your data stays within your organisation's compliance boundary and is not used for training. For professional use with anything sensitive, enterprise-level agreements are the minimum threshold.
Layer 3 — AI-native apps: purpose-built for one job
General AI assistants are broad. They're the Swiss Army knife — useful for many things, excellent at none of them in particular. For certain tasks, a purpose-built tool will outperform a general assistant significantly.
AI-native apps are products where AI is the entire product — not a feature added to something else. They're built specifically for one modality or workflow, with interfaces and models optimised for that job alone.
flowchart TD
ANA["AI-Native Apps by Category"]
ANA --> IMG["Image Generation"]
ANA --> VID["Video Generation"]
ANA --> VOI["Voice and Audio"]
ANA --> COD["Code and Development"]
ANA --> DOC["Document and Research"]
ANA --> PRES["Presentations and Design"]
IMG --> I1["Midjourney — highest image quality"]
IMG --> I2["DALL-E 3 — integrated into ChatGPT"]
IMG --> I3["Adobe Firefly — IP-safe, creative suite"]
IMG --> I4["Stable Diffusion — open source, self-hosted"]
VID --> V1["Runway — video generation and editing"]
VID --> V2["Sora (OpenAI) — text to video"]
VID --> V3["Pika — short video creation"]
VOI --> VO1["ElevenLabs — voice cloning and synthesis"]
VOI --> VO2["Whisper — speech to text"]
VOI --> VO3["Descript — audio and video editing with AI"]
COD --> C1["GitHub Copilot — code completion in your IDE"]
COD --> C2["Cursor — AI-native code editor"]
COD --> C3["Replit — AI coding environment"]
DOC --> D1["Perplexity — AI search with citations"]
DOC --> D2["NotebookLM — document Q&A"]
DOC --> D3["Elicit — research paper analysis"]
PRES --> P1["Gamma — AI presentation builder"]
PRES --> P2["Canva AI — design with AI"]
When to use a native app versus a general assistant:
| Situation | Use a native app | Use a general assistant |
|---|---|---|
| Need high-quality images | ✅ Midjourney, Adobe Firefly | ❌ Image quality noticeably lower |
| Need code completion as you type | ✅ GitHub Copilot, Cursor | ❌ Copy-paste workflow is slower |
| Need to analyse 50 research papers | ✅ NotebookLM, Elicit | ⚠️ Possible but clunky |
| Need a voice-over for a video | ✅ ElevenLabs | ❌ Not designed for this |
| Need a draft email | ❌ Overkill | ✅ General assistant is fine |
| Need to brainstorm ideas | ❌ Overkill | ✅ General assistant is fine |
The reason native apps outperform general assistants on specialist tasks isn't mysterious. Language models are trained to predict text. For images, they're using diffusion models — a completely different architecture. For voice, neural text-to-speech systems. For code completion integrated into your editor, the tool has access to your entire codebase as context, not just what you paste into a chat window.
Different tools, different underlying technology, different results. When the task is specialist and quality matters, the native app wins.
Try it yourself — The native app test
Think of one specialist task you or your team does regularly — creating images, writing code, analysing research, producing voice-overs. What tool do you currently use? Is it a general assistant or a native app? If the answer to "would a native app be better?" is yes, that's your next tool evaluation.
| Task | Current tool | Native app alternative | Would it be better? |
|---|---|---|---|
| e.g. Creating marketing visuals | ChatGPT image generation | Midjourney | Yes — quality gap is significant |
Layer 4 — AI-embedded tools: what you already pay for
This is the layer most people underutilise — and often the highest-value starting point.
Before you sign up for a new AI tool, it's worth asking: does the software I already use every day have AI built in? In most cases, the answer is yes. Microsoft 365, Google Workspace, Notion, Grammarly, Slack, Zoom — all of them have had AI features added in the last two years, often included in licences organisations are already paying for.
flowchart LR
AE["AI-Embedded Tools by Category"]
AE --> PROD["Productivity and Writing"]
AE --> COLLAB["Collaboration"]
AE --> CRM["CRM and Sales"]
AE --> DATA["Data and Analytics"]
PROD --> P1["Microsoft 365 Copilot\nWord · Excel · PowerPoint · Outlook"]
PROD --> P2["Google Workspace AI\nDocs · Sheets · Gmail · Slides"]
PROD --> P3["Notion AI\nDrafting · Summarising · Database queries"]
PROD --> P4["Grammarly\nWriting assistance · Tone adjustment"]
COLLAB --> C1["Slack AI\nThread summaries · Search · Recaps"]
COLLAB --> C2["Zoom AI Companion\nMeeting summaries · Action items"]
COLLAB --> C3["Microsoft Teams Copilot\nMeeting notes · Chat summaries"]
CRM --> R1["Salesforce Einstein\nLead scoring · Email drafting · Insights"]
CRM --> R2["HubSpot AI\nContent generation · Forecasting"]
DATA --> D1["Tableau AI\nNatural language queries · Insights"]
DATA --> D2["Power BI Copilot\nReport generation · Q&A"]
The reason embedded tools are often the best starting point isn't just cost. It's context.
A general AI assistant knows only what you paste into the chat window. Microsoft Copilot, connected to your M365 tenant, knows your emails, your documents, your calendar, your Teams conversations. Google Workspace AI knows your Docs, your Drive, your Gmail history. That contextual access produces genuinely different — often better — outputs for work-specific tasks.
There's also a data governance reason. Microsoft Copilot keeps your data within your M365 compliance boundary — it doesn't get sent to OpenAI for training. That's fundamentally different from using ChatGPT.com, where your inputs may be used to improve the model unless you're on an enterprise agreement. For most organisations, embedded enterprise tools are the first category of AI tools that IT and compliance teams can approve without extensive review.
The practical starting point for most teams: before adopting anything new, run a quick audit. Which tools do you already pay for? Do they have AI features? Have you turned them on? The answer is often that there's significant value sitting unused in the stack you already have.
Try it yourself — The embedded audit
List every software licence your team or organisation already pays for. Which ones have AI features you haven't turned on? Total up the estimated time savings. That's your unused AI value — before spending a penny on new tools.
| Tool | AI feature | Turned on? | Who could use it? | Estimated value |
|---|---|---|---|---|
| e.g. Microsoft 365 | Copilot in Word, Excel, Outlook | No | Everyone | 2 hrs/week per person |
Layer 5 — Platforms and APIs: building your own
Sometimes off-the-shelf tools don't fit. Your workflow is specific enough, your data sensitive enough, or your use case novel enough that you need something built rather than bought.
Layer 5 is where that happens.
flowchart TD
PLAT["AI Platforms and APIs"]
PLAT --> DIRECT["Direct Model APIs\nAccess models programmatically"]
PLAT --> CLOUD["Cloud AI Platforms\nManaged infrastructure with model access"]
PLAT --> BUILD["AI App Builders\nNo-code and low-code AI workflows"]
PLAT --> VECTOR["Vector Databases\nFor RAG and knowledge retrieval"]
PLAT --> AGENT["Agent Frameworks\nFor building AI agents and automation"]
DIRECT --> D1["OpenAI API"]
DIRECT --> D2["Anthropic API"]
DIRECT --> D3["Google AI Studio"]
CLOUD --> C1["Azure OpenAI — GPT-5 in Microsoft's cloud"]
CLOUD --> C2["AWS Bedrock — multiple models in AWS"]
CLOUD --> C3["Google Vertex AI — Gemini in Google's cloud"]
BUILD --> B1["LangChain — AI workflow orchestration"]
BUILD --> B2["LlamaIndex — document Q&A pipelines"]
BUILD --> B3["n8n — no-code AI workflows"]
VECTOR --> V1["Pinecone"]
VECTOR --> V2["Weaviate"]
VECTOR --> V3["pgvector (PostgreSQL)"]
AGENT --> A1["MCP — connects AI to tools and data sources"]
AGENT --> A2["LangGraph — agent orchestration"]
AGENT --> A3["CrewAI — multi-agent framework"]
The most important pattern in this layer for most organisations is RAG — Retrieval-Augmented Generation. It's what powers the question "can we build an AI that answers questions about our own documents?" and it's the architecture behind most serious enterprise AI deployments.
The basic idea: your documents get converted into vectors (the same meaning-fingerprint concept from the LLMs guide) and stored in a vector database. When a question comes in, the system searches for the most relevant document passages and injects them into the AI's context window alongside the question. The model answers using both what it learned in training and the specific documents you retrieved.
flowchart LR
DOCS["Your documents\nPDFs · wikis · databases"] --> EMBED["Convert to\nvectors"]
EMBED --> VDB["Vector database"]
QUERY["User question"] --> SEARCH["Search for\nrelevant passages"]
VDB --> SEARCH
SEARCH --> INJECT["Inject into\nAI prompt"]
INJECT --> ANS["Answer grounded\nin your documents"]
RAG solves two problems simultaneously: the knowledge cutoff (the model answers from your documents, not its training data) and hallucination risk (grounded in retrieved content, not pure generation). It's the most practical enterprise AI pattern for building something that knows your organisation's specific information.
When you need this layer versus a product:
| Situation | Use a product | Use a platform or API |
|---|---|---|
| General daily tasks | ✅ ChatGPT or Claude.ai | ❌ Unnecessary complexity |
| AI over your own document library | ❌ Not possible | ✅ RAG pipeline |
| AI embedded in your own application | ❌ Not possible | ✅ API integration |
| Specific data residency requirements | ⚠️ Depends on the tool | ✅ Azure, AWS, or GCP deployment |
| Fine-tuning on your domain | ❌ Not possible off-the-shelf | ✅ Fine-tuning via API |
| Automated AI workflows | ⚠️ Limited in consumer tools | ✅ LangChain, n8n, custom |
How to choose — four questions in order
With five layers and hundreds of tools, selection can feel like a research project in itself. It doesn't need to be. Four questions, asked in order, will get you to the right answer for almost any task.
flowchart TD
START["You have a task to do with AI"]
START --> Q1{"Is this task already handled\nby a tool I use every day?"}
Q1 -->|"Yes"| A1["Use the embedded AI feature\nM365 Copilot · Google Workspace AI\nNotion AI · Grammarly"]
Q1 -->|"No"| Q2
Q2{"Is this a specialist task —\nimage, voice, code, video, research?"}
Q2 -->|"Yes"| A2["Use a purpose-built native app\nMidjourney · GitHub Copilot\nElevenLabs · Perplexity"]
Q2 -->|"No"| Q3
Q3{"Is this a general language task —\nwrite, summarise, analyse, explain?"}
Q3 -->|"Yes"| A3["Use a general AI assistant\nChatGPT · Claude.ai · Gemini · Copilot"]
Q3 -->|"No"| Q4
Q4{"Does this need a custom\nor proprietary solution?"}
Q4 -->|"Yes"| A4["Use an AI platform or API\nAzure OpenAI · Anthropic API\nAWS Bedrock"]
Q4 -->|"No"| A5["Re-examine the task —\nAI may not be the right tool here"]
The ordering matters. Start with embedded — the tool you're already in, already paying for, already governed. Only escalate to a new tool if what you have genuinely doesn't cover the job.
Once you've identified the layer, choosing within it comes down to six factors:
Data sensitivity — can this data go to this tool's servers? This is not optional to consider. Check your organisation's AI policy before you start.
Integration — does it connect with the tools your team already uses? A tool that requires a separate workflow is a tool half the team won't use.
Cost — what's the per-user or per-call cost at your expected volume? The free tier is not appropriate for sensitive work.
Performance on your actual tasks — don't rely on benchmarks. Test the tool on five or ten real examples from your own work. The one that performs best on your specific tasks is the right one, regardless of which model a reviewer rated highest.
Stability and support — is this a stable product with enterprise support, or a startup that might pivot next quarter?
Compliance — data residency, audit logs, access controls, SSO. The checklist varies by sector but the question is always: can this tool meet your governance requirements?
Building a team stack that actually holds together
Individual tool choices are one thing. Most organisations that have been through a year of unmanaged AI adoption end up with something far messier: dozens of tools, inconsistent practices, overlapping subscriptions, and no shared understanding of what's approved.
I've run audits on teams where individuals were using ten or fifteen different AI tools, often for overlapping jobs, often with no awareness of what data was going where. The annual cost was significant. The data risk was worse.
A deliberate team stack — one or two tools per layer, selected against clear criteria, approved and governed consistently — is the antidote.
flowchart TD
STACK["Team AI Stack"]
STACK --> T1["Layer 2: Primary AI Assistant\nOne tool everyone uses for general tasks"]
STACK --> T2["Layer 3: Specialist Tools\nOne or two for your team's specific needs"]
STACK --> T3["Layer 4: Embedded AI\nEnable what's already in tools you pay for"]
STACK --> T4["Layer 5: Platform\nOnly if you're building something custom"]
T1 --> EXAMPLES["Example stacks by organisation type"]
EXAMPLES --> MSFT["Microsoft-first org\nM365 Copilot · GitHub Copilot · Bing Copilot Pro"]
EXAMPLES --> GOOG["Google-first org\nGemini for Workspace · Gemini Advanced · NotebookLM"]
EXAMPLES --> MIXED["Mixed or best-of-breed\nClaude.ai Pro · GitHub Copilot · Perplexity · Notion AI"]
EXAMPLES --> BUILD["Technical or engineering team\nAnthropic API · Azure OpenAI · Cursor · LangChain"]
The process for getting there doesn't need to be complicated:
Step 1 — Audit what's actually in use. Before making decisions, find out what's happening. Which AI tools are people already using, officially or not? This is almost always more than anyone expects.
Step 2 — Map your top use cases. What are the five or ten tasks where AI could save the most time for your team? The tool choices should follow the use cases, not precede them.
Step 3 — Check governance constraints. Which tools are approved? What data classifications can each one handle? If this hasn't been decided yet, this is the moment to decide it.
Step 4 — Select and pilot. Pick one tool per layer. Run a 30-day pilot with a cross-section of the team. Get specific feedback on real tasks, not general impressions.
Step 5 — Train and embed. A tool nobody knows how to use is not in the stack — it's just installed. Shared prompt libraries, brief onboarding, and a channel for questions make the difference between adoption and abandonment.
Step 6 — Review quarterly. The landscape moves fast. What was the right choice nine months ago may not be the right choice today. A quarterly review doesn't need to be long — it just needs to happen.
The goal is not perfection. It is intentionality. A team that has consciously decided on four tools and knows why is in a fundamentally better position than a team with twenty tools and no policy — regardless of which four tools they picked.
Try it yourself — Your team stack design
For each layer, which tool(s) would you put in your team's approved stack? Now ask: for each tool, is it enterprise-tier? Is it approved by IT? Does it meet your data governance requirements? If the answer to any of these is "no," it doesn't go in the stack.
| Layer | Tool 1 | Tool 2 | Why these? |
|---|---|---|---|
| Layer 1: Foundation models | |||
| Layer 2: AI assistants | |||
| Layer 3: Native apps | |||
| Layer 4: Embedded tools | |||
| Layer 5: Platforms/APIs |
The selection framework in one diagram
flowchart TD
TASK["You have a task"]
TASK --> L{"Which layer?"}
L -->|"In a daily tool"| EMB["Layer 4\nEmbedded AI\nM365, Google Workspace, Notion"]
L -->|"Specialist modality"| NAT["Layer 3\nNative App\nMidjourney, GitHub Copilot, ElevenLabs"]
L -->|"General language"| ASS["Layer 2\nAI Assistant\nChatGPT, Claude.ai, Gemini"]
L -->|"Custom or proprietary"| API["Layer 5\nPlatform or API\nAzure, Anthropic, AWS"]
EMB --> GOV{"Governance check:\nApproved tool?\nRight data tier?"}
NAT --> GOV
ASS --> GOV
API --> GOV
GOV -->|"Yes"| USE["Use it\nWith appropriate verification"]
GOV -->|"No"| FIX2["Use an approved alternative\nor escalate for approval"]
The takeaway:
Once you can place a tool in a layer, new launches stop being confusing — they're just a new option in a slot you already understand. The rest follows from that: pick the right fit, build a deliberate stack, and review it regularly. But the layer map is the thing that changes how you see the landscape.
Cheat Sheet — All the key terms
| Term | Plain English | Where it fits |
|---|---|---|
| Foundation model | The trained neural network that powers everything above it | Layer 1 |
| Proprietary model | Vendor-managed, highest performance, data handling depends on your agreement | Layer 1 |
| Open-source model | Free to run and modify, full data control, requires your own infrastructure | Layer 1 |
| AI assistant | General-purpose chat interface built on a foundation model | Layer 2 |
| Enterprise tier | Data stays within your compliance boundary — required for sensitive work | Layer 2 |
| AI-native app | A product built specifically for one modality or task | Layer 3 |
| AI-embedded tool | AI features added to software you already use | Layer 4 |
| AI API | Direct programmatic access to a foundation model | Layer 5 |
| Cloud AI platform | Foundation models hosted in your cloud provider (Azure, AWS, GCP) | Layer 5 |
| RAG | Custom AI that answers from your documents, not its training data | Layer 5 |
| Fine-tuning | Adapting a model to your specific domain or style | Layer 5 |
| MCP | Standardised protocol for connecting AI to tools and data sources | Layer 5 |
| Agent framework | Orchestration layer for building AI that takes actions autonomously | Layer 5 |
| Tool sprawl | What happens when AI tool adoption is unmanaged | Every layer |
| Team AI stack | A curated, approved, governed set of tools — one or two per layer | Every layer |
How to know if this landed
You'll know this has landed when someone can place any tool they encounter into one of the five layers without help. When they ask "what layer does this task need?" before reaching for a new tool. When they know which tools are approved in their organisation and why — and they don't use unapproved tools with sensitive data. When they've checked what AI features already exist in the tools their team pays for before adopting something new. When they understand why a native app will outperform a general assistant on certain tasks — and can explain it without jargon. When they can describe what RAG does and when it matters, even if they'll never build one themselves. And when their team has a defined stack — not just individual preferences.
What the tool audit always surfaces
The audit is always the most revealing moment in this workshop.
Before we talk about which tools to adopt, I ask teams to list every AI tool currently in use across the team — officially or not. The number is consistently higher than anyone expected. I've worked with teams of thirty people who collectively had forty-two AI tools in active use. Many were doing the same job. Several were being used with data that violated the organisation's own policies — often because nobody had told them not to.
The five-layer framework cuts through that immediately. Once everyone can categorise a tool, the conversation changes from "which AI should we use?" to "we have three things doing the same Layer 2 job — pick one." That's a productive conversation. The first one isn't.
The other shift I see consistently: Layer 4 adoption goes up after this session, not down. People realise they've been paying for Microsoft Copilot or Google Workspace AI for months and never turned it on. They come back two weeks later with specific questions about how to use what they already have — which is a far better problem to have than thirty people on thirty different unapproved tools.
The governance conversation also lands differently after this session. "You can't use that tool" is a hard message to deliver and a hard one to hear. "That tool is Layer 2, it's not in your approved stack, and here's what you should use instead" is a concrete, actionable message. The framework gives the governance conversation a language it didn't have before.
Book a Workshop
Ready to bring clarity to your team's AI tools landscape — and build a stack that's deliberate, governed, and genuinely effective?
or
Half-day workshop includes the five-layer AI landscape mapping exercise, a team AI tool audit, data risk identification, a team stack design session, the tool selection framework as a takeaway, and integration with your AI governance framework.