Skip to main content
News Archive 7 min read

What Makes AI Agents Different: The CAMP Framework

Inside Claude Code, OpenClaw, and Hermes Agent: the CAMP framework reveals why different AI agents make radically different architectural choices.

Originally published:

Medium by Sathish Raju

TL;DR

Three leading AI agents—Claude Code, OpenClaw, and Hermes Agent—share the same four foundational requirements (character, action, memory, protocol) but make radically different architectural choices about how to satisfy them, revealing fundamentally different theories of what makes an agent valuable.

The CAMP Framework: Four Survival Needs Every Agent Must Satisfy

Despite superficial differences, every functional AI agent must answer the same four core questions to operate. The CAMP framework—Character, Action, Memory, Protocol—is not documented anywhere in official specs; it emerged as a pattern after examining the internals of Claude Code, OpenClaw, and Hermes Agent. Every design decision in these systems reduces to an answer to one of these four questions. The real insight is not that agents must answer them, but how differently they do—and what those differences reveal about each system's implicit theory of value.

Character: Who the Agent Thinks It Is

Before an agent touches a file or calls a tool, it needs operational self-concept—not philosophical identity, but a constraint on what outputs the model will generate. The underlying language model has no inherent personality; it produces text likely given context. Character is the layer that defines "likely" for a particular agent in a particular context.

Claude Code's approach: Character is infrastructure, not configuration. Anthropic bakes approximately 10,000 tokens of system prompt invisibly into every session. This hardened personality encodes tool usage patterns, risk flagging rules, output structure, and dozens of behavioral defaults that prevent common failure modes. Users cannot override it completely. The tradeoff: reliability and battle-tested safety at the cost of customization.

OpenClaw's approach: Character is version-controlled configuration. The system prompt lives in editable files—SOUL.md for values and tone, AGENTS.md for operational rules, IDENTITY.md for name and presentation. Your agent's personality is Git-tracked, shareable, and team-auditable. The tradeoff: full transparency and ownership at the cost of potential misconfigurations.

Hermes Agent's approach: Character is user-defined with graceful fallback. Users can replace built-in identity completely with a custom SOUL.md, or delete it and rely on sensible defaults. No invisible constraints. The tradeoff: maximum flexibility with the risk that poorly-written custom prompts degrade agent behavior.

Action: What the Agent Can Physically Do

Every tool an agent can access is described by a JSON schema loaded into the context window. This creates a direct tension: more tools mean more capability but proportionally more token consumption before the model reads a single line of your actual codebase. At 40+ tools, you can burn thousands of tokens on tool schemas alone. This is not a secondary performance concern—it is load-bearing for agent efficiency.

Claude Code's solution: Deferred loading. The model sees only tool names initially; full schemas load on-demand when the agent determines it needs a specific tool via a ToolSearch function. Tools cost nothing when unused. This is elegant engineering that works silently—most users never notice because nothing breaks.

Hermes Agent's solution: Explicit toolset activation. Eight tool categories (web, terminal, browser, media, orchestration, memory, automation, integrations) can be selectively loaded per session. A coding session loads terminal and file tools; a research session loads web and browser tools. Context overhead scales with task relevance.

From production experience: the most common performance complaint from experienced Claude Code users is not model quality but context bloat. Too many MCP servers, too many skills, too many memory entries. The model spends cognitive budget on overhead rather than actual problems. Tool hygiene directly determines agent hygiene.

Memory: The Unsolved Problem at Scale

Within-session memory is largely solved across all three agents. Between sessions—across weeks, months, and full project lifecycles—the ecosystem remains in early innings. Session amnesia is a real cost that organizations systematically underestimate.

Consider a developer using an agent daily for six months on a complex codebase. Conservative estimates suggest 50-100 hours spent re-explaining context a human colleague would retain. That is 2.5 full-time work weeks of re-teaching, invisible because it distributes across thousands of micro-frustrations.

A critical design insight unites all three agents: memory is stored in plain-text markdown files on regular filesystems, not proprietary databases or cloud-synced binaries. This is deliberate, not accidental. You can read memory with cat, edit with any text editor, back up with cp, version with Git, and migrate by copying folders. Your agent's knowledge base is not a black box—it is an auditable, human-readable filesystem you can inspect, correct, and understand directly.

Protocol: How the Agent Connects to the World

The protocol layer defines how agents interact with external systems, other agents, and users. This is where implementation diversity peaks. Different architectures encode fundamentally different assumptions about integration, reliability, and governance.

The Execution Loop: Where All Four Converge

In practice, CAMP components don't operate independently. Character constrains what actions the agent will choose. Action schemas define what Memory must track. Protocol determines which tools are accessible. The execution loop is where these four dimensions synchronize: on each cycle, character filters available actions, action schemas consume tokens of memory space, and protocol handles the interface to external systems.

Understanding this convergence point is critical because a failure in any one dimension cascades. Poor character definition leads to incorrect tool choice. Bloated action schemas starve memory of context space. Broken protocol prevents memory from persisting correctly.

The Instruction Hierarchy Problem All Three Face

All three agents load multiple instruction files and all face the same unspoken question: when files conflict, which wins? The answer in every case is text ordering, not technical priority mechanisms. The model sees concatenated instruction blocks and exhibits well-documented recency bias—later text weights more heavily than earlier text.

This has a practical debugging implication most documentation undersells: you are not configuring priority levels. You are curating the order in which the model reads instructions. Project-level files override global files not because of a priority rule but because they appear later in assembled context. Understanding this makes diagnosing misbehaving agents significantly easier.

Key Architectural Tradeoffs

Claude Code prioritizes hardened reliability with restricted customization. OpenClaw prioritizes transparency and team governance with configuration risk. Hermes Agent prioritizes flexibility with expertise requirements. None of these are "better"—they are different bets on what developers value most.

These choices ripple through the entire stack. Anthropic's invisible system prompt enables deferred loading (why expose complex tool schemas if users can't understand the system prompt anyway?). OpenClaw's editable prompts drive explicit toolset curation (users must understand what they're loading). Hermes's user-defined character enables the most flexible tool organization but demands the highest user expertise.

Why This Matters to the Ecosystem

Agent development in April 2026 is not yet converging on a dominant architecture. Instead, three fundamentally different theories about agent value are competing in the market. Understanding CAMP provides a framework to evaluate new agents, diagnose performance problems, and make deliberate tradeoffs rather than accepting defaults blindly. ai-agent-architecture agent-system-prompts

The absence of a unified standard is actually healthy. It means the field is still exploring design space. It also means developers must be intentional about which theory of value matches their use case. A startup optimizing for velocity might choose Claude Code's hardened reliability. A team building custom workflows might choose OpenClaw's transparency. A researcher exploring agent behavior might choose Hermes's flexibility.

The deeper insight: agent quality is not determined by the model anymore. Swapping GPT-5 for Claude Opus for Gemini Ultra produces minimal behavioral difference. Swapping the instruction layer, memory system, or tool architecture produces something fundamentally different. The model is the least architecturally interesting component. Everything else matters more.

Share:

Original Source

https://medium.com/@sathishkraju/what-actually-lives-inside-an-ai-agent-we-went-looking-43d3d3802592?source=rss------openclaw-5

View Original

Last updated: