10-Layer AI Agent Stack: Build Agents That Learn Across Sessions

Building an AI agent stack that actually compounds performance is the difference between a tool that gets better over time and one that resets every session. Medium-sized businesses and enterprise teams are pouring resources into AI agents — OpenAI hit 400 million weekly active users in February 2026, McKinsey reports that 92 per cent of companies plan to increase AI investment, and Gartner predicts that by 2028, 60 per cent of organisations will have deployed AI agents into production. Yet most of those agents start from zero every session.

We hear this from clients all the time. They buy a tool like Claude Code or Cursor, set up an agent, and spend every session re-explaining their priorities, their tech stack, and their decisions. The agent never gets better. It never learns. After a few weeks they wonder if they are doing something wrong.

They are not doing anything wrong. They are missing the right AI agent stack — a set of layers that together make an agent compound across sessions instead of resetting.

At Supernodes we build agent systems for mid-market and enterprise teams, and we have found that a working agent is not a single thing. It is a stack of ten layers. When you set each one up properly, the agent compounds across sessions. When you skip layers, you stay on a treadmill.

Here is the stack, how each layer works, and exactly how to set it up in the tools your team already uses.

Layer 1: The Brain

This is the reasoning engine. It decides what to do next, picks which tool to call, and keeps the loop running. Pick one brain and stick with it. We have found that switching between brains every week destroys consistency.

In practice: If your team uses Claude Code for development, use it for everything agent-related in that project. If you use Hermes for research and operations, route all general tasks there. Do not half-switch. The brain needs to build momentum. A fragmented reasoning engine leads to fragmented outputs — each tool has its own style, its own memory scheme, its own tool-calling conventions. Using one brain means those conventions compound.

Layer 2: Models

Different tasks need different models. Heavy reasoning benefits from Claude Opus 4.6 or Sonnet 4.6. Structured output works best with GPT-5.5. Long context analysis is cheaper on Gemini or DeepSeek. Set up an AI gateway like OpenRouter so you are not locked into one provider.

In practice: Write a routing rule in your agent config. For Hermes, this lives in config.yaml under the model section. A survey from Kore.ai found that 53 per cent of organisations say model and API usage costs drive their AI spend. Routing by task cuts that down — you are not paying Opus prices for a simple summarisation job, or using a cheap model for complex multi-step reasoning.

Layer 3: Identity

This is who the agent is and how it behaves. It lives in a single markdown file at your project root. In Claude Code, the file is called CLAUDE.md. In Codex, it is AGENTS.md. In Hermes, it is SOUL.md. The file sets the role, the tone, and the hard rules. Cap it at 200 lines. We tested going beyond 200 and rule adherence drops because the instructions dilute each other.

How to set it up: Create CLAUDE.md at the root of your project. Start with one line that says what this project does. Then write three sections: role (what the agent's job is), tone (how it communicates), and constraints (rules it must never break). Keep each section under 50 lines. Review the file quarterly — a six-month-old identity file will be giving instructions that no longer match your workflow.

Layer 4: Context

Context is what is currently true about your situation. It is not loaded every session. It is pulled on demand when relevant. We keep five files: people.md, strategy.md, product.md, customers.md, and now.md for current priorities. The now.md file is the most important one. We update it weekly. It is the single thing that stops the agent from asking what we are working on.

In practice: Put these files in a context/ directory at your project root. In Hermes, the agent reads context when it matches the topic — a question about customers loads customers.md, not the whole directory. Set up an auto-update cron job that rewrites now.md every Monday with this week's priorities. Teams that do this report saving roughly 15 minutes per session just on re-orientation.

Layer 5: Skills

Skills are modular playbooks the agent loads on demand. Each skill is a separate markdown file with a purpose, execution steps, and verification criteria. We used to have one big content skill, but it kept blending our LinkedIn tone with our email tone. Splitting them out fixed it immediately.

In practice: Keep skills in a skills/ or .hermes/skills/ directory. Name them after what they do: deep-research.md, code-review.md, lead-gen.md. Each skill starts with a one-line trigger condition — the agent only loads it when the task matches. For agents running on schedules, skills can be loaded at session start for consistent behaviour across automated runs.

Layer 6: Tools

Tools are how the agent executes. MCP servers connect the agent to real systems. The agent cannot search LinkedIn, query your database, or send messages without them. Connect them once and the agent discovers them automatically. The same principle applies to deploying the output — our guide to AI website deployment shows how tools connect agents to infrastructure.

In practice: Configure each MCP server in your agent's config with the exact endpoint and authentication. Test each tool in isolation before wiring it into an agent loop. A misconfigured tool that returns errors can cascade through the whole stack. Start with the three most used tools — search, file read/write, and a database query — then expand.

Layer 7: Memory

Memory is what the agent has learned across sessions. Read it at session start, write to it at session end. Without memory, your agent resets every time. With it, each conversation adds to what the agent knows.

In practice: In Hermes, memory lives in an editable file that the agent reads at startup and writes to on shutdown. Structure it as declarative facts — dates, decisions, user preferences — not procedural instructions. Cap it at roughly 2,000 characters so it fits in every session's context window. Archive old entries to a history file so the agent can look them up on request without paying the context cost of carrying them always.

Layer 8: Orchestration

When you have more than one agent, you need orchestration. A coding agent, a research agent, a lead gen agent. Orchestration decomposes a task, routes pieces to the right agent, and recovers when one fails. We cover the research agent pattern in detail in our guide to building deep research agents — it shows exactly how orchestration works in practice with a search-and-verify loop.

In practice: Define each agent's boundary explicitly. Agent A handles code, Agent B handles research, Agent C handles lead generation. When a task crosses boundaries — writing code that needs market research — route the research sub-task to Agent B and bring the results back. Use a supervisor pattern where one orchestrator agent delegates and validates, rather than letting agents talk to each other directly. Direct agent-to-agent communication is where most multi-agent failures happen.

Layer 9: Observability

You cannot improve what you cannot see. Tracing, logging, cost tracking and quality evaluation keep the stack honest. Without observability, you are flying blind.

In practice: Log every tool call with input tokens, output tokens, latency, and the result status. Keep a rolling 7-day window of these logs. Run a weekly quality review — check which tools failed most often, which models cost the most per task, and which skills were loaded most frequently. Teams that do this typically cut their per-task costs by 20 to 30 per cent in the first quarter by identifying the expensive patterns.

Layer 10: Safety

Credential isolation and sandboxing. The brain runs privileged. Tools run in a disposable sandbox with zero credential access. This prevents the most common failure mode: an agent that accidentally deletes production data because it had too much access.

In practice: Use environment variables for all credentials — never hardcode them in skill files or agent config. Set up a read-only database user for query agents. For destructive operations (write, delete, deploy), require a separate approval step. In n8n, this means using an approval webhook node before any write action. In Hermes, it means defining write tools as a separate category that the agent must explicitly request.

One thing we have noticed across our client work: frameworks like LangChain and CrewAI add abstraction layers that can obscure what your agent is doing. Anthropic's engineering team advises starting with LLM APIs directly — most patterns are implementable in a few lines of code. As of 2026, the tools have matured enough that the framework abstraction costs more than it saves for most mid-market and enterprise teams.

The ten layers form a complete AI agent stack. Set them up once and your agent compounds across sessions. The brain picks the right model, the identity file sets the tone, skills provide the playbooks, tools execute, memory carries learning forward, orchestration routes work, observability keeps everything honest, and safety prevents the catastrophic failures. Each layer is simple in isolation. Together they create a system that gets better the more you use it.

For more on how the research and tool layers work in practice, read our guide on building deep research AI agents. And if you are setting up the deployment pipeline for your agent's outputs, our free AI website builder guide shows how the same composable patterns apply to static site deployment.