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.

Persistent Agents

Beyond Forgetful Bots

Emerging Architecture for AI agents

> talk.start()

01 / REWIND

Let's rewind to 1973.

> ls /ibm/os360 # everything, in one place

01 / REWIND

The Unix mindset

  • shell + interface
  • small modules
  • chain them
$ cat access.log | grep ERROR | sort | uniq -c

The OS becomes a language. Composition over monolith.

> cd /history/unix

02 / THE PARALLEL

The agent, fully decomposed

LLM + shell + file system + markdown + tools

Everything but the model — we already had.

Latent power that sat in the shell for 50 years, waiting for something smart enough to use it.

> echo $AGENT # llm + shell + fs + md + cron
A diagram showing five rectangular blocks labelled 'LLM', 'shell', 'file system', 'markdown', and 'tools', connected by plus signs, illustrating the components of a decomposed agent.

03 / THE SHAPE

One shape, every framework

Interfaces → Gateway → Runtime → Execution → Output

Claw family • Hermes • Deep Agents – same skeleton.

> diff claw hermes deepagents # same bones

A horizontal flow diagram illustrates a common framework structure with five connected rectangular blocks: Interfaces, Gateway, Runtime, Execution, and Output.

03 / THE SHAPE

The gateway: hub & spoke

Inputs

  • Channels
  • Cron / heartbeat
  • Webhooks / CLI

Central gateway

  • stateless
  • routing
  • auth

Agent runtime

  • always on

Channels evolve independently from the agent's intelligence.

> gateway.route(any_input) → runtime

A diagram illustrates a hub and spoke architecture. Three input boxes on the left, labeled "Channels", "Cron / heartbeat", and "Webhooks / CLI", all point with arrows to a central box labeled "Central gateway". An arrow then goes from "Central gateway" to a final box on the right labeled "Agent runtime".

03 / THE SHAPE

What “always-on” actually means

It's not magic. It's a process that never exits.

  • daemon
  • cron
  • heartbeat
  • background jobs
$ If the gateway is running, your cron jobs are running.

> heartbeat = cron with a personality

04 / THE RUNTIME

The runtime: three pillars

The runtime consists of three core components:

  • Tools: what it can do
  • Models: how it thinks
  • Memory: what it keeps

All three run in parallel inside every agent. Two of them became the 2026 differentiators.

> runtime: { tools, models, memory }
A diagram illustrates three core components of the runtime: Tools, Models, and Memory. Each component is represented by a rectangular box, with the 'Memory' box highlighted with a green border.

04 / THE RUNTIME

#1 Memory

architectural differentiator in 2026

Memory is no longer context stuffing. It's first-class infrastructure.

> agents.forEach(a => a.remember())

04 / THE RUNTIME

Layered memory

In-prompt: active context - current task

Session search: FTSS / SQLite - episodic recall

Long-term curated: skills - knowledge base

Procedural: auto-generated SKILL.md

shorter
...longer retention

> memory.tiers = [prompt, session, longterm, procedural]
A diagram illustrates a layered memory system with four distinct tiers: In-prompt, Session search, Long-term curated, and Procedural, arranged vertically. Arrows indicate a progression from one layer to the next. Text on the right side labels the top layers as having "shorter" retention and the bottom layers as having "longer retention".

04 / THE RUNTIME

Where memory is heading

yesterday

Standalone vector store

one bolt-on DB
top-k similarity

today

SQLite + FTS5

BM25 full-text recall

Markdown files

greppable — model-native

Knowledge graph

entity links — temporal

Hybrid routing

right store per query

Production memory is a small stack — files + FTS5, plus a graph for entity-heavy queries — not one store.

SELECT note FROM mem WHERE notes MATCH ? — be25

A diagram illustrating the evolution of memory architectures. On the left, under "yesterday", is a single box labeled "Standalone vector store". An arrow points to the right, where under "today", there are four boxes: "SQLite + FTS5", "Markdown files", "Knowledge graph" (highlighted in green), and "Hybrid routing".

04 / THE RUNTIME

File System

A filesystem agent beat specialized memory tools — just by storing files and building relationship.

  • SOUL.md
  • IDENTITY.md
  • MEMORY.md
  • HEARTBEAT.md
> cat MEMORY.md # the agent's soul is on disk

05 / THE HARNESS

What's in the harness

Tools

shell · browser · code · APIs

Skills

self-written SKILL.md

The loop

plan · act · observe

The scaffolding that turns a raw model into a working agent.

  • Claw bundles
  • Hermes learning loop
  • Deep Agents toolkits - each wires it differently.
> while alive: plan(); act(); observe()

A diagram showing three conceptual boxes labeled 'Tools', 'Skills', and 'The loop'.

05 / THE HARNESS

Model layer — the swappable core

  • Claude
  • GPT
  • Grok
  • Ollama / local

Strong models plan. Light models execute.

State lives in files, so you can swap the brain and keep the agent. The model is a commodity; the harness around it is the moat.

> route(task.hard ? strong : light)

Four rectangular buttons are displayed, labeled "Claude", "GPT", "Grok", and "Ollama / local" respectively.

06 / SCALE & SAFETY

Patterns to scale beyond one agent

  • Orchestrator → workers
    decompose • delegate • merge
  • Sequential pipeline
    fixed stages, step by step
  • Parallel fan-out / in
    independent work, merged
  • Hierarchical
    managers delegate to teams
  • Debate / maker-checker
    one builds, one verifies
  • Dynamic handoff
    route to the right specialist

Reach for multi-agent only when one agent genuinely can't cope — it adds cost and new failure modes.

> compose(patterns) # not a single silver bullet

06 / SCALE & SAFETY

Security is not bolted on

  • Sandbox & isolation
    network-off micro-VM / container for code & tools
  • Prompt injection
    treat all tool output as hostile / goal-lock
  • Least privilege
    scoped, short-lived creds / no wildcard tools
  • Human-in-the-loop
    approval gates on high-impact actions
  • Memory poisoning
    validate before persisting / sign skills
  • Audit & kill switch
    log every action / revoke on anomaly

> OWASP agentic top-10 # injection = ASI01

06 / SCALE & SAFETY

Production readiness

  • backups
  • audit logs
  • reliability
  • cost ceilings
  • incident response
  • observability

Treat the agent like a service, the same operational rigor, plus hard cost ceilings.

> tail -f /var/log/agent/audit.log

07 / END-TO-END

Emerging Architecture

  • User Channels

    WhatsApp, Slack, Web, CLI, cron

  • Gateway

    stateless, routing, auth, protocol

  • Agent runtime (reasoning loop + planning)

    • Tools & Connectors

      shell, browser, connectors, apis

    • Models

      multi-LLM routing

    • Memory

      short, long, procedural

  • Secure and Hardened execution

    sandbox, least privilege, human gates, audit

  • Outputs & actions

    reply, task done, new skill, A2A delegation

A block diagram illustrates an emerging architecture for an agent system. It depicts a layered structure, starting with User Channels at the top, flowing through a Gateway, then an Agent runtime (comprising Tools & Connectors, Models, and Memory), followed by a Secure and Hardened execution layer, and concluding with Outputs & actions at the bottom. The Memory component is visually emphasized with a green border.

Thank you

Navan Tirupathi

CTO in a ralph loop

https://www.linkedin.com/in/navan-tirupathi

People

  • Marc Andreessen
  • Simon Wilson

Technologies & Tools

  • Bash
  • Claude Code
  • CLI
  • Deep Agents
  • Hermes
  • LLM
  • Markdown
  • Obsidian
  • Slack
  • SQLite
  • Unix
  • Vector stores
  • WhatsApp

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