3-Layers of AI automation
Every useful AI system, from a simple chatbot to an autonomous research agent, is built from the same three layers. Understand them, and you can place any tool - or any business case - on the map.
“AI automation” gets used to mean everything and nothing. But strip away the hype and almost every system reduces to a simple stack: it gets context from your data, it acts on that context with some blend of automation and intelligence, and it surfaces the result where people already work. Three layers - Data, Action, Interface.
The original sketch for this model had two layers. The third - Interface - earns its place because the same Data + Action engine feels completely different delivered as a chat box, an AI operating layer, or a purpose-built app. Where it lives decides whether people actually use it.
Data - get the context
Intelligence is only as good as the context it can see. The Data layer is everything an AI system can reach to ground its answers: live services (APIs, MCP servers), structured stores (SQL databases), unstructured documents (PDFs, images, email), and vector databases that make all of it semantically searchable.
Live, tool-callable access to systems that already run the business.
Tables, transactions, records - queried precisely and deterministically.
The 80% of knowledge that lives outside any database.
Embeddings that let the model retrieve by meaning, not keywords.
Data-focused business cases
When the value is mostly in retrieval and knowledge, the interface is usually a chatbot. Three patterns cover most of it:
A company-wide assistant that answers any question from your internal data, with the source linked. Replaces the daily 1.5 hours people lose searching across email, docs, chat, and systems.
Goes a step beyond retrieval: pulls internal context, merges it with external/market information, then performs analysis and synthesis to produce an answer no single source held.
Automatic capture and organization of company knowledge - built on a store like Obsidian. Information from messages and PM tools is extracted, filed, and kept current without anyone maintaining it.
Action - apply behaviour
An action can be a single task, a process (a set of tasks), or an entire organization (a set of processes). Every action sits somewhere on a spectrum between pure automation (deterministic if-then) and full intelligence (a model deciding what to do).
The break from every prior technology is this: an action's behaviour can now be specified in plain human language. Before, you needed a programmer to translate human intent into code; now the specification is the instruction.
Deterministic software, hand-written by programmers.
Supervised & unsupervised models, each trained for one task.
General models that augment knowledge work; human is architect & closer.
Self-improving loops that run to a quantified goal.
Actions also move through a lifecycle - and this is where the engineering happens:
A fresh action created from a specification - you describe the outcome and the model performs it.
A proven action is saved for repeated use, so it runs the same way every time.
The saved action runs on a trigger - a schedule, an event, or a webhook - or loops until it reaches a goal.
A human stays in the loop wherever confidence falls below a set threshold, or the stakes are high. And note: an agent is simply any software with partial or full intelligence.
Action-focused business cases
When the value is in workflow automation, the interface climbs from chatbot to an AI OS to a custom app:
A throwaway task done once and well: reconcile two exports, reformat a dataset, draft 200 personalized messages from a list - specified in plain language, run, done.
A recurring need captured as a skill: "summarize this week’s support tickets," "generate the Monday pipeline report." Defined once, invoked forever.
The modern alternative to brittle RPA: instead of screen-scraping, the system acts through MCP servers and skills against real APIs. The human describes the workflow in plain text - no programming needed - and it runs auditably and deterministically.
AI does the heavy lifting while a human keeps judgment and relationships. Example - AI sales: the rep keeps the in-person relationship; AI handles enrichment, lead scoring, outreach drafted in the rep’s voice, and live deal-risk flags. The human stays the closer and the judge.
You hand the system a quantified goal, not a script. A growth agent runs its own experiment loop - hypothesis, test, measure against the KPI, keep what wins - escalating to a human only at set checkpoints. Common in performance marketing, pricing, and self-tuning ops.
Interface - deliver it
The same Data + Action engine can be delivered three ways, in rising order of depth. Most companies start at the chatbot and earn their way down.
Ask-and-answer over your data. Fastest to ship, lowest commitment.
A shared layer of skills and agents the whole company works through.
Purpose-built software around one high-value workflow. Deepest fit.
App-focused business cases
At the deep end, the interface becomes the product - a shared operating layer, or software that only exists because the AI does:
A control layer where management composes custom workflows, sets guardrails and rules, and orchestrates the company’s skills and agents - the operating system every team works through. Think an internal harness built on an orchestration layer like n8n, LangGraph, or a Claude/MCP skill registry.
Software built AI-first around one high-value workflow, not bolted on after. Example - Tana’s "do work in the meeting": it captures the call, structures decisions and tasks, and acts on them live. The product only exists because the AI does.
Once you see the three layers, the question stops being “what AI tool should we buy?” and becomes “which data, which action, which interface - and how much intelligence does this one actually need?” That is the entire job.

