“Claws” is the emerging name for a layer that sits above LLM agents: always-on, event-driven, and reachable from your phone instead of living in a chat window you open and close. We have run one for months. Here is what the idea gets right, and the one feature we deliberately refused to build.
Where the term “Claws” came from
The word started as an offhand coinage in a widely shared post by Andrej Karpathy, and it spread fast — a few hundred points on Hacker News inside a day. The argument underneath it is more interesting than the label. Most people’s experience of an AI agent is a session: you open a window, type a request, watch it work, close the tab. Everything the agent knew dies with the tab. A claw inverts that. It runs whether or not you are watching, wakes up when something happens in your systems, keeps context you can edit yourself, and answers when you reach for it from a phone on a train. It describes a shape, not a product — which is exactly why it caught on so quickly among people who had already built the shape.
What actually makes something a claw and not a chatbot?
Four properties, and you need all four. First, persistence: the thing runs continuously instead of being summoned. Second, event triggers — it reacts to a webhook, a schedule, a failing build, not only to you typing. Third, durable context you own and can edit in plain text, so the agent’s understanding of your project is not trapped inside a transcript. Fourth, bidirectional remote control: you can see what it is doing and redirect it from wherever you happen to be. Remove persistence and you have a chatbot. Remove event triggers and you have a chatbot with good memory. Remove owner-editable context and you get something that slowly drifts away from what you actually meant. The combination is what changes how the work feels day to day.
The four pieces we already had
Reading the discussion was a slightly odd experience, because we had built all four without ever naming them. Our AI development platform runs a background worker continuously — it walks a ladder of scheduled work deciding what is due, and it replays repository events as they arrive, so a push or a pull request wakes it up rather than waiting on a human. Project context lives in plain markdown documents an operator can open and hand-edit; those edits are detected and synced back into the system, then published to the repository, so the file and the database never quietly disagree. Remote control works from a phone over an authenticated channel. Capabilities come from a curated, first-party-only skill set in which anything that writes passes through a human gate.
None of that was built because a term existed. It was built because running a code-generation pipeline on a laptop you have to babysit is miserable, and every one of those four properties removed a specific reason we were being woken up.
The feature we turned down, and why
Here is the part I find more useful than the taxonomy. A claw is supposed to be reachable from anywhere, and we already had a dormant chat-bot integration sitting in the codebase — half-wired, easy to finish, an obvious win on the reachability axis. We went to switch it on. Then we actually read it. The command path had no check on who was sending the message: anyone who found the endpoint could issue instructions to the system. Finishing it would have bought a second, weaker copy of a remote-control feature we already had in authenticated form, and paid for it with an unauthenticated command surface. So we left it off on purpose and wrote down the reason.
That is the same instinct behind the guardrail we added for secrets in AI-generated code. The failure mode of an always-on system is rarely that it does too little. It is that it does something, correctly, for the wrong person. Reach is not a feature if anyone can grab the handle.
Always-on is a security posture, not just a convenience
My honest reservation about the claw framing is that it gets sold almost entirely as ergonomics: always there, always warm, no cold start. But moving an agent from a session you open to a process that never stops changes your threat model, and most of the conversation around the term skips that. A session-bound agent can only act while you are watching. A persistent one acts at three in the morning, in response to an event no human reviewed, using credentials that stay live the whole time. That is precisely why we keep every write human-gated and the skill set first-party rather than open to arbitrary third-party plugins. The convenience is real and I would not give it back. It is just not free, and the word makes it sound free.
Is it a real category or a new name for old plumbing?
Both, and that is fine. Nothing in the four properties is novel on its own — daemons, webhooks, and remote consoles are decades old, and multi-agent orchestration systems have combined them for a while now. What a good name does is let people ask for the bundle. Before, a client asking for “an AI that just handles it” had to be walked through four separate infrastructure decisions. Now there is a word for the destination, which makes the conversation shorter and the expectations clearer. That is worth something, even if the underlying parts are ordinary.
Frequently asked questions
What does “Claws” mean in AI?
It is an informal term for a layer above LLM agents that runs continuously, reacts to events rather than only to prompts, keeps context the owner can edit directly, and can be controlled remotely. The name was popularised by Andrej Karpathy. It describes an architecture pattern, not a specific product or vendor.
How is a claw different from an AI agent?
An agent typically lives inside a session you start and end. A claw persists between sessions and acts on triggers — a code push, a schedule, a failed build — without anyone opening a window. Think of the agent as the worker and the claw as the always-on environment that decides when the worker should wake up.
Does every team need an always-on AI agent?
No. If your AI work is occasional and you are happy to supervise it live, a session-based tool is simpler and safer. Persistence pays off when work arrives as events you would otherwise have to catch by hand — build failures, pull requests, scheduled checks — and when waiting for a human to be at a desk is the actual bottleneck.
What is the main risk of an always-on AI agent?
Unattended action with live credentials. Because it runs when nobody is watching, any weak entry point becomes a way to make the system do real work on someone else’s behalf. Authenticate every control channel, gate writes behind human approval, and be deliberate about which capabilities the agent can load.
