How to Build an AI Stack: The Five Layers That Matter
Most stacks are assembled by accretion — a subscription here, a workflow tool there — until you own three tools in one layer and nothing in the two that actually fail. The decision problem, layer by layer.
Every week someone posts their “AI stack” and it is a screenshot of nine logos in a grid. That is a collection, not a stack. A stack has layers, each layer does one job, and for a small operation the entire decision problem fits in five of them: model access, an agent harness, memory, automation glue, and observability. This is how to work out which layers you already own, which one is actually missing, and why the tool you are about to buy is probably aimed at the wrong one.
Nobody designed your stack, and it shows
A small operation acquires AI tools the way a kitchen drawer acquires cables. You subscribed to a chat model during one crunch, added an image generator for a launch, signed up for a workflow platform because a video made it look inevitable, and started three free trials you have since forgotten. At no point did anyone decide anything. The monthly total is real; the coverage is accidental.
The fix is not a better list of tools. It is a change of unit: stop deciding tool by tool and decide layer by layer. A layer is a job that fails on its own schedule with its own symptoms — the model being wrong is a different failure from the automation not firing, which is different again from not knowing whether it fired at all. Five layers cover a small operation, and two of them cost approximately nothing, which is exactly why they are the two most likely to be missing.
The five layers
1. Model access — the intelligence you rent
One frontier model subscription, plugged in where you actually work. The selection criterion is not the leaderboard — the gaps between frontier models shift month to month and matter less than everything below this line. What matters is duller: the usage limits you will actually hit, and whether the model is reachable from a harness — a terminal agent, an API — rather than only from a chat tab. A chat tab cannot touch your files. If your only access is a browser tab, you have bought intelligence and no hands. (If the choice between the two big chat products is the thing blocking you, we wrote a separate comparison — but that choice is the least important one on this page.)
2. Agent harness — the hands
The harness is whatever lets the model act instead of advise: run commands, edit files, read a whole project, call tools. Terminal agents like Claude Code are the clearest current example, and MCP servers extend what they can reach. The test for whether you own this layer is embarrassing and reliable: watch yourself work for an hour. Every copy-paste from a chat window into a file or a terminal is you performing, by hand, the job of a layer you do not have. People pay for model access that already supports a harness and never install it — the layer is not under-bought so much as under-unwrapped.
3. Memory — what a session knows without being told
Everything a new session should not need explained again: what the business is, the hard rules, where things live, what “done” means. For a small operation this layer is mostly not a product. It is instruction files and procedure documents — plain markdown, versioned next to the work. The strongest signal that this layer is missing is session two starting with you typing the same three paragraphs of background you typed in session one.
# CLAUDE.md (or AGENTS.md) — what every session must know ## What this operation is Two sentences. What you sell, who pays. ## Hard rules - Things the agent must never do. One per line. - Keep this list short enough to stay true. ## Paths that matter - Where the real work lives. Where output goes. ## What "done" means Every task closes with a receipt: the file, the URL, or the command output that proves it happened.
The temptation at this layer is to buy something — a memory product, a vector database, a second brain app. Resist it until the markdown version has failed you, because for one operator on one machine it usually does not. Writing the file is the work; the tooling is a detail. We keep a full guide to what belongs in the instruction file — the short version is: less than you think, kept truer than you expect.
4. Automation glue — things that run without you
Schedulers and triggers: cron, launchd on macOS, systemd timers on Linux, workflow platforms like Zapier, Make, or n8n, webhooks, CI schedules. The rule for this layer has nothing to do with which platform: only automate a procedure after it has run manually, boringly, without surprises, several times. Glue applied to an unstable procedure does not stabilize it. It automates the chaos and adds a scheduler to it.
Before adding any glue, audit what already runs without you. The answer is rarely zero:
$ crontab -l $ launchctl list | grep -v com.apple # macOS: third-party jobs $ systemctl list-timers --all # Linux # and what is holding ports right now $ lsof -nP -iTCP -sTCP:LISTEN
5. Observability — knowing what ran
The layer nobody sells well and nobody builds until an automation fails silently for weeks. It does not need a product either, at this scale. It needs three habits: logs with dates on them, a one-line receipt per run that names the artifact produced, and a way to ask the machine what is actually running instead of trusting what you remember starting.
# every scheduled job writes a dated log
$ my-scheduled-job 2>&1 | tee logs/job-$(date +%F).log
# and one greppable receipt line per run
$ echo "$(date -u +%FT%TZ) job=invoice-sync ok wrote=out/invoices.csv" \
>> logs/receipts.logAn automation you cannot observe is not automation. It is a rumor about your own business.
What gets over-bought, and what gets under-bought
Over-bought: intelligence and glue
The most common duplicate purchase is a second frontier chat subscription doing the same single job as the first — bought during a week when one model annoyed you, kept out of inertia. Two chat tabs is not redundancy; it is the same layer twice, with neither instance wired into a harness.
The second over-buy is glue: a workflow platform plan acquired in the honeymoon week, now hosting a pile of half-dead automations nobody can list from memory. There is a clean test for this state: if you cannot enumerate your own automations without logging in to check, your glue layer has outgrown your observability layer — and that combination is worse than having neither, because things now happen to your business that no one is watching.
Under-bought: memory and observability
The two free layers. Nobody writes the instruction file because writing feels like overhead; nobody builds receipts because while everything is manual, you are the receipt. Both bills come due the moment the operation adds an agent or a scheduled job — the agent re-asks everything the file would have told it, and the job fails on a Tuesday and is discovered through its consequences. Every hour spent on these two layers is worth more than the same hour spent comparing models, and it is not close.
Missing layer, or misconfigured layer?
Almost every “we need a new AI tool” conversation is one of these two states wearing the other one's clothes. The distinction matters because the fixes are opposites: a missing layer is fixed by adding something; a misconfigured layer is fixed by reading and editing what is already there. Shopping is more fun than reading, which is how a misconfigured layer ends up with a second tool stacked on top of it.
- You re-explain the business at the start of every session. Memory layer missing. Write the instruction file. This is an afternoon, not a purchase.
- The instruction file exists and the agent still gets it wrong. Memory layer misconfigured. The usual causes, in order: the file is too long to be followed, it contradicts itself, or it is stale and the agent is faithfully obeying last quarter. The fix is deleting and correcting lines, not adding a memory product on top of a broken file.
- Your workflow contains copy-paste between a chat window and your machine. Harness missing — whatever you are paying for model access, you are using a fraction of it.
- The model seems “not smart enough.” Usually a misconfigured context problem, not an intelligence problem: the model was not shown the file, the rule, or the example that made the task answerable. Swapping subscriptions to fix a context problem is the single most common wrong purchase in this whole stack.
- An automation failed and you found out days later from the fallout. Observability missing. No glue purchase fixes this; the replacement automation will fail silently too.
- You discover an automation you forgot existed. Glue over-provisioned. Run the scheduler audit above and delete before you add anything.
The general razor: before money moves, say out loud which layer the purchase lives in, and what would have to be true for the existing layer to be merely misconfigured. If you cannot name the layer, you are not buying a stack component. You are adding a cable to the drawer.
The assembly order
- One model subscription, reachable from a harness. Not three subscriptions. Not chat-tab-only access. One model you can wire into the place work actually happens.
- Install the harness where the work lives. Run real tasks through it manually for a while. This period is not wasted time — it is where you learn which procedures are stable enough to deserve automation later.
- Write memory as you go. Every time you explain something to the agent twice, that explanation moves into the instruction file. The file grows out of friction, not out of a planning session.
- Automate the boring survivors.A procedure that has run manually several times without surprises earns glue. Start with a scheduled script before reaching for a platform — a script that logs to a file is easier to observe than a workflow living in someone else's dashboard.
- Observability starts with the first automation, not after the first incident. Dated log, one-line receipt per run, and a periodic check of what is actually running. Ten minutes of setup per job.
Honest limits
Five layers is a map, not a mandate. A one-person operation can run for months on the first three layers with zero glue and be entirely correct to do so — automation is leverage on procedures you already trust, not a substitute for having them. If nothing in your week is boringly repeatable yet, you do not have an automation gap. You have a procedure gap, and that one is solved at a keyboard, not at a checkout page.
The boundaries also blur at the edges. A harness reading instruction files is doing memory work; a workflow platform ships its own run history, which is a slice of observability. The taxonomy earns its keep at buying time — as the question “which layer is this, and do I already own it?” — not as an org chart for your software. And stacks decay: limits change, models leap, a tool you rely on gets acquired and re-priced. Re-run the layer audit whenever the monthly total changes, not on a calendar.
The bottom line
Decide by layer, not by logo. One model, reachable from a harness. A harness installed where the work is. Memory as markdown, grown out of every repeated explanation. Glue only for procedures that were already boring. Receipts from the first scheduled run onward. The two layers that cost nothing are the two that are missing from almost every stack screenshot you will ever see — start there, today, before renewing anything.
If you want the written layers as finished documents rather than a blank file, the AI Operator Flagship Stack ($79) is the playbook, the prompt arsenal, and the workspace kit in one bundle. Related reading: what AI automation actually costs a small business and, once the stack grows past one agent, how to run multiple coding agents on one machine without them trampling each other.