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 2025, McKinsey reports that 92 per cent of companies plan to increase AI investment over the next three years, and Gartner predicts 33 per cent of enterprise software applications will include agentic AI by 2028, up from less than 1 per cent in 2024. 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 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 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.

The 10-layer stack at a glance

Layer	What it does	Where it lives
1. The Brain	Reasoning engine that decides what to do next	Claude Code, Hermes, or your chosen agent runtime
2. Models	Task-specific LLMs routed by job type	OpenRouter or a routing rule in your agent config
3. Identity	Role, tone, and hard rules, capped at 200 lines	CLAUDE.md, AGENTS.md, or SOUL.md
4. Context	What is currently true, pulled on demand	context/ directory (people.md, now.md, etc.)
5. Skills	Modular playbooks loaded when the task matches	skills/ or .hermes/skills/
6. Tools	MCP servers that let the agent act on real systems	Agent config, endpoint and auth per server
7. Memory	What the agent learned last session	Editable file read at startup, written at shutdown
8. Orchestration	Routes sub-tasks across multiple agents	A supervisor agent, not direct agent-to-agent calls
9. Observability	Tracing, logging, cost tracking	Rolling 7-day tool-call log, reviewed weekly
10. Safety	Credential isolation and approval gates	Env vars, read-only DB users, approval webhooks

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, because a fragmented reasoning engine leads to fragmented outputs. Each tool has its own style, its own memory scheme, its own tool-calling conventions, and 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 2026 Zapier survey of 715 professionals found that companies spend six figures a month on AI tools, and 40 per cent have routed more than half their software budget to AI. Routing by task keeps that spend in check, so 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, because past that the instructions start to dilute each other and the agent follows the file less reliably.

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, since 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, and it is pulled on demand when relevant rather than loaded every session. 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, and 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, so 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, and the agent stops asking what the team is working on at the start of every session.

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, so 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, and 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, because 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, which 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, such as 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. The expensive patterns show up fast once you look, and they are almost always fixable in the config rather than in the agent's instructions.

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, and 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 is that 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, since 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.

Frequently asked questions