Luis Gabriel

On the nature of Claws

2026-07-29


I think personal agents will be the defining form factor for software in the LLM AI era.

What started with Peter Steinberger’s OpenClaw (hence the claw nickname[1]) is gaining popularity. At first, I didn’t understand it very well. There was so much hype, mixed with inside jokes and name changes, that it was hard to discern signal from noise.

Now the appeal is clearer to me. I haven’t set up or tried a personal agent yet because of safety concerns[2], but I’ve become very interested in these kinds of systems.

I’m very curious to see how products from bigger companies will fare with a wider audience, especially the new Siri and Gemini Spark. I wouldn’t be surprised if, in less than a year, it becomes normal for the average person to use them daily.

What’s a personal agent?

I consider a personal agent to be a general-purpose, LLM-powered AI agent that’s highly customizable and specific to an individual user. They’re available via a chat or voice interface, commonly through a third-party messaging app like Telegram, Apple Messages or WhatsApp.

They have access to the outside world, both to gather relevant information and to act on behalf of the user. Relevant and broad context about the user and the situation is a defining factor.

Together with a memory system, skills and tools, the agent is empowered to continuously learn, improve and be customized through natural language.

Background and scheduled work are also present, so the user can run longer tasks in parallel or the agent can be proactive outside an ongoing interaction. Their proactive nature is also a main factor.

These systems are often deployed on a local machine or in a single-tenant environment, like a rented VM. But I think that’s more of a current implementation decision than a defining factor. It’s also common for them to have access to the computer environment via the terminal or CLI tools, so they can run code and access the file system.

Some examples include:

Coding and personal agents

As with most things in AI, the lines are blurred, but I see coding and personal agents as two distinct genres of the same category of products. While similar, personal agents differ from traditional coding agents in their goals and breadth, which influence their design.

Personal agents are derived from the original coding agents, Claude Code being the origin of them all. Even if personal agents can be used to write code and create programs (or coding agents can be used as general assistants), they’re more ambitious in scope. As the name suggests, a coding agent would be more akin to a freelance developer/engineer and a personal agent to a personal assistant.

Claude Code has more depth and is intended for development work; Hermes has greater breadth and aims to be a companion that supports more aspects of day-to-day life.

Sam Bhagwat, Mastra founder and CEO, gave a talk arguing that all AI agents eventually move toward being personal agents.

I’m not sure if I agree with that, and I can’t make up my mind about whether these two kinds of agents will converge or diverge. Currently, I would bet on the latter. We’ll get general-purpose personal agents to help us with a broad set of duties and errands, and specialized coding agents for those kinds of tasks. Of course, coding is just the start; other professions will have their own types of agents too.

The differences in target users and goals will directly influence their priorities, constraints and, therefore, their design. That’s why I think we’ll keep two different genres with their own popular products, even as some will do both.

The main components

Now that we have a baseline for what a personal agent is, I wanted to study how they’re built and designed. More than the code, I wanted to get a sense of the moving pieces and the main components that developers have to deal with.

These components all relate to each other but can be tackled as their own unique challenges. To build a personal agent, one has to at least keep them all in mind.

Model selection

Many projects isolate the LLM provider instance, so the agent is model-agnostic. I don’t see that as a hard requirement, but decoupling this logic from the rest seems to be a good design decision.

The main loop

That’s the core of the agent; it’s the orchestrator that makes all the parts work well together and “turns a message into actions and a reply”[3].

It sends the assembled context to the model, executes any tools the model calls and keeps the loop going until the model returns a final response or another stopping condition is met.

The loop may also handle retries, circuit breakers, permissions and subagent delegation. It can check whether context compaction or other maintenance work is needed between model calls.

Because it controls how the agent reasons and acts, this core is also where some systems can introduce unique features.

Context management

This determines what gets sent with each model generation. Some harnesses have been built entirely to deal with this question (famously, Pi was an answer to Claude Code context bloat). There are many parts of context management to take into consideration.

This includes the system prompt and files such as SOUL.md; message history and compaction when the context gets too long; and a memory system.

Context management also depends on persistence. Sessions, message history, memory and unfinished tasks have to survive across messages and sometimes across restarts. This state can be stored in files or in a database. But storage alone is not context management: the system still has to answer two questions—what to preserve and what to retrieve.

Anthropic (1, 2) prefers to work with a simple file-based system for memory. That’s also Hermes’ default, although it allows connections to third-party memory systems like Mem0, Honcho and others.

I find the way Chris Raroque implemented the memory system for his Boop agent to be one of the most interesting approaches to study, albeit a very expensive one.

Extensibility and customization

These are closely related to the memory system, but I consider them a separate component. They define what the agent is capable of doing, and they’re usually implemented with skills and tools (and MCP support). There are third-party services, like Composio, that help with that.

Tools also define a large part of the agent’s security boundary: what it can access, where its actions are executed, how credentials are handled and which actions require approval.

If the agent has access to the file system and can modify its own files, the user can extend and improve it just by talking to the agent itself. It’s a powerful design decision that Pi is known for.

The interface

Most of the agents I’ve seen implement some kind of message gateway, so they’re also platform-agnostic. That was one of OpenClaw’s core premises.

By using a message gateway, the agent can live inside the messaging apps people are already familiar with: Telegram, iMessage, WhatsApp and others.

However, not every run starts with a message. A scheduler can trigger background or proactive work, while the gateway delivers updates and results to the user.

There are even open-source message gateways ready to be used in any system, like Vercel’s Chat.

Overview

Considering all these components, a run may start either with a user message, received and normalized by a message gateway, or with a scheduled task from a scheduler. From that point, both inputs can follow similar paths:

Normalized input -> load state and build context (history, skills and memory) -> agent loop -> response or action

State can be persisted after the loop completes or between individual steps. The latter makes the system more resilient and easier to recover if execution fails midway.

Of course, this is not an extensive study or a breakdown of a specific agent, but a general exercise in breaking this system into discrete parts. I’m planning on building an agent from scratch to learn more about them, and thinking about that division has made things clearer to me.

If you’re interested in a real breakdown of how the most popular agents work, I highly recommend Alejandro AO’s videos.

Footnotes

  1. At least that’s the name it landed on after many changes. ↩

  2. Which I still think is a major hurdle these products must overcome. The challenge here is twofold: feeling safe and being safe. I think the former will be solved first. The average person already has iffy safety habits online, and humans are bad at assessing real risk. It’s only a matter of time before personal agents become widespread and a worthwhile attack surface.

    What I think makes these things more interesting is their non-deterministic nature. That trait makes agents less safe by default, but does that also make an exploit less scalable and repeatable?

    Frontier models are becoming better at defending against prompt injection, jailbreaks and other forms of attacks. Even if we can’t make them 100% secure against that, will they become good enough? Will anything less than 100% be satisfactory? ↩

  3. “The agent loop is the serialized, per-session run that turns a message into actions and a reply: intake, context assembly, model inference, tool execution, streaming, persistence.” OpenClaw Docs ↩

© Luis Gabriel

Made in 🇧🇷 with SvelteKit. Hosted on Netlify.