Personal Agent Ontology (PAO): Mapping the Shared Architecture of AI Agents

Every personal AI agent — OpenClaw, Claude Code, LangGraph, CrewAI, Letta — makes the same design choices: sessions, memory tiers, tool invocations, permission policies. Then each invents its own vocabulary. A "session" in one system is a "thread" in another. "Memory" means three different things depending on who you ask. The architecture is converging, but the language is not.

The Personal Agent Ontology (PAO) is a formal OWL 2 DL ontology that maps this converging domain. Created by Michel at Mepuka, it captures the shared structure that every agent implementation assumes — not as code, but as a domain model. It draws from academic research (cognitive architectures, BDI models, dialog act theory) and real implementations (Claude Code's session model, Letta's tiered memory, MCP's capability discovery).

The ontology is available as browsable HTML documentation, and as OWL 2 DL in Turtle, JSON-LD, and OWL/XML formats at purl.org/pao/.

What Is a Personal Agent Ontology?

An ontology, in the formal knowledge engineering sense, is a structured vocabulary that defines the concepts in a domain and the relationships between them. It's not code — it's a map. PAO uses the OWL 2 DL (Web Ontology Language) standard, the same formal framework used for biomedical knowledge bases like the OBO Foundry, industrial standards, and the semantic web.

PAO answers a specific question: what concepts does every personal AI agent implementation assume? Not how to build an agent, but what the domain contains. When you look across OpenClaw, Claude Code, Letta, CrewAI, and LangGraph, you find the same entities — sessions, memory tiers, tool invocations, permission policies, context windows — described with different vocabulary.

PAO aligns every top-level class to BFO 2020 (Basic Formal Ontology, ISO 21838-2), the same upper ontology used by the OBO Foundry's biomedical ontologies. This means an AIAgent is classified as a Generically Dependent Continuant — an information entity that depends on physical substrate (a server, a process) for its existence. A HumanUser is an Object. The distinction sounds academic until you reason about deployment migration: the agent persists across servers because it is information, not matter.

The 9 Modules

PAO organizes its 115 classes into 9 modules, each covering a distinct architectural concern that appears across every agent implementation:

Identity & Agents

The identity module starts with the simplest question: what is a personal AI agent? Agent is the base class, splitting into AIAgent and HumanUser. The distinction matters because their properties differ — an AI agent has a Persona (system prompt, behavioral configuration), belongs to a ModelDeployment, and can spawn a SubAgent. A human user has none of these.

SubAgent is a subclass of AIAgent, not a separate type. It has every property an agent has, plus a delegation relationship to its parent — its own session, memory, and tool access. This directly models systems like Claude Code, where sub-agents spun up for background tasks need the same architectural scaffolding as the primary agent.

Three concepts that most implementations leave implicit get first-class treatment: AgentRole (the same agent can act as researcher, coder, or reviewer), Organization (agents belong to tenants), and Persona (the behavioral configuration that makes an agent act like "a helpful assistant" or "a senior engineer").

The Conversation Stack

Most agent systems model conversation as "a list of messages." PAO exposes five distinct layers, each with its own architectural concerns:

• Conversation — spans multiple sessions, holds long-running thread identity and participants
• Session — a bounded period of interaction with status transitions (active, suspended, completed), owns the ContextWindow
• Turn — records who spoke and links to any ToolInvocations
• Message — the actual content within a turn
• ContentBlock — text, code, images, or tool calls within a message

The most interesting piece is context overflow. In PAO, ContextWindow is a first-class entity with token capacity, current usage, and a CompactionDisposition — the policy that determines what happens when the window fills. A CompactionEvent records that tokens were reclaimed, how many, and what was lost. Most architectures bury this as an implementation detail. PAO elevates it to an architectural concern because memory, tool tracing, and conversation continuity all degrade when context compacts.

The conversation module also includes a pragmatics layer drawn from DIT++ dialog act theory: DialogAct, CommunicativeFunction, CommonGround, and GroundingAct. These model why an utterance was made (requesting information, confirming understanding), not just what was said.

Channels add another dimension. The same agent might interact through CLI, Discord, web chat, email, or REST API. PAO models six channel types through a closed enumeration (owl:oneOf), which means a reasoner can verify that every channel has a recognized type. This matters for governance — a permission policy might allow tool execution through CLI but block it through email.

Memory Architecture

Agent memory looks deceptively simple from the outside: store things, retrieve things. PAO exposes an architecture closer to cognitive science than database engineering, drawing heavily from Letta (formerly MemGPT), the CoALA framework, and LangMem.

Letta's core insight, from the MemGPT paper, is that agent memory should work like an operating system's virtual memory: the LLM gets a fixed context window (analogous to RAM), and a tiered storage system pages data in and out. The LLM itself manages the paging.

PAO generalizes this into four memory tiers:

The operations between tiers matter more than the tiers themselves:

• Encoding — moves information from working memory into storage
• Retrieval — pulls information back into working memory
• Consolidation — transforms episodic memories into semantic knowledge
• Forgetting — removes items by policy or by request (privacy-aware deletion)
• Rehearsal — strengthens frequently accessed items

Each operation is a first-class process with provenance tracking via PROV-O derivation chains. When a Claim lives in semantic memory, PAO tracks which episode, turn, and message produced the evidence. If a user requests data deletion, the system can follow provenance chains to find every derived memory item.

Goals, Plans & Tasks (BDI Model)

This module borrows from the Belief-Desire-Intention (BDI) model in philosophy of mind. An agent holds:

• Beliefs — what it thinks is true about the world
• Desires — what it wants to achieve
• Intentions — what it commits to doing

Goals decompose into Plans, plans contain Tasks with dependencies and status. Deliberation is modeled explicitly: the act of choosing which goals to pursue and which plans to adopt. BDI gives agents a vocabulary for why they act, not just what they do.

The BDI model has deep roots in AI research, originating from Michael Bratman's philosophical work on practical reasoning and formalized by Rao and Georgeff in the 1990s. PAO adapts these concepts for the LLM agent era, where "beliefs" include the agent's context about user preferences and environmental state.

Governance & Safety

PAO treats governance as architecture, not an afterthought. A PermissionPolicy governs what tools an agent can use. A SafetyConstraint defines non-negotiable behavioral limits. ConsentRecord and RetentionPolicy handle privacy. AuditLog and AuditEntry record every authorization decision.

The ontology aligns to ODRL (the W3C Open Digital Rights Language) for policy representation. This matters because governance policies need to be machine-verifiable. A reasoner can check whether a given tool invocation is permitted under the active policies — not just at code review time, but at runtime.

External Services & Integration

This module covers how agents connect to the outside world. An ExternalService exposes capabilities (tool capabilities, resource capabilities, prompt capabilities) discovered through CapabilityDiscoveryEvent.

This module aligns closely with the Model Context Protocol (MCP), modeling the same connection lifecycle: discovery, authentication, invocation, disconnection. MCP has emerged as the standard for tool and resource discovery in agent systems, and PAO provides the formal domain model that MCP's protocol-level specification doesn't cover.

Error Recovery & Observability

Things go wrong. PAO classifies failures through ErrorRecoveryEvent (timeout, authentication, rate limiting) and tracks recovery strategies: RetryAttempt, ReplanEvent, RollbackEvent. Checkpoint and CheckpointDecision capture the agent's state before risky operations. OperationalMetric and MetricObservation provide observability hooks.

Model Identity

Tracks which FoundationModel, from which ModelProvider, through which ModelDeployment, produced each conversation turn. GenerationConfiguration captures temperature, top-p, and max tokens — the parameters that affect output quality. This is essential for reproducibility and auditing.

Scheduling & Automation

Handles recurring and triggered agent tasks. A Schedule binds a RecurrencePattern to an action. Triggers fire on cron expressions, intervals, or external events. ScheduledExecution tracks each run's outcome. ConcurrencyPolicy determines what happens when a new execution overlaps with one still running.

Academic Foundations

PAO doesn't exist in a vacuum. It draws from several established research traditions:

The CoALA framework from Princeton (Sumers et al., 2023) is particularly influential. It describes language agents with modular memory components, a structured action space, and a generalized decision-making process. PAO takes CoALA's conceptual framework and renders it in formal OWL 2, making the concepts machine-verifiable rather than just descriptively useful.

Real Implementations Mapped by PAO

PAO's value becomes clear when you see how it maps across real agent systems:

The table illustrates PAO's core thesis: the architecture converges even when the vocabulary doesn't. Every implementation has sessions, memory tiers, tool invocations, and permission policies — they just call them different things.

Why This Matters

PAO is descriptive, not prescriptive. It maps what the domain contains, not how to build an agent. That matters because the domain is stabilizing.

Here's what a formal ontology gives you that documentation and code can't:

• Shared vocabulary — When a team discusses "memory," they can reference specific PAO classes (WorkingMemory vs. EpisodicMemory vs. SemanticMemory) instead of talking past each other
• Completeness checking — When you design your agent's memory system, you can check whether you've accounted for consolidation and forgetting, not just storage and retrieval
• Machine reasoning — OWL 2 DL supports decidable reasoning, meaning tools can verify your agent model for consistency automatically
• Interoperability — A standard vocabulary enables different agent frameworks to exchange information about their capabilities and state
• Governance auditing — Every tool invocation can be traced through permission policies and audit logs using formal relationships

"The ontology makes the convergence visible. It gives agent builders a shared map — not to constrain design, but to clarify it."

Getting Started

PAO is freely available and ready to explore:

1. Browse the documentation — mepuka.com/pao/ provides interactive HTML documentation of all 115 classes, 173 properties, and 75 named individuals
2. Read the companion blog post — mepuka.com/blog/personal-agent-ontology/ walks through each module with architectural context
3. Download the ontology — Available at purl.org/pao/ in Turtle, JSON-LD, and OWL/XML formats
4. Load it into Protégé — The standard ontology editor lets you explore class hierarchies, run reasoners, and extend the ontology for your use case
5. Map your own agent — Take your agent's architecture and identify which PAO classes correspond to your components. The gaps are where you may be missing architectural concerns

# Quick start: download and explore with Python
pip install rdflib
python3 -c "
from rdflib import Graph
g = Graph()
g.parse('https://purl.org/pao/', format='turtle')
print(f'Classes: {len(list(g.subjects(predicate=RDF.type, object=OWL.Class)))}')
print(f'Properties: {len(list(g.subjects(predicate=RDF.type, object=OWL.ObjectProperty)))}')
"

Pros & Cons

References

1. Mepuka — Mapping the Domain of a Personal AI Agent (2026)
2. Personal Agent Ontology — HTML Documentation
3. PAO Persistent URL — OWL 2 DL Downloads
4. Sumers et al. — Cognitive Architectures for Language Agents (CoALA) (2023)
5. Packer et al. — MemGPT: Towards LLMs as Operating Systems (2023)
6. Basic Formal Ontology (BFO 2020) — ISO 21838-2
7. Model Context Protocol (MCP) — Anthropic
8. Claude Code — Anthropic Documentation
9. OpenClaw — GitHub Repository
10. Letta (formerly MemGPT) — GitHub Repository
11. CrewAI — GitHub Repository
12. LangGraph — GitHub Repository
13. LangMem — Cognitive Memory Framework
14. W3C PROV-O — Provenance Ontology
15. W3C ODRL — Open Digital Rights Language