I use PAI (Personal AI Infrastructure) extensively. The system started as a structured way to configure Claude Code, then evolved into something broader: a composable architecture for extending an AI assistant with skills, hooks, agents, workflows, and deterministic enforcement layers.
Architecture: Files vs. Daemons
PAI lives in a .claude/ directory where every piece of the system is a file you can read with a text editor and back up with cp -r. Skills are Markdown documents describing capabilities, while hooks are TypeScript files that execute on specific events. Agents are personality definitions the model loads when spawned for particular tasks, and workflows chain them together through step-by-step procedures that reference whichever tools the job requires. Settings live in a JSON file you edit directly, which means the entire infrastructure is a directory tree.
OpenClaw runs a persistent Node.js Gateway process composed of five subsystems: channel adapters, a session manager, a message queue, an agent runtime, and a WebSocket control plane on port 18789. Messages flow from WhatsApp or Telegram into the Gateway, where the agent runtime processes them and returns responses through the same channel. The architecture is a server application with a daemon lifecycle. You start it, configure it, maintain it, and patch it. When it crashes, you debug a running process.
The difference is not aesthetic. A file-based system fails transparently: a broken skill is a Markdown file with bad syntax you can see and fix in seconds. A daemon-based system fails opaquely: a WebSocket connection drops, a message queue stalls, session state corrupts in memory. One failure mode requires a text editor. The other requires process debugging and enough familiarity with Node.js internals to trace what went wrong in a running system.
PAI's file architecture also means your AI configuration is portable. Copy the .claude/ directory to another machine, and your assistant works identically. OpenClaw requires reinstalling the Gateway, reconfiguring channel adapters, re-establishing daemon persistence through systemd or launchd, and hoping your session state transfers cleanly. Portability is the difference between a configuration and an installation.
Customization: Composition vs. Code
PAI at v3.0 ships with 38 skills and 20 hooks backed by over 160 workflows. Adding a new capability means writing a Markdown file that describes what the skill does and when it activates. The model reads the skill definition and follows the instructions, requiring no SDK and no plugin API. You describe what you want in the same language you would use to explain it to a colleague, and the system executes it.
Hooks provide deterministic enforcement. A hook fires on a specific event (file write, session start, prompt submission) and runs a TypeScript function that can modify or block the action. Hooks handle tasks like content validation and voice synthesis. Each hook is a single file with a clear trigger condition and a predictable outcome.
The agent system lets you define specialized personalities for different tasks. An Architect agent reasons about system design while a Pentester agent evaluates security, and an Intern handles grunt work with high agency. Each agent definition describes the agent's available tools alongside constraints that govern its behavior. When a task requires multiple perspectives, the system spawns a team that coordinates through a shared task list, where agents cross-validate findings before reporting results.
OpenClaw uses similar Markdown files for agent behavior, but meaningful extension requires JavaScript or TypeScript and understanding the plugin SDK.
PAI collapses the distinction between personality and capability. A skill that needs to call an API describes the API call in its workflow, and the model executes it through the bash tool. A skill that needs to coordinate multiple research agents describes the coordination pattern, and the model spawns them. The composability comes from the fact that every component is a text file the model can read and follow, which means adding capability requires only the ability to write clear instructions.
Running PAI: What Customization Looks Like in Practice
Daily use involves editing files. When a blog post comes out poorly written, the fix is a new rule in the anti-slop scanner or a refined instruction in the writing skill. When a research task misses important context, the fix is an updated workflow that spawns additional agents with different search angles. When a deployment goes wrong, the fix is a hook that validates before the push executes.
The blogging system illustrates the depth of customization possible. A canonical five-phase workflow orchestrates research (three parallel agents with distinct roles), strategy (thesis and argument structure), writing (per-paragraph inline validation against dozens of anti-pattern rules), automated scanning that must pass a 95/100 threshold before the post can ship, and finalization with artwork from a curated registry. Every phase has quality gates with explicit pass criteria. The pipeline runs through composition of Markdown instructions and agent definitions without custom application code, without a bespoke framework. Just files that describe what should happen and a model that follows them.
The hook system handles enforcement that instruction-following alone cannot guarantee. An anti-slop hook scans every file written to the blog directory and flags violations before they reach the repository. A session-start hook loads identity configuration and memory context. These are deterministic checkpoints that fire regardless of what the model decides to do, which is exactly what you want when the model might drift from your specifications.
Security: Attack Surface Is Architecture
OpenClaw's WebSocket control plane suffered a critical vulnerability (CVE-2026-25253, CVSS 8.8) that exposed 21,000 instances to hijacking before the patch arrived. Running a persistent daemon that accepts network connections creates an attack surface that a directory of text files simply does not have. PAI runs inside Claude Code with the permissions of your user account, which means no listening ports and no control plane accepting inbound connections. The attack surface is your filesystem permissions and the model's tool access, both of which you control through the same mechanisms you already use for local development.
OpenClaw's DM pairing system and Tailscale integration address real security concerns for a daemon that accepts inbound connections from messaging platforms. The engineering is sound. But the safest network service is the one you never run, and PAI never runs one.
Two Architectures, One Goal
OpenClaw approaches personal AI through a server application that mediates between messaging platforms and AI models, giving you multi-channel messaging and a heartbeat daemon for autonomous task execution. PAI approaches it through a directory of files that extend an existing CLI tool, giving you transparent configuration with composable skills and deterministic enforcement at zero operational overhead.
If you want an AI assistant that lives in your messaging apps and runs tasks autonomously on a timer, OpenClaw is the more direct path. If you want an AI development environment that you can inspect, modify, version-control, and extend without writing application code, PAI is the architecture that delivers.
The AI answers to me because every instruction it follows lives in files I wrote. That is what personal infrastructure means.