Section I
The premise
The way companies are built is changing at the foundation level. Not the tools on top. The logic underneath. Most organisations are adding AI to an existing model. A small number are building a different model entirely. This is the blueprint for the second approach.
The shift in one sentence
The traditional company was built around humans as the execution unit. The new company is built around knowledge and context as the core asset, with agents as the execution unit.
Two fundamentally different bets
Augmentation
Add intelligence to the existing stack. Give people better tools. Make the translation faster. The human remains the bridge between the business need and the machine. They just cross the bridge more quickly.
Produces: faster execution of existing work. Measured by: adoption rates, time saved, productivity scores.
Substitution
Build systems that handle the execution so the human no longer needs to be the bridge at all. The human defines the outcome, provides the context, sets the direction. The agent finds the path and runs it.
Produces: a different kind of working day. Measured by: what your people spend their time thinking about.
of the average knowledge worker's day is work about work
Navigation, coordination, information retrieval, status updates, approval chains. Not the skilled work. The overhead around it. Asana found this across 10,000+ knowledge workers globally. The average worker switches between applications over 1,200 times a day. If AI makes that 60% faster, the hamster wheel runs faster. The hamster is still on the wheel. The opportunity is escaping it.
Source: Asana Anatomy of Work Index · Harvard Business Review · Cornell Workgeist Report 2024
The diagnostic question. Has your AI adoption changed what your people spend their time thinking about? If the answer is no, you are making the first bet regardless of what the procurement deck says. The test is not which tools you have deployed. The test is whether the execution layer is still consuming the attention of your most valuable people.
Section II
The intelligence operating stack
Five layers. Built from the bottom up. The models will change. The frameworks will evolve. But the logic of the stack is durable because it reflects what agents actually need to function well: knowledge, context, infrastructure, execution, and human direction. The diagram below shows the architecture at a glance. Click each layer below to explore in detail.
The architecture — overview
The stack — explore each layer
Human intelligence layer
Direction, judgement, relationships, and the things that require accountability
What lives here
- Defining what the outcome should be
- Relationships that make difficult conversations possible
- Knowing when the brief is wrong before starting
- Decisions where being wrong has real consequences
- Reading context no dataset fully captures
- Building things that do not yet exist
- Holding accountability for what agents produce
- Setting the direction when the path is genuinely unclear
What this replaces
- Management layers that relayed information up and down
- Status meetings that monitored execution progress
- Project coordination that tracked tasks
- Reporting that aggregated context already held in systems
- Middle management as the primary coordination mechanism
Cost unit
Human attention · irreplaceable · the scarcest resource in the new model
Elevated work — what humans do when execution is handled
Execution layer
Agents doing the work — continuously, without being asked, at token cost
What agents handle today
- Email triage, extraction, and drafted responses
- Research synthesis across multiple sources
- Client briefing documents from context files
- Meeting intelligence logged to memory
- Reporting generated from live system state
- Scheduling and coordination routing
- Code scaffolding, tests, and documentation
- CRM updates from conversation context
- First-draft proposals from context and standards files
- Data extraction and transformation
Still developing (honest assessment)
- Complex multi-step reasoning across ambiguous inputs
- Regulated decision-making in banking and healthcare
- Novel problem types with no training precedent
- High-stakes actions without human review
- Tasks requiring real-time physical world interaction
Cost unit
Tokens per task · Gartner forecasts 90% cost reduction by 2030 · agentic workflows consume 5–30x more tokens than simple queries
Example tasks moving from human to agent
Agent infrastructure layer
Harness, heartbeat, tools, memory, orchestration — the operating environment
Core components
- SYSTEM.md — identity, purpose, rules of engagement
- MEMORY.md — accumulated knowledge across all sessions
- Heartbeat — scheduled loop running without being asked
- SKILL files — capabilities described in plain text
- Shell access — direct execution against the machine
- Tool connections — APIs, email, calendar, CRM, data sources
- Logs — auditable record of decisions and actions
Current frameworks (April 2026)
- OpenClaw — 345K stars, gateway architecture, 5,700+ skills
- Hermes — self-improving, persistent memory, agent-loop
- Pi / Claude Code — minimal harness, 4 core tools
- Goose (Block) — open source, model-agnostic
- LangGraph, CrewAI — multi-agent orchestration
- Claude Managed Agents — production-grade hosted infrastructure
- Perplexity Computer — 19-model routing, persistent sessions
The minimal viable harness — what you actually need
Context layer
The living picture of every relationship, project, commitment, and decision
What context contains
- CLIENT.md — who they are, what they need, what is open
- Decision log — what was decided, when, and why
- Project state — current status, blockers, next actions
- Relationship notes — preferences, communication style
- Pattern library — what works in this sector or situation
- Commitment tracker — what has been promised and to whom
How it is maintained
- Agent updates MEMORY.md after every significant session
- Structured folder per client, project, and domain
- Plain markdown — readable by humans and models alike
- No login required — no SaaS wall between agent and knowledge
- Version controlled — full history of what changed and when
- Human review at decision points, agent maintenance in between
Knowledge architecture layer
The foundation — what the company knows, encoded in a form agents can act on
What goes here
- Every process described precisely enough to evaluate
- Definition of good for every deliverable type
- Domain expertise encoded in plain language
- Lessons from every engagement, accessible to every agent
- Brand voice, standards, and non-negotiables
- Structured data sources agents can query directly
- Failure patterns — what has gone wrong and why
Why this layer must come first
- Agents without context are expensive and unreliable
- McKinsey: 80% of enterprises cite data limitations as the primary blocker to scaling agentic AI
- Context cannot be bought — only built over time
- Competitors can buy the same models; not your knowledge
- Every week this layer compounds — the moat deepens automatically
Cost unit
Time to encode · the only irreplicable asset · compounds indefinitely
Section III
Where are you now?
Before deciding where to focus, it helps to be honest about which layers you currently have and which are missing or broken. Answer the five questions below. No right answers. The output is a starting point, not a verdict.
Five questions — honest answers only
1. Where does your organisation's knowledge currently live?
2. When a new person joins your team, how do they learn what good looks like?
3. How does your team currently use AI?
4. What percentage of your senior people's day is execution versus direction?
5. If your two most valuable people left tomorrow, what would you lose?
Your starting point
Section IV
Building the knowledge architecture layer
This is the layer most organisations skip. It is also the reason most agent deployments underperform. Before you think about which framework to use or which model to run, you need to answer one question: what does this agent need to know about how we work in order to do this work without us?
The three files every domain needs
The folder structure
knowledge/
agents/
SYSTEM.md # Agent identity and constitution
MEMORY.md # Accumulated learning
skills/ # Capability files
clients/
[client-name]/
CLIENT.md # Living context
decisions.md # Decision log
briefs/ # Project briefs
standards/
delivery.md # Definition of good
voice.md # Brand and communication standards
process.md # How we do things here
domain/
market.md # Sector knowledge and patterns
tools.md # What tools exist and how to use them
The first encoding session
Block out two hours with the person who knows the most about the domain you have chosen. Ask three questions.
What does good look like?
How would you know if something was excellent versus merely acceptable? Be specific enough that someone new could evaluate their own work without asking you.
What consistently goes wrong?
What are the failure modes? Where do things typically stall? What mistakes keep happening? What do you wish people understood before starting?
What takes six months to learn?
What context does someone need to do this well that they would only absorb after significant time? What is never in the documentation but should be?
Record or transcribe the conversation. Have an agent turn it into the first draft of your STANDARDS.md and MEMORY.md. Review and correct. That two-hour session, properly encoded, is worth months of agent training. The act of encoding the knowledge is itself clarifying — most organisations discover they have never made explicit what they have always assumed was obvious.
Section V
Building the agent infrastructure layer
Once the knowledge architecture exists, you can build the agent. Not before. The infrastructure layer is where most organisations start, which is why most agent deployments underperform. The order matters more than the tooling.
Choosing the right framework — honest comparison
| Framework | Best for | Technical requirement | What it gives you | Honest limitation |
|---|---|---|---|---|
| OpenClaw / Hermes | Personal agent, always-on across messaging channels | Moderate — comfortable with command line | WhatsApp/Telegram integration, 5,700+ skills, self-improving loop | Security CVEs in OpenClaw; complex for regulated environments |
| Claude Code / Pi | Developer workflows, coding agents, minimal harness | Developer comfort required | Deep codebase context, git integration, extensible via tools | Claude-only; not a full autonomous agent without additional harness |
| Goose (Block) | Teams wanting open-source, model-agnostic foundation | Technical team required for setup | Privacy-first, local execution, proven at scale | Less ecosystem than OpenClaw; requires more self-built skills |
| LangGraph / CrewAI | Multi-agent orchestration, complex workflow automation | Engineering resource required | Full orchestration control, role-based agents, custom pipelines | Higher complexity; over-engineered for simple use cases |
| Claude Managed Agents | Production deployments requiring security and reliability | Low — managed infrastructure | Durable sessions, crash recovery, credential vaults, SOC2 | Claude-only; ongoing infrastructure cost |
| n8n / Zapier (no-code) | Teams without technical resource who need automation fast | None — visual builder | Fast to deploy, wide integrations, no code required | Not truly agentic — triggered workflows, not autonomous agents |
The full landscape of every current agent framework, platform, and tool is mapped at agentnetwork.ai. Use the Agent Mapper to understand where you sit on the spectrum from tool-use to full autonomous agents. The Groundwork resource focuses on the architecture decisions; the landscape covers the tooling in full.
What separates a tool from an agent
Waits to be asked
Responds when prompted. Has no memory between sessions. Exists only in the moment of being asked. Does not monitor, initiate, or accumulate. Most people who believe they are using AI agents are using tools.
Has a heartbeat
Runs on a scheduled loop whether or not a human asks it to. Has persistent memory that accumulates across sessions. Has a defined role, tools to act with, and the authority to act within boundaries without waiting to be asked.
Section VI
The build sequence
The order matters more than the speed. Most failed deployments started with the agent. The ones that work started with the knowledge. Here is the sequence that compounds correctly.
Week by week — the first ninety days
Choose one domain. Map the knowledge that currently exists in people's heads.
Pick the single area where the most valuable knowledge lives informally. Run the first encoding session. Create SYSTEM.md, MEMORY.md, and the first CLIENT.md or STANDARDS.md. Do not deploy an agent yet. The knowledge layer must exist first. Most teams find this harder than expected — writing down what seems obvious is itself clarifying work.
Deploy a minimal agent against the knowledge you have just built. Give it one task.
Choose the single highest-value task in your chosen domain that is currently consuming human time. Brief the agent with the knowledge files you built. Run it. Observe what it gets right and what it gets wrong. Everything it gets wrong is a gap in your knowledge architecture, not a failure of the agent. Add what is missing to the files. Run it again.
Add the heartbeat. Let the agent run without being asked.
Set up the scheduled loop. Define what the agent checks for and what it does when it finds something. This is the moment the agent shifts from a tool to a system. The first time it handles something you did not ask it to handle, and handles it correctly, is the moment you understand what this infrastructure actually is. Log everything. Review the first two weeks of autonomous outputs carefully.
Add a second domain. Let the first agent's memory inform the second.
By now the first agent has a MEMORY.md that is accumulating real knowledge. The patterns it has observed, the decisions it has logged, the failures it has recorded — all of this is now part of your knowledge architecture. When you extend to a second domain, the second agent starts with a richer foundation than the first. This is the compounding logic at work. Each deployment improves the substrate for the next.
Stop measuring adoption. Start measuring what your people are spending their time thinking about.
By month three you should be able to answer a question you probably could not answer on day one: what would your most valuable people build if the execution layer was not consuming their attention? That question, and its answer, is the signal that the architecture is working. The organisations that reach this point are not talking about AI productivity anymore. They are talking about what they are building now that they could not previously reach.
The most common failure mode. Deploying the agent before the knowledge layer exists. The agent is technically functional but produces generic, context-free outputs that require constant correction. The team concludes agents are not ready. The reality is the foundation was not ready. The agent was willing; the knowledge was not there to guide it.
Section VII
The agent's constitution
The models will change. Frameworks will be superseded. Costs will fall. What will not change is what an agent needs to function well: a clear sense of what it is, what it knows, what it remembers, what it can do, and what it is for. This is the permanent structure underneath all of it.
The six elements that persist across every model change
Identity and purpose
Who the agent is, who it serves, what it is for, and what it will not do. This is the SYSTEM.md. Every other element depends on this being clear. An agent without a soul is just an expensive autocomplete.
Accumulated knowledge
What the agent has learned across every session. Patterns, decisions, failures, preferences. The MEMORY.md is the thing that turns a capable model into an entity that knows your organisation. Without memory, the agent starts from zero every time.
Situational awareness
The living picture of the current state. Who are we working with. What has been decided. What is open. What has changed since last time. Context is what makes the agent's output relevant rather than generically correct.
Capability to act
The connections to external systems, data sources, and services. Email, calendar, CRM, APIs, files. Without tools, the agent can think but not do. The tools are the hands. The quality of the connections determines the scope of what is possible.
Autonomous operation
The scheduled loop that wakes the agent and asks it to check, decide, and act without being prompted. This is the architectural difference between a tool and an agent. A chatbot waits. An agent with a heartbeat is already working.
Definition of good
What success looks like, precisely enough for the agent to evaluate its own output. This is the STANDARDS.md. An agent without a clear definition of good will produce technically correct outputs that miss the point. This file is what turns capability into quality.
The permanent truth
"The models will be replaced. The frameworks will evolve. The costs will fall. What compounds permanently is the knowledge, the context, and the memory you build today. That is the moat. And unlike every other advantage in technology, it is one your competitors cannot buy."
Craig Hepburn · Ground Truth · April 2026