Beyond Forgetful Bots: Architectural Patterns for Persistent, Proactive Claw-Style AI Agents
Introduction: The 2026 Shift in Always-On Agents
Speaker C opens by describing a fundamental architectural shift enabling agents that are always on, possess memory, and can autonomously complete tasks. He previews the talk's goal of unpacking the building blocks behind this shift, noting that many components are already familiar but rarely viewed as a cohesive architecture.
The Unix Mindset: Historical Roots of Agent Architecture
Drawing on a Marc Andreessen anecdote about 1973 Bell Labs engineers escaping monolithic systems, Speaker C connects the Unix philosophy of shells, small modules, and piping to modern agent design. He explains how agents now embody this Unix mindset with LLMs, shells, file systems, and tools, enhanced by added intelligence from models like Claude Code and OpenClaude.
Common Agent Patterns: Gateway, Runtime, and Execution
Speaker C identifies a common architecture across agent families like Claude, Hermes, and Deep Agents, consisting of a gateway, runtime, execution, and output. He argues that understanding these shared components allows builders to construct new agents without deep-diving into every framework individually.
Understanding the Gateway and 'Always-On' Daemon
The speaker details the gateway as a central hub handling all inputs—Slack, WhatsApp, webhooks—decoupled from the agent's runtime brain, enabling authentication, policy enforcement, and scalability. He demystifies 'always-on' agents as daemons running cron jobs and heartbeats, describing this as essentially 'a personality with a heartbeat.'
Runtime Components: Tools, Models, and the Rise of Memory
Speaker C breaks down the runtime into tools, models, and memory, noting that models are becoming commoditized while memory emerges as the key architectural differentiator in 2026. He emphasizes that memory has evolved beyond simple context stuffing into a core innovation area.
Layers of Memory: From Prompts to Procedural Learning
The speaker outlines memory's layered structure—prompt-level system instructions, session/episodic search, long-term curated knowledge (skills and markdown), and procedural self-improving loops seen in frameworks like Hermes. He references OpenCloud's 'Dreaming' feature as an example of optimizing the transfer from short-term to long-term memory.
Emerging Memory Technologies: Markdown, Knowledge Graphs, and Plug-in Memory
Speaker C discusses how markdown files have become a highly efficient memory storage method, often indexed via SQLite for full-text search, complemented by knowledge graphs for entity relationships. He highlights hybrid memory approaches and the rise of portable plug-in memory systems that let agents swap frameworks while retaining stored knowledge like skill.md and soul.md files.
Harness as the New Core: Scaffolding Tools, Skills, and Loops
The speaker explains 'harness' as the scaffolding of tools, skills, and feedback loops that transforms a raw model into a working agent, citing examples like Claude bundles, Hermes learning loops, and Deep Agents toolkits. He positions harness alongside memory as a critical differentiator now that models are becoming commoditized.
Model Layer and Multi-Agent Orchestration Patterns
Speaker C describes best practices for model selection—using stronger models for planning and swappable models for execution—then transitions to multi-agent architecture patterns including orchestrator-worker, sequential, parallel fan-in/fan-out, hierarchical, and creator-reviewer debate setups. He notes that real-world use cases often combine multiple patterns rather than relying on a single approach.
Security as a Core Requirement, Not an Afterthought
The speaker stresses that security must be built into agent architecture from the ground up, referencing Simon Willison's 'lethal trifecta' of private data, untrusted content, and external communication as a major risk combination. He covers prompt injection, least privilege access, human-in-the-loop safeguards, memory poisoning risks, and the necessity of audit trails and kill switches.
Production Readiness: Reliability, Cost, and Observability
Speaker C addresses the final challenges of deploying agents to production, including config/memory backups, audit logging, handling non-deterministic model failures and tool call errors, managing costs, and adapting incident response processes for autonomous agents. He emphasizes observability across all actions, inputs, and outputs as essential for trustworthy deployment.
Closing Summary: Building Blocks of Emerging AI Architecture
Speaker C concludes by synthesizing the full architecture—channels, gateway, runtime, secured execution, and output actions—into a unified framework diagram. He predicts these layers will continue to expand and innovate, but the core building blocks will remain traceable, closing the talk with thanks to the audience.
Thank you, and welcome, everyone. And in 2026, there has been a fundamental shift on the agents. You will notice that agents are always on, and it has its memory. It can get things done for you. And there's a lot more progressed on that. And if you really look deep, there is a fundamental architecture change that has sort of enabled all of this.
I'm going to cover that in detail in this pack. And you'd be surprised to see that many of them you would be already familiar with, but then we don't see that as a massive building blocks that cover those things. For that, let's rewind fifty years. And I think this was one of my inspiration from Mark Anderstein's talk in one of the podcast, where in 1973, in Bell Labs, a handful of engineers are about to make a design decision that still drives our everyday phones to Internet, to our machines, and all of them. They were fighting against the big monolith system, which is tightly coupled. It does the job, but it's very hard to break them in terms of navigate that.
And then they sort of come back with the term, let's do something different, and that can allow escape that big monolith system. And I'm talking that as a Unix mindset. So most of you have been familiar on Unix mindset. Unix is all about you have a shell and an interface. Given a shell and an interface, you can get a lot more things done. And then you can have a lot of small modules.
You can chain them, pipe them together, and achieve what they want. And this sort of makes sense, and that's the way things have evolved for a longer period of time. And if you notice, agents now start realizing this pattern really works, right from Piped out dev to OpenCLAR to other things.
Pretty much they start seeing how we can navigate that particular setup. So when you take that agent fully decomposed, it's very similar to Unix mindset where you have an LLM and you have a shell, you have a file system, markdowns, and tools. These are the things we already had before, so it's not a lot changed. Many of the components are the same.
But you are adding a model to it. You are adding intelligence to it. And that sort of makes a lot more easier on this whole thing. Right? So that's the power of that framework. Now agents with clot code and everything start progressing on CLI, and enabling all of that makes significant changes. So you take any different family of agents that we come across Claw, Hermes, Deep Agents pretty much they all follow a common set of patterns. One is a gateway.
Another one is a runtime. And you have interfaces that connect to a gateway, then sort of runtime comprise of a few components, which we'll cover in deeper. And then you have the execution of them, and then you get an output. So pretty much, instead of going through deep dive of every framework, we can start looking back and then see what are those components. And in the future, if we build agents, we just have to acknowledge and then have these patterns and you can create another agent.
So let's start with gateway. So the gateway is a central hub. And if you really see any channels, like if it's a WhatsApp or a Slack, a webhook or a ping, all of them are acted as an input to the gateway. So this is a difference. Typically, when you say a gateway, you always say external API coming in or some interface coming in, channel inter coming in.
But here, the gateway is an input for almost all the things that's coming in as an input, and that completely differentiates, decouples from the actual brain, which is the runtime. And that gateway sort of can handle authentication, can apply policy, can be stateless, and it can be decoupled for different channels. Even if you're deploying agents in your enterprise setup, so you can allow a few channels.
It does not have to be all channels, but it enables the scalability of channels and the interfaces. And it can apply same rules of even if the interface comes from internal. Right? So that that's so gateway can apply standard policies and authentication. So they sort of works that way. And all of that act as a spoke, and then you have a hub, which which is a gateway that progresses it.
And I also want to unravel what is always on, so called always on, means. It's nothing but a daemon running on that machine, basically. It's a unique machine, a daemon running on it. And then you have a cron, heartbeat, background jobs. All of that actually makes it we feel always on. But if you really deep again, how it's pinging me in the night when I'm at sleep, it's because there may be some waybook it would have received in the night.
And because the daemon is already in listening mode, it sort of handles it. So that's what happens in this. So as per the OpenCLOUT terminology, if you say if the gateway is running, that means your cron jobs are running. Basically, something is running under the hood. So basically, your cron job is a is personality, basically, a personality with a heartbeat. That's what is a cron job nowadays.
So now then we deep dive into runtime. Then runtime, when you decompose further, you have tools, models, and memory. Tools, you can expand tools to connectors, MCPEs, and so on, so it can get broader. But predominantly, it has the tools. It's from Bash to all Unix tools, searching tools, and you can keep adding on top of it.
Then you have a model where the actual thinking happens and then memory, what it keeps. And this is what is the change where the models are becoming like a commodity, where you can actually switch between the models for the different tasks. So the number one differentiator, I think we have seen the talk this morning as well, is the memory is the key differentiator of architecture in 2026. Memory is no longer just a context stuffing.
It is becoming a core. And a lot of innovations are happening on how we optimize the memory in a right way for the agent to function efficiently. So we have seen in the morning session as well that the memory is comprised of several layers. You start with imprompt, which is nothing but your system instructions, your recent chat messages, or your tool output, and so on.
And then you have a next layer where you can session search where you can go back to your conversations and find what are all things as in conversations and a lot more episodic in nature where you can start having the episodes stored. And then you have your long term curated layer of memory. Md, your skills and knowledge base, and that's that's your long term layer. The last one, which is also emerging where which is procedural where your procedures, processes are getting self improved loop happens, especially in Hermes or other other frameworks where it updates the skills.
Md based on the learning. So there is a learning loop can also go back and update the memory. So the memories will have short to longer retention. And a lot of optimizations are happening, even in the recent OpenCloud Dreaming feature, which is nothing but what are the efficient method it actually uses to write it to the long term memory from a short term memory. So all of that is emerging areas in the architecture.
So where is memory heading? Two years back, we were always talking about vector stores and some sort of top case similarity and all of that. Now we have a few more areas that emerges in memory. Most importantly, the biggest change is the markdown files. Markdown files are super efficient. You sort of store a lot of them, and you can actually create them, search them, so you can get a lot done from that. And then you sort of create a full text search or a best match searches if you can take the context of some of the markdown into an SQLite.
And that sort of and this is similar how it's done in OpenCLI as well. So it acts as an index or reference to a markdown file. And even there's a post of creating a second brain with Obsidian, markdown goes really well there. And sort of you create an index and cover that. Then you have knowledge graphs. You may need knowledge graphs if you want to define entity relationships, any facts, any temporal things you want to connect, then it's knowledge graph. So it's not just either this or that.
Nowadays, everything is becoming hybrid. When you run a hybrid query, you can run an SQLite search with a markdown file. Then if you want to go back to finding the relationship, then you go to knowledge graph and then sort of work through all of them. So it is possible, but that's an emerging area. And new plug in memories are also emerging, where you have another memory externally. You plug it to an agent.
That way you can keep swapping your agent framework. Your memory is still there. Very much skill. Md, memory. Md, soul. Md, all of them are becoming very common patterns that you can actually transfer to other agents. So file system being one of the most transformative change in this year, and Grip and Search works most of the time.
There was a study that 74% of the time, pretty much running markdown and searching and gripping gives the context that's required. Of course, you want to go from 74% to more, you can actually go beyond. The second important differentiator is hardness. I know we would have talked about a hard I think a lot of people, a lot of hype or a lot of messages about hardness became the core.
Then model becoming commodity, and that's the change that's happening. What is in the hardness? Yes, we talked about memory. Yes, that's an important part. But on top of it, once again, it's tools, skill, and then the loop, pretty much. So I think by scaffolding all of these into a raw model, you create a working agent under the hood.
And there are different methods of harness or this bucket where you have a cloud bundles or Hermes as a learning loop. Deep agents have toolkits. So all of these are different methods of how they tackle the harness. So escorting harness is a lot more evolving. Even agentic harness have the similar building blocks. So then is the model layer being the middle, definitely spappable core in terms of different models depend on the need.
And typical practice is to use a stronger model for planning and then for execution, you can actually swap between the different models. And that becomes truly like a commodity, whereas your states are kept in the memory. So have seen about memory hardness and then the model.
And if you want to scale beyond from a deployment perspective, we've got to start looking at what are the different patterns. Yes, we start creating agents with this concept. Then how can you go multi agents? If you go multi agents, then you have different agentic patterns for multi agents. I will not have time to go through all of them in detail, but just to give you a snapshot of these are the different patterns of a multi agent framework where you can orchestrate one agent act as an orchestrator, another one as a workers, then it works between them.
Or you make it sequential. Or if your latency is a key, then you would do a parallel fan in, fan out. Or it can be hierarchical for certain managing and delegating a task. You can have a creator and then the reviewer from a debate make checker. So once again, it is not like you have to pick one or the other.
Even for one big use cases, you may go more than one pattern, and then you will set up the agent in a way that you can either this or that. So it's going to be like that. So usually, you would have a main agent and a sub agent, and you will fork them on different patterns. So that is one of the ways you can scale your agentic framework into different patterns.
Yeah, security is not a bolt on. I think every agent framework when we talked about Unix, Unix gives a lot of freedom. And it also enables a lot of power. But that means it comes with a lot of responsibility. And that is where we have all seen in the past, initial days of Unix, you would have lived there at the time, and we sort of seen there are security things, how we tackled.
And same thing applies to agents as well. So we got to go through all the different aspects of security from the ground up, from a sandboxing perspective. And there is a good saying of lethal trifactor from Simon Wilson where if you have a private data and if you have an untrusted content and then have an external communication, If all of the three are enabled as a tool to an agent, you are asking for a problem. So we've got to start thinking about how you decouple them, isolate them, and then sort of execute.
Then sort of other methods of prompt injection. And that's being one of the biggest vulnerability. And the trifactor comes in truly. When you know the prompt is going to be injected, then you sort of need to take care. Any instructions in a skill. Md to say please take care doesn't help there. So least privilege as an access mechanism, human in the loop.
Memory poisoning is also one of the most important emerging areas where because memory is becoming very important, your long term memory can get corrupted or rewritten, and you need to have different policies to ensure that's being taken care. And last, you need to still have an audit and kill switch for every auction. So last but not the least, the production readiness.
Yes, you have done all of this. Still, there is a last mile to go. This has always been a challenge when it comes to taking agent to the production, where you need to think about, Okay, what I'm going to do with the backup of the config or the memory I'm using? What audit logs I can support to say this is what has happened and to prove that this is the action that is taken? Reliability is another key area where you need to handle the failures. It is possible model gives you the different incorrect response.
It is not deterministic. And it is also there are tool calls can fail in between how we are going to tackle. Cost being another critical aspects of how you make sure that costs can be managed, monitored. And also incident responses, how do you manage your incident response process with agents working compared to if there is a human in the loop and then doing it, how we are going to handle that.
And observability as another area where you need to observe at different actions taken, different inputs, outputs, and then the entire execution steps. So all the pieces put into one slide where you see different layers right from channels, then you sort of have a gateway layer, then you sort of have a runtime, and then you can have a secured hardened execution and then the output actions.
And pretty much this forms the building blocks an emerging AI architecture. And I'm sure all these layers will expand and innovate, but pretty much easy to trace back to these building blocks.
That's all. Thank you.
People
- Marc Andreessen
- Simon Wilson
Technologies & Tools
- Bash
- Claude Code
- CLI
- Deep Agents
- Hermes
- LLM
- Markdown
- Obsidian
- Slack
- SQLite
- Unix
- Vector stores
Concepts & Methods
- Episodic memory
- Fan-in fan-out
- Gateway pattern
- Harness
- Hierarchical pattern
- Human in the loop
- Kill switch
- Knowledge graphs
- Least privilege
- Lethal trifecta
- Memory poisoning
- Multi-agent patterns
- Observability
- Orchestrator-worker pattern
- Procedural memory
- Prompt injection
- Runtime
- Sandboxing
- Unix mindset
Organisations & Products
- Bell Labs
Most AI agents are reactive chatbots—great for one-off queries, but they reset, forget, and lack initiative, failing in real-world use like personal assistants or autonomous workflows.
This talk dives into the battle-tested architecture of Claw-family agents (OpenClaw and lightweight forks like NanoClaw, PicoClaw, TinyClaw, IronClaw, ZeroClaw), which power persistent, proactive systems that run 24/7 on your devices. Drawing from real implementations, we’ll unpack core patterns:
Hub-and-Spoke Separation: A stateless gateway routes inputs (messages, heartbeats, cronjobs, hooks, webhooks) while adapters normalize diverse channels (WhatsApp, Discord) and enforce typed protocols/security handshakes.
Ephemeral vs. Persistent State: Transient context (system prompts, recent interactions) stays token-efficient; durable memory (append-only logs + curated facts) uses hybrid retrieval (semantic + keyword) with flush safeguards to survive compaction/restarts.
Runtime Loop & Extensibility: RPC streaming for task queuing/execution; plugin discovery (tools, providers, memories) and Markdown-based skills (SOPs) enable hot-loading without recompiles, plus multi-agent delegation for collaboration.
Security Boundaries: Defense-in-depth with network isolation, sandboxed sessions (e.g., Docker for untrusted chats), identity pairing, and safeguards against injection/poisoning.
Proactivity and Deployment: Inputs trigger autonomous actions; architectures span local native, VPS/Docker, or cloud for low-resource edge devices.
Whether forking OpenClaw or building similar agents, this playbook delivers insights on separation of concerns, model-agnostic brains, and tradeoffs for scalable, secure AI that feels truly alive—beyond single sessions.














