I thought that was the ceiling. Prompt engineering, then context engineering, then harness engineering — each one solving the failure of the previous layer. A clean, tidy story with an ending.

It doesn't end there.

In June 2026, a new term started spreading through the AI engineering community: loop engineering. Addy Osmani (engineering lead at Google Chrome) synthesized it into a single framing, pulling together ideas that Boris Cherny at Anthropic and Peter Steinberger had already been describing in their own workflows. The post that kicked it off reportedly crossed 6.5 million views in days.

Here's the sentence that made me stop and rethink everything: stop prompting your agent, and start designing the loop that prompts it for you.

Let me walk through what that actually means, why it's a genuinely different discipline from harness engineering, and how I'm applying it to Anton.

The Ladder So Far

Before loop engineering makes sense, you need the full ladder underneath it. Each rung exists because the previous one hit a wall.

Prompt Engineering (2020–2022)
  → All intelligence lives in the prompt string
  → Breaking point: tiny context windows, no tool use, purely stateless

Context Engineering (2022–2024)
  → Agent autonomously gathers relevant info via RAG, tool calls, MCP
  → Breaking point: no iteration primitive, context rot over long tasks

Harness Engineering (2024–2026)
  → An outer shell manages state externally, feeds fresh context per call
  → Breaking point: harness still waits for YOU to say "go"

Loop Engineering (2026–)
  → The system prompts itself. No human in the loop at all.

That last line is the entire shift. A harness makes an agent reliable once it's running. A loop decides when it runs, whether it needs to run again, and when it's actually done — all without you sitting there.

The distinction, stated precisely: harness engineering builds the environment the agent operates in — skills, tools, hooks, permissions. Loop engineering designs the runtime that drives the agent through that environment — the loop contract, the state, the checkers, the stop conditions.

A good loop needs a good harness underneath it. They're not competing layers. They're stacked.

Why Now, Specifically

This isn't a random rebrand of an old idea. There's a real capability threshold that got crossed.

By mid-2026, coding agents could run autonomously for long stretches — sometimes an hour or more, touching dozens of files — and recover from their own mistakes well enough that babysitting every step stopped making sense.

When a single agent run might last an hour, the highest-leverage thing you can do stops being "write a sharper prompt." It becomes "design a loop that starts the right work at the right time, checks it properly, and knows when to stop."

The bottleneck moved from model capability to orchestration design. That's the whole story in one sentence.

The Four Loop Types

Not every loop looks the same. There are four recognized shapes, and most production systems combine two or three of them.

Heartbeat loops
  → Runs continuously on a short interval (every 5–10 minutes)
  → Wakes up, checks if there's work, acts if so, sleeps if not
  → Example: a support-queue agent that checks for new tickets every 10 min

Cron loops
  → Scheduled at specific times (daily at 10am, every Monday)
  → Predictable, low-surprise, good for reporting and maintenance work

Hook loops
  → Triggered by events — a PR push, a CI failure, a webhook firing
  → Reactive rather than time-based
  → Example: a fix-loop that launches the moment tests fail on main

Goal loops
  → Iterates until a defined success condition is met, then stops
  → No fixed schedule — runs until "done," however long that takes
  → Example: "research the competitive landscape and produce a report"

Goal loops are the most powerful and the most dangerous. The strength is unbounded effort applied to a well-defined goal — the agent keeps trying different approaches until one actually works. The failure mode is exactly the same property working against you: goals without a convergence criteria.

"Research the competitive landscape" doesn't have a clear stopping condition. The agent runs, and runs, and runs, burning thousands of tokens before anyone notices. Every goal-driven loop needs, non-negotiably: a max iteration cap, a budget cap, a success function the agent can actually evaluate against, and an escalation path for when the goal genuinely can't be met.

The Five-Layer Loop Anatomy

Here's the part that actually matters if you're building one of these. A production loop is made of five components layered together.

1. The Harness (environment)
   Skills, tools, hooks, permission boundaries
   — everything from the previous post in this series

2. The Loop Contract (what "done" means)
   The explicit, checkable definition of success
   Not "make it better" — a condition a program can evaluate

3. The State Layer (files and task lists that survive restarts)
   Durable, external, disk-backed — not conversation history
   This is what makes the loop resumable after a crash or a pause

4. The Checker (automated verification)
   Compiler, test suite, linter — anything that gives a real pass/fail
   Deterministic where possible: "did the tests pass" beats "does this look right"

5. The Human Checkpoint (where a person reviews before irreversible actions)
   The one point where autonomy stops by design
   Merging to main, sending an email, spending money — gated behind a human

Notice that four of the five layers exist specifically to make autonomy safe, not just possible. Loop engineering isn't "remove the human." It's "decide precisely where the human still belongs."

Deterministic vs Non-Deterministic Loops

This distinction turned out to be more useful than I expected once I started applying it to Anton.

Deterministic loops use test/compile gates. The checker is a program — a test suite, a build step, a type checker. It either passes or it doesn't. No ambiguity, no judgment call.

Non-deterministic loops use reviewer/quality gates. The checker is itself another LLM call — a verifier subagent that reads the output and judges whether it's good enough. This is necessary for tasks that don't have a clean pass/fail signal — writing quality, architectural soundness, whether a summary actually captured the important points.

Deterministic example:
  Trigger: cron every 15 minutes
  State check: read production health checks
  Decision: all passing? → log and stop. Something failed? → open a fix loop
  Execution: launch a coding agent in a FRESH git worktree with the failing
             test as the explicit goal
  Verification: stop only when the health check actually passes
  Memory: write a short note about the failure pattern for next time

That's a real, working pattern people are running today against Hermes Agent — the self-improving agent framework I covered in the ecosystem post. Notice the fresh git worktree. That's harness engineering (isolated state) feeding directly into loop engineering (the retry cycle around it).

Non-deterministic loops are riskier by nature — a bad verifier subagent can approve bad work just as easily as a bad human reviewer can. The general advice: use deterministic checks wherever a real one exists. Only fall back to a reviewer-agent checker when there's genuinely no programmatic way to verify success.

The Six Components, Concretely

The original breakdown of loop engineering names six building blocks that show up across every real implementation: automation, worktrees, skills, plugins/connectors, subagents, and state.

Let me connect each one to something concrete.

Automation — the heartbeat. The recurring trigger that surfaces work without you asking for it. Without this, you don't have a loop, you have a single run you did once.

Worktrees — isolated task environments. Each autonomous run gets its own git worktree so parallel agents don't collide on the same files. This is the thing that lets you run five fix-attempts simultaneously without them corrupting each other's state.

Skills — the SKILL.md pattern from harness engineering, reused here. A loop doesn't reinvent how to do a task every time — it calls a known, tested skill.

Plugins/connectors — how the loop reaches outside itself. MCP servers, webhooks, API integrations. The loop needs to touch the real world (read a ticket queue, check a deployment status) to know if there's work to do.

Subagents — used for verification and parallelization. A subagent can check another subagent's work, or split a big task into pieces that run concurrently.

State — the layer that survives restarts. Exactly the AntonState struct I described in the harness engineering post — task queues, completed work logs, failure records — living on disk, not in a message history.

Together, these six components are what let a loop run for hours or days without a human watching, while still being debuggable when something goes wrong.

A Real Example: The World Cup Scores Site

The clearest illustration I've found of all four engineering layers working together at once is a deceptively simple example: an agent that builds and then continuously maintains a live World Cup scores website.

Here's how the layers stack in that scenario:

Prompt engineering:
  The initial instruction — "build a live scores website for the World Cup"

Context engineering:
  The agent pulls in real match data via tool calls / RAG
  to know what's actually happening in the tournament

Harness engineering:
  Manages the ongoing build — fresh context per file/component,
  durable state tracking what's been built and what's pending

Loop engineering:
  A heartbeat loop wakes every few minutes DURING live matches
  Checks: has the score changed? Is there a new match starting?
  If yes: updates the site autonomously, verifies the build still compiles,
  and only escalates to a human if something breaks in a way
  the checker can't resolve on its own

Nobody is sitting there manually refreshing the site's data every time a goal is scored. The loop notices, updates, verifies, and moves on — for the entire duration of the tournament, unattended.

That's the actual promise of loop engineering: not one clever autonomous run, but a system that keeps itself correct over an extended period of time with minimal human attention.

The Skepticism Is Real, and Worth Taking Seriously

I want to be honest about this rather than just hype it, because the pushback exists for real reasons.

Critics argue loop engineering can produce "AI slop" — agents running continuously, generating output, consuming tokens, without a human closely checking whether any of it is actually good. A loop that runs is not automatically a loop that's producing value. It's entirely possible to build a very well-engineered loop that confidently does the wrong thing, repeatedly, for hours.

This is exactly why the loop contract and the checker layers aren't optional extras — they're the actual safety mechanism. A loop without a real convergence criteria and a real verification step isn't autonomous, it's just unsupervised. Those are different things, and the difference matters.

The honest framing: loop engineering is powerful and it's also genuinely early. The World Cup example works because match data and site correctness are relatively easy to check programmatically. Plenty of real-world tasks don't have that property yet, and forcing a loop onto a task without a clean success condition is how you end up burning budget on confidently wrong output.

What This Means For Anton

I haven't fully rebuilt Anton around this yet, but here's the concrete plan, because I think working through it clarifies the idea better than any abstract description.

Right now, Anton is a harness — I trigger it manually with a goal, it plans, executes tasks iteratively, and stops when the task queue is empty. That's a single goal loop, run once, by hand.

The loop engineering version:

Trigger: a cron loop, every night at 2am
State check: read AntonState's task_queue —
             anything queued from earlier that never got picked up?
Decision: queue empty? → log and sleep until tomorrow
          queue non-empty? → run the existing harness loop
Execution: same AntonState struct, same context-per-task pattern
           from the harness post — unchanged
Verification: same as before — compiler + test suite, deterministic
Human checkpoint: PRs get opened, not merged.
                   That's the one place I stay in the loop, deliberately.

The harness code barely changes. What changes is that I stop being the trigger. Anton decides, on its own schedule, whether there's work worth doing — and only interrupts me at the one point that actually matters: before anything ships.

That's loop engineering, concretely, on top of everything I already built.

The One Thing To Remember

If prompt engineering is what you say, and context engineering is what the model can see, and harness engineering is how each individual call stays clean — then loop engineering is who decides to make the call in the first place.

The shift isn't really about capability. Frontier models were already good enough for a lot of this months ago. The shift is architectural: you stop being the trigger, and start being the designer of the system that triggers itself.

That's a genuinely different skill than writing a good prompt. And based on how fast this term spread through the community in June — 6.5 million views on the post that started it — a lot of people are realizing that at the same time.

I'm Niranjan — Full Stack & Web3 Developer at Alkimi Exchange, M.Sc. student in Data Science & Generative AI. I write about what I'm actually building, not what sounds impressive.

This post follows Harness Engineering: Why Your AI Agent Needs an Outer Shell, Not Just a Better Prompt — read that first if loop contracts and state layers feel unfamiliar.

Follow me on X / Twitter | More at The Agentic World

One GitHub gist. 16 million views. Then Google turned it into an open standard. Here's what's actually happening to AI memory.

Two months ago, Andrej Karpathy — co-founder of OpenAI, former Director of AI at Tesla — published a GitHub gist.

Not a paper. Not a product launch. Not even a repository with installable code.

A gist. A text file describing a folder structure.

It got 16 million views.

That number deserves a pause. Not because Karpathy is famous (though he is). But because 16 million developers looked at a description of a folder and collectively thought: yes, this is the thing I've been doing wrong.

Then, two months later, Google Cloud turned that folder into an official open standard.

This post is the full story — what RAG actually is, why the folder idea is so powerful, how Google formalized it, and what it means for anyone building AI agents right now.

First, What RAG Actually Does (And Where It Quietly Falls Apart)

RAG — Retrieval Augmented Generation — has been the default approach to AI memory for two years. The pattern is everywhere. Every AI chat tool, every document search product, every "ask questions about your PDFs" demo runs some version of it.

Here's the full pipeline:

Your documents
      ↓
Chunking — split into ~500 token pieces
      ↓
Embedding — convert each chunk into a high-dimensional vector
      ↓
Vector database — store all vectors (Pinecone, Weaviate, Chroma, etc.)
      ↓
Query time:
  User asks a question
      ↓
  Question converted to vector
      ↓
  Similarity search — find top-k most similar chunks
      ↓
  Retrieved chunks injected into context
      ↓
  LLM generates answer from those chunks

This works. It genuinely works. For large-scale document search across thousands of files, it's still the right architecture.

But it has a problem that nobody talked about loudly enough:

Every query starts from zero. Nothing accumulates.

You ask about your quarterly report. RAG finds the relevant chunks, synthesizes an answer. You close the chat. Tomorrow you ask a followup question. RAG finds chunks again, re-synthesizes, re-derives all the same relationships.

The LLM is like a researcher who reads every relevant source fresh for each question — never taking notes, never building on previous work, never compiling anything. All the synthesis work happens at query time, every single time, for every single user.

Ask a question that requires synthesizing five documents and understanding how they relate to each other? RAG has to piece that together from fragments every time. The cross-references, the contradictions, the synthesis — re-derived from scratch, again and again.

There's no accumulation. Nothing compounds.

The Gist That Got 16 Million Views

On April 3, 2026, Karpathy published his answer to this problem. And his answer was almost offensively simple.

Instead of vector databases and embeddings and similarity search — a folder of linked markdown files that an AI agent maintains itself.

The structure:

/wiki
  index.md              ← table of contents, agent reads this first
  /concepts
    transformer.md      ← concept page, linked to related concepts
    attention.md
    rag-vs-wiki.md
  /people
    andrej-karpathy.md
  /projects
    project-alpha.md

Each file is one concept. Files link to each other with standard markdown links, forming a knowledge graph. When you add a new source document, you don't embed it — you give it to the agent, and the agent reads it, extracts what's important, and updates the wiki. It rewrites existing pages. Adds new ones. Fixes cross-references. Notes where the new information contradicts something that was already there.

The knowledge gets compiled once. Then it stays compiled.

The insight Karpathy named precisely — and that resonated with 16 million people:

RAG retrieves and forgets. A wiki accumulates and compounds.

The analogy that made this click for me: think of RAG like an interpreter and the wiki like a compiler.

RAG (interpreter):
  Every query → re-parse source documents → re-derive relationships → answer
  Same work, every time, from scratch

Wiki (compiler):
  Ingest source → agent compiles knowledge once → updates wiki
  Every query → read the pre-compiled wiki → answer
  All the synthesis work is already done

The compilation happens once. The queries are cheap. The knowledge grows over time instead of being re-derived forever.

And the reason Karpathy chose to publish a gist instead of a repo? He explained it directly: "In the age of LLM agents, sharing an idea is more valuable than sharing code, because the other person's agent customizes and builds it for your specific needs."

Why It Actually Works — The Technical Picture

The honest answer to "why does a folder beat a vector database for smaller knowledge bases" comes down to three things:

1. Processing happens upfront, not at query time

RAG's expensive work — understanding relationships, synthesizing across documents, resolving contradictions — happens at query time, every query. The wiki's expensive work happens at ingest time, once. After that, retrieval is just reading files.

RAG:
  Ingest: fast (just embed and store chunks)
  Query: expensive (re-synthesize every time)

Wiki:
  Ingest: expensive (agent processes, cross-references, updates)
  Query: fast (read pre-compiled pages)

For knowledge bases where you're querying far more than you're ingesting — which is almost always — the wiki's trade-off is better.

2. The agent reads the index, then drills in

The scaling insight: you don't load the whole wiki into context. The agent reads index.md first — a table of contents with one-line summaries of every page. It identifies which pages are relevant to the current question. Then it reads only those pages.

Query: "How does attention work in transformers?"

Agent reads: index.md
  → Finds: attention.md, transformer.md, positional-encoding.md
  → Reads those three files
  → Answers from synthesized, pre-compiled knowledge

Total context used: ~3 pages
vs.
RAG: retrieves K random chunks from across all documents
  with no guarantee they're the most relevant

For knowledge bases up to a few hundred pages, this selective loading beats probabilistic vector retrieval in both accuracy and speed.

3. It's just files

No running service. No vector database to maintain. No embedding model to call. No API key. No special tooling.

git init
mkdir wiki
touch wiki/index.md

That's your entire infrastructure. The knowledge is version-controlled, diffable, reviewable, shippable as a tarball, hostable in any git repo, readable in any editor. Any LLM that can read text can consume it.

The filesystem is the API.

Google's Response: Turn It Into a Standard

Here's where the story gets interesting.

Two months after Karpathy's gist went viral — on June 12, 2026 — Google Cloud published the Open Knowledge Format (OKF) v0.1.

Formally. With a specification. With reference implementations. With sample bundles.

The announcement was explicit: OKF is a direct formalization of the LLM-wiki pattern.

The format is deliberately minimal. An OKF bundle is a directory of markdown files. Each file represents one concept. Each file has a small YAML frontmatter block:

---
type: Metric                    # The only required field
title: Weekly Active Users
description: Unique users who performed any action in the last 7 days
resource: https://analytics.internal/metrics/wau
tags: [growth, retention]
timestamp: 2026-06-12T10:00:00Z
---

# Weekly Active Users

Computed from the `events` table, counting distinct `user_id`
values where `event_time > NOW() - INTERVAL 7 DAY`.

Related: [Monthly Active Users](../mau.md), [Retention Rate](../retention.md)

That's it. One required field (type). Everything else optional. Standard markdown links create the graph between concepts. Two reserved filenames: index.md for navigation and log.md for change history.

The full v0.1 specification fits on a single page.

Google also shipped reference implementations:

• A BigQuery enrichment agent that walks a dataset and produces OKF concept files for every table and view

• A static HTML visualizer that turns any OKF bundle into an interactive graph view

• Three ready-to-browse sample bundles (GA4 e-commerce, Stack Overflow, Bitcoin public datasets)

The stated goal: end the context assembly problem. Every AI agent builder today solves the same problem from scratch — gathering relevant organizational knowledge before the agent can do its work. OKF standardizes the container so knowledge can be written once and consumed by any agent, any tool, any organization.

RAG vs Wiki vs OKF — When To Use What

This is the most important practical question, and the honest answer is: they're not actually competing.

RAG is the right choice when:
  ✅ Thousands or millions of documents
  ✅ Knowledge base grows continuously at scale
  ✅ You need probabilistic retrieval across a huge corpus
  ✅ Enterprise document search
  ✅ You genuinely can't pre-compile the knowledge

LLM Wiki / OKF is the right choice when:
  ✅ Up to a few hundred pages / concepts
  ✅ Knowledge accumulation matters more than raw retrieval speed
  ✅ Small team or personal knowledge base
  ✅ You want version control and human readability
  ✅ No infrastructure budget or appetite
  ✅ The agent should maintain the knowledge itself over time

Neither is the right choice when:
  ❌ You need real-time data (neither is a live database)
  ❌ Access control is complex (both are just files)

The "RAG is dead" framing that circulated after Karpathy's post is inaccurate. RAG is the right tool for large-scale retrieval. The wiki pattern is the right tool when the knowledge base is small enough to compile and when knowledge accumulation matters.

They're suited to different scales and different problems.

The Real Limitations Nobody Wants To Admit

The wiki pattern is genuinely powerful. It's also genuinely incomplete for some use cases, and anyone building with it should understand where it breaks.

Staleness. The wiki has no built-in mechanism for knowing when pages are out of date. If your source documents change frequently, the compiled wiki can drift from reality. OKF's solution was pragmatic — instruct readers to tolerate errors and broken links. That's damage control, not a fix.

Scale ceiling. The index-then-drill approach works up to a few hundred pages. Beyond that, the index itself gets unwieldy, and the agent starts making worse page selection decisions. At that scale, you need hybrid search — BM25 keyword matching plus vector search — layered on top of the wiki structure. LLM Wiki v2, published by the community within weeks of Karpathy's original, addresses exactly this.

LLM note-taking quality. The wiki is only as good as what the agent writes. Smaller models write inconsistent pages, miss cross-references, and occasionally produce subtly wrong summaries. The schema file (the configuration that tells the agent how to maintain the wiki) is critical — without strict schema instructions, you get an inconsistent mess. With a good schema, you get structured, reliable pages.

No shared semantics. OKF standardizes the container — the folder structure, the YAML fields, the file format. It explicitly does not standardize the vocabulary inside files. Two teams can both produce valid OKF bundles where "type: Metric" means completely different things. True interoperability between organizations requires agreement on semantics beyond the format itself.

Team maintenance. For a solo developer with discipline, the wiki compounds beautifully. For a team of ten, without a clear process for who reviews agent-generated updates, the wiki slowly drifts and rots. The format solves the technical problem. The workflow problem remains human.

What This Means For Your Agent Right Now

If you're building agents, here's the practical takeaway:

The Memory OS layer we covered in the previous post already implements a version of this pattern — the LLM Wiki layer (Layer 6) is literally a self-curating knowledge base where Vault Curator v3 automatically organizes what the agent has learned after each session. The architecture Karpathy described in April, formalized by Google in June, is already running inside the most advanced open-source agent stacks.

For your own projects, the entry point is simple:

Step 1: Create a wiki folder
Step 2: Write a schema file (AGENTS.md or CLAUDE.md)
  — How pages should be structured
  — Naming conventions
  — How to handle contradictions
  — When to create new pages vs update existing ones
Step 3: Give your agent a source document and tell it to ingest
Step 4: Ask questions against the wiki

That's it.

The schema file is the critical piece most people skip. Without it, the agent produces inconsistent output. With a good schema, the wiki becomes a disciplined, structured knowledge base that actually compounds over time.

The Shift That's Actually Happening

Zoom out from the technical details and here's what's actually going on:

For two years, the AI industry invested heavily in retrieval infrastructure. Vector databases. Embedding pipelines. Similarity search algorithms. The assumption was that better retrieval was the path to better AI memory.

Karpathy's gist — and Google's subsequent formalization — suggests a different frame:

The bottleneck isn't retrieval. It's that we never bothered to compile the knowledge in the first place.

RAG is a sophisticated search algorithm applied to a pile of raw documents. The wiki pattern says: stop throwing queries at raw documents. Have an agent do the synthesis work once, maintain it over time, and make it available as a compiled artifact that any query can use directly.

The next generation of AI knowledge infrastructure won't be built on better embeddings or faster vector search. It'll be built on better knowledge compilation — agents that maintain living knowledge bases that get smarter every time new information arrives.

A folder of markdown files. That's the whole idea.

And apparently, 16 million people needed to hear someone say it out loud.

I'm Niranjan — Full Stack & Web3 Developer at Alkimi Exchange, M.Sc. student in Data Science & Generative AI. Writing about what I'm actually learning, not what sounds impressive.

Follow me on X / Twitter | More at The Agentic World

My local Rust agent kept crashing after 20 iterations. The fix taught me the most important architectural lesson in agentic AI.

A few weeks ago, Anton — my local Rust-based coding agent running on Gemma 4 via Ollama — did something embarrassing.

I gave it a multi-step task. Build a feature, write tests, fix what breaks, document it. Simple enough on paper.

Iteration 1: clean response, 2,000 tokens, fast. Iteration 10: getting sluggish, 18,000 tokens, some weird hallucinated context. Iteration 20: Ollama choked. Out of memory. The whole thing collapsed under its own conversation history.

I'd been appending every message to a Vec<Message> and shipping the entire growing history into every single model call. It felt natural. It's how every basic agent tutorial does it.

It's also completely wrong for anything beyond a toy demo.

What I learned fixing this turned out to be a real discipline with a name — harness engineering — and understanding it changed how I think about every agent I build from now on. This post is everything I learned, with Anton as the running example throughout.

Three Eras, Three Bottlenecks

To understand why harness engineering exists, you need to see what came before it — and exactly where each previous approach broke down.

Era 1: Prompt Engineering (2020–2022)

In the beginning, the entire "intelligence" of working with an LLM lived in the prompt string itself. Few-shot examples. "Let's think step by step." Role priming — "You are an expert Python developer."

This was the era of GPT-3 with a 4,000-token context window. Everything — instructions, examples, conversation history, expected output format — had to fit inside that tiny budget.

The model was stateless by design. Every API call was independent. And critically: the model could describe an action ("you should run npm install") but it couldn't take the action itself. No tool use. No execution. Just text in, text out.

The breaking point came when tasks got complex enough that the actual bottleneck stopped being "how do I phrase this instruction better" and became "how do I even give the model enough information to work with."

Era 2: Context Engineering (2022–2024)

The realization that broke this era open: output quality is a function of context quality, not prompt quality. You could have the most beautifully crafted prompt in the world — if the model didn't have the right information in front of it, the output would still be wrong.

Three mechanisms emerged to solve this:

Tool calling — the model produces a structured function call, your runtime executes it, the result gets injected back into the context. This grounds the model in real, current world-state without you having to pre-load everything it might possibly need.

RAG (Retrieval Augmented Generation) — at inference time, retrieve the top-k semantically relevant chunks from a vector database and inject just those. The model sees only what's relevant, not your entire knowledge corpus.

MCP (Model Context Protocol) — Anthropic's standardized JSON-RPC protocol. Servers expose resources (readable context) and tools (callable functions). A model can list resources, read them, and call tools — all over one standard connection. The advantage over raw tool calling is discoverability: any compliant client can discover what a server offers without custom integration code.

These three mechanisms were genuinely powerful. But they all shared the same hidden ceiling.

There's no iteration primitive. Context engineering is still fundamentally a single-call paradigm. The moment your task requires more than one model call — and any real agentic task does — you're left manually managing state across calls with no architectural support.

This shows up as three concrete failures:

Context accumulation rot:
  By step 20 of a naive loop, the context window is full of noise —
  old tool outputs, superseded decisions, dead-end attempts.
  The signal-to-noise ratio collapses.

No persistent state primitive:
  When the context window resets or gets truncated,
  everything is just gone. There's no durable record.

Single-call thinking applied to multi-call problems:
  RAG and tool calling were designed to make ONE call smarter.
  They don't tell you how to architect TWENTY calls together.

This is exactly the wall Anton hit. I had tool calling. I had reasonably good prompts. None of it mattered because the loop itself was badly designed.

Era 3: Harness Engineering (2024–present)

Here's the insight that actually broke the ceiling, and it's worth sitting with because it's not intuitive at first:

Instead of managing context across a long loop, architect the loop itself.

The harness is the outer shell. It's the thing that controls iteration, controls state, and decides exactly what each individual model call gets to see. Critically — each model call gets a fresh, purpose-built context. Not accumulated history. Not the entire conversation so far. Just exactly what's needed for this one step.

The single sentence that reframes everything:

The context window is a viewport into durable state — not a ledger of everything that happened.

Read that again. It's the entire idea in one line.

The Code That Makes This Click

Let me show you the difference directly, because seeing the naive version next to the harness version is what made this finally click for me.

The naive pattern — what almost every basic agent tutorial teaches you:

# Naive — what most people do, including me with early Anton
messages = [system_prompt]

while not done:
    response = llm(messages)
    messages.append(response)        # grows forever
    tool_result = execute(response)
    messages.append(tool_result)     # grows more
    # by step 20: 40K tokens, quality garbage, cost explodes

This works fine for 3 or 4 steps. It actively falls apart after that. The context window becomes an ever-growing ledger of everything that's ever happened in the session — including mistakes, dead ends, and superseded decisions that are now actively confusing the model.

The harness pattern — what actually scales:

state = HarnessState()  # lives on disk, external to any context window

while not state.is_complete():
    task = state.next_task()
    context = build_context(task, state)   # fresh, purpose-built, bounded
    response = llm(context)                 # clean call
    state.apply(response)                   # update durable state
    # context is discarded. state persists.

The difference isn't subtle. The context window stays roughly 2,000–3,000 tokens at iteration 1, iteration 20, and iteration 100. Quality stays constant because the model is never drowning in irrelevant history.

There's also a real technical reason this matters beyond just "less noise." Attention computation scales quadratically with context length — O(n²). A fresh 2K-token context has dramatically better attention density than step 20 of an accumulated 40K-token conversation, where the model's attention is being diluted across a huge amount of mostly-irrelevant text.

The Analogy That Actually Made This Stick For Me

A human developer doesn't wake up and remember every single keystroke they typed yesterday. They don't replay their entire week in their head before starting work today.

Instead: they open the codebase. They check their task list. They do one focused thing. They commit it. They move to the next thing.

The codebase + the task list  = state (durable, external, persistent)
Their working memory in the moment = context window (fresh, bounded)

A harness is exactly that separation, formalized and applied to an LLM. The harness engineers the boundary between what persists and what's disposable.

Fixing Anton — A Real Walkthrough

Here's what Anton actually looked like before, and exactly how I rebuilt it.

Before — the problem in Rust:

struct Anton {
    client: OllamaClient,
    messages: Vec<Message>,  // grows without bound — this is the entire problem
}

Every iteration appended both the model's response and the tool execution result to this vector. Gemma 4 running locally via Ollama has a tight context budget and is a meaningfully smaller model than something like GPT-4 — it degrades fast under noisy, bloated context. Step 1 was a clean 2K tokens. Step 20 was 40K+ tokens and an Ollama crash.

After — separating state from context:

The first thing I had to do was define what actually needed to persist, independent of any single model call:

struct AntonState {
    task_queue: VecDeque<Task>,             // tasks waiting to run
    completed: Vec<CompletedTask>,          // append-only log
    failures: Vec<Failure>,                 // retry context
    file_index: HashMap<String, FileEntry>, // current file contents
    iteration: usize,
    max_iterations: usize,
}

This lives on disk. It survives crashes. It's the source of truth — never the message history.

Each unit of work became its own scoped struct:

struct Task {
    id: String,
    description: String,
    relevant_files: Vec<String>,   // harness injects ONLY these files
    dependencies: Vec<String>,     // must complete first
    expected_outputs: Vec<String>,
    retry_count: usize,
}

The critical piece — the part that actually does the work of being a harness — is the context builder:

fn build_context(task: &Task, state: &AntonState) -> Vec<OllamaMessage> {
    // 1. System prompt scoped to THIS specific task, not generic
    // 2. Only the files this task actually needs — never the whole codebase
    // 3. Failure context if this is a retry — the SPECIFIC error, not "try again"
    // 4. Final clear instruction
    // Returns a fresh Vec — used exactly once, then thrown away
}

This function is called fresh, every single iteration. It never sees what happened 15 steps ago unless that information was explicitly written into durable state and is relevant to the current task.

The full loop, end to end:

EACH ITERATION:
1. Select next task (check dependencies are satisfied)
2. Build a fresh context from current state
3. Call Gemma 4 via Ollama
4. Parse the JSON output (structured, not free-form text)
5. Write resulting files to disk
6. Update AntonState — file_index, completed tasks, etc.
7. Persist state to disk (this is what gives you crash recovery)
8. Check the termination condition

I also split Anton into two distinct phases, which turned out to matter a lot:

Phase 1 — Planner. One single model call. Takes a high-level goal, returns a structured task list with explicit dependencies between tasks.

Phase 2 — Harness. Executes that task list iteratively, one fresh context per task, exactly as described above.

One advantage specific to running locally that's worth calling out: Anton has zero marginal cost per call and no rate limits. That means I can afford genuinely aggressive retry behavior and iteration counts that would get expensive fast on a cloud-hosted agent calling a paid API. Local-first agents can afford to fail more often, because failing is free.

Three Architecture Patterns — And When Each One Breaks

Harness engineering isn't one single pattern. There are three common shapes, and picking the wrong one for your task is a real failure mode.

Single agent loop — one model, one task queue, strictly sequential. This is the simplest to reason about and debug. Use it for well-defined sequential work: spec → implement → test → fix → document. It falls apart the moment you have genuinely parallel, independent subtasks — everything still runs one at a time even when it doesn't need to.

Hierarchical agents — an orchestrator (itself an LLM call) dispatches scoped tasks to subagents. Subagents must return structured JSON output, never free text, so the orchestrator can reliably parse and act on results. Good for complex projects with real parallel structure. The real downside: the orchestrator becomes a complexity attractor. All the hard bugs end up living there, and it's genuinely difficult to debug a system where one LLM is managing the outputs of several other LLMs.

Agent swarms — no central coordinator at all. Agents share a blackboard — a shared state store — claim available tasks, publish results, and react to what other agents have published. This suits exploratory tasks where you don't know the structure in advance. The cost: emergent behavior is hard to predict, convergence isn't guaranteed, and this pattern is by far the hardest to debug when something goes wrong, because there's no single place to look.

For Anton, a single agent loop with a planner phase in front of it was the right call. The tasks are sequential by nature — you generally need to implement before you can test, and test before you can document.

This Isn't Theoretical — Real Tools Already Do This

Once I understood the pattern, I started recognizing it everywhere in tools I already use.

Cursor maintains a file index — tree-sitter ASTs, symbol graphs — that lives entirely outside the context window. It uses semantic search to pick relevant files for each individual iteration. It does not dump your whole codebase into context and hope for the best.

Kiro (AWS) takes this even further by introducing specs as formal state artifacts. Before any code gets written: produce a requirements.md, then a design.md, then a task list — and only then implement. Each phase produces a durable document that becomes the context for the next phase. The documents are the state. The model calls are disposable.

Claude Code uses TodoWrite and TodoRead tools specifically to maintain a task list as durable state, separate from the conversation. It also applies a "compact" operation once context grows too large — summarizing the history and replacing it with the summary rather than letting it grow forever.

Kilo Code (open source) exposes this logic directly and transparently. It uses a sliding window — recentHistoryContext(n=5) — instead of full history, and tracks state explicitly in an AgentState object rather than burying it inside the message array.

Different implementations. Same underlying architectural insight every time: separate what persists from what's disposable.

Where Harnesses Actually Break

I hit most of these myself building Anton. Worth knowing them before you hit them too.

Infinite loops. Your termination condition depends on a test passing, but the model keeps generating subtly incorrect code that never quite satisfies it. The fix is blunt but necessary: hard iteration caps, and skip a task after N retries rather than re-queuing it forever.

Task decomposition failures. Tasks that are too granular create overhead. Tasks that are too coarse don't give the harness enough structure to work with. Worst case: circular dependencies, where task A depends on task B and task B depends on task A. The fix is to validate your task graph with a topological sort before execution starts, not after something deadlocks.

Context bleed. If your durable state stores raw model outputs with implicit assumptions baked into them, every future context you build from that state inherits those assumptions silently. The fix is to track intent — what should exist — separately from artifact — what was actually produced. Don't conflate the two in your state.

Scope creep. The model adds a feature you didn't ask for, or changes an API signature that wasn't part of the task. The fix: require structured output that specifies exactly what changed, and validate it against an expected schema before accepting it into state.

The verification oracle problem. This is the hardest one and it's genuinely unsolved in general. How does the harness actually know a task succeeded? For code, you have real oracles — run the compiler, run the test suite, get a definitive pass/fail. For open-ended reasoning tasks, there may be no reliable oracle at all. This is still an open research problem, not something you can architect your way fully out of.

Gemma-specific: malformed JSON. Smaller local models occasionally wrap valid JSON in markdown code fences, or use slightly wrong field names. The practical fix: strip ``` fences before parsing, use strict deserialization (deny_unknown_fields if you're in Rust with serde), and retry with the actual parse error included in the next context — not just "try again."

Ollama OOM on retry. A large context crashes Ollama. The retry logic sends the same oversized context. It crashes again, identically. The fix: pre-check an estimated token count before sending, and truncate file content if you're over budget — don't just blindly retry the exact thing that just failed.

The Vocabulary Worth Knowing

A few terms that are worth having precisely defined, because they get used loosely:

Harness — the orchestration layer that runs the loop and controls exactly what each individual model call sees.

State — durable, external data: tasks, files, failure records. Specifically not the message history.

Context window — what the model sees for one single call. A viewport, not a ledger.

Context rot — the quality degradation that happens as history accumulates in a naive, unbounded loop.

Task decomposition — breaking a goal down into small, scoped units that each fit cleanly into a single model call.

Verification oracle — something external — a compiler, a test suite — that can actually confirm whether a task succeeded.

Planner phase — one model call upfront that generates the full task list before any execution begins.

Fresh context — a new context built from current state at the start of every single iteration, and discarded immediately after use.

The One-Line Summary

If you remember nothing else from this post, remember this:

A harness turns an AI assistant into an AI engineer — it plans, loops, checks its work, and persists until the job is genuinely done.

An assistant responds to what you say. An engineer maintains a plan, works through it systematically, verifies its own output, and keeps going without you babysitting every step. The difference between those two things isn't a better prompt. It's an architecture.

Anton runs without crashing now. Not because Gemma 4 got smarter, and not because I wrote a cleverer prompt. Because I stopped asking the model to remember everything, and started asking it to look at exactly what it needed for the task in front of it — nothing more.

That's the whole discipline.

I'm Niranjan — Full Stack & Web3 Developer at Alkimi Exchange, M.Sc. student in Data Science & Generative AI. I write about what I'm actually building, not what sounds impressive.

Follow me on X / Twitter | More at The Agentic World

No subscriptions. No browser tabs. No starting from zero every session. Just an AI that runs on your machine, remembers everything, and actually does things while you sleep.

Let me tell you what broke my brain this week.

I've been building with AI long enough to know the pattern. You open a tab. You type. You get an answer. You copy it somewhere. You close the tab. Tomorrow you open a new tab and the AI has no idea who you are, what you're building, or what you talked about yesterday.

Every session. Starting from zero. Forever.

That's not an agent. That's a very smart search engine with a chat interface.

What I found this week is something fundamentally different. Four open-source repos that together form a complete stack — a persistent, self-improving AI agent that lives on your own hardware, connects to the messaging apps you already use, remembers everything across sessions, and can actually do things autonomously while you're not watching.

I'm going to break down all four. By the end of this post, you'll understand why this architecture matters — and why it's the direction serious agentic AI is heading.

The Problem With Every AI Tool You're Using Right Now

Before the repos, let's name the actual problem.

Current AI tools are stateless. Every conversation is an island. The model doesn't know your name, your stack, your preferences, your ongoing projects, or anything about the context of your work unless you paste it in manually every single time.

This creates a hidden tax on every developer using AI today:

Session 1: Explain your project, your stack, your constraints
Session 2: Explain everything again
Session 3: Explain everything again
Session N: Still explaining everything

You're not just using AI. You're babysitting it. Re-onboarding it. Every. Single. Day.

The solution isn't a better prompt. It's a different architecture entirely.

An agent that:

• Runs continuously in the background — not waiting for you to open a tab

• Connects to where you already are — Telegram, Slack, WhatsApp, Discord

• Remembers everything — facts, preferences, past sessions, your codebase

• Gets smarter over time — learns from experience, creates its own skills

• Actually does things — runs code, manages files, opens PRs, browses the web

That's what this stack builds. And the entire thing is open source, runs locally, and costs you nothing except compute.

Let's go through each piece.

Piece 1: OpenClaw — The Pioneer That Started It All

OpenClaw has one of the wildest origin stories in open source.

It was released on November 24, 2025 as "Warelay." Renamed to Clawdbot on January 2, 2026. Renamed again to Moltbot on January 27, 2026 after a trademark complaint. Then the community voted on a new name — and landed on OpenClaw on January 30, 2026.

241,000 GitHub stars. In record time.

Something about this project clearly hit a nerve.

What OpenClaw Actually Is

Most AI tools are reactive — you go to them. OpenClaw flips this. It runs as a continuous background daemon on your hardware. You don't open a browser tab. You message it on Telegram. Or WhatsApp. Or Slack. Or Discord. It's always there, always running, always ready.

The architecture has one central concept: the Gateway.

You (Telegram / WhatsApp / Discord / Slack)
              ↓
         The Gateway          ← central control plane
         ├── Message routing
         ├── Session management
         ├── Plugin execution
         └── Tool policy
              ↓
         Agent Runtime        ← processes context, calls LLM, streams responses
              ↓
         Tool Execution       ← shell commands, browser, calendar, email

The Gateway normalizes every messaging platform into a standard message shape. Telegram messages and Discord messages look identical to the agent runtime. One agent, every channel.

The Four Files That Define Everything

This is the part that makes OpenClaw genuinely different to build with. You define your agent by writing four files:

SOUL.md — Who the agent is. Its personality, identity, rules of engagement. This gets injected as the system prompt before every single LLM call. Write this well and you have a consistent agent that behaves predictably.

SKILL.md — What the agent can do. Step-by-step capability cards written in Markdown. No code required. You write a skill card that says "when asked to create a PR, do these steps" and the agent reads it and executes it. Skills are composable — one skill can call another.

HEARTBEAT.md — The scope limiter. Budget caps, access boundaries, what the agent is and isn't allowed to do autonomously. This is your safety layer for production deployments.

openclaw.json — The master config. Which channels, which agents, which skills, which model providers.

Your Agent Definition:
  SOUL.md      → identity and behavior
  SKILL.md     → capabilities and procedures
  HEARTBEAT.md → autonomy limits
  openclaw.json → runtime configuration

The latest release (2026.6.2-beta.1) added native ClawHub skill installations — you can now install community-built skill packs with a single command. Think of it like npm for agent capabilities.

OpenClaw established the patterns. But there were limits. The TypeScript runtime, the manual skill creation, the session-based memory. A team took those patterns and rebuilt everything from scratch.

Piece 2: Hermes Agent — The Evolution

Hermes Agent is built by Nous Research. Same DNA as OpenClaw, upgraded everything that mattered.

TypeScript → Python. Manual skills → self-creating skills. Session memory → persistent memory with learning loops.

But the most important architectural upgrade is something called lifecycle hooks.

The Hook System — The Most Important Concept in This Post

Every message passing through Hermes touches three moments where plugins can intercept and act:

User message arrives
       ↓
  pre_llm_call    ← fires BEFORE the LLM sees your message
       ↓            Memory plugins inject relevant context here
  LLM processes
       ↓
  post_llm_call   ← fires AFTER the LLM responds
       ↓            Facts and decisions are captured here
  Response sent
       ↓
  on_session_end  ← fires when conversation ends
                    Long-term consolidation happens here

This hook system is what makes the entire ecosystem modular. Memory OS — which we'll get to — plugs directly into these hooks without touching Hermes's core code. Any plugin can hook into any of these three moments. The agent becomes a platform, not a monolith.

The Self-Improving Loop

Here's what makes Hermes genuinely different from every other agent framework:

The agent creates its own skills.

When Hermes completes a complex task — 5+ tool calls, or a task where it had to recover from errors — it doesn't just finish and forget. It saves the successful approach as a skill. A Markdown card describing the workflow, stored in its skill library, available for next time.

Over time, Hermes builds up a personal library of skills derived from its own experience with your specific problems. It doesn't just get faster — it gets better at your particular tasks.

Complex task completed successfully
              ↓
Hermes creates skill card:
  "How to refactor auth modules in this codebase"
  "How to debug this team's CI pipeline"
  "How to structure PRs for this project"
              ↓
Next similar task:
  Skill card injected into context
  Agent already knows the workflow

Model Freedom

One more thing worth noting: Hermes doesn't lock you in. Switch models with hermes model — no code changes, no migration, no lock-in. Nous Portal, OpenRouter (200+ models), OpenAI, NVIDIA NIM, your own endpoint. Works with all of them.

The v0.15.0 "Velocity Release" was a serious engineering overhaul — the core agent conversation loop went from 16,083 lines to 3,821 lines (-76%). 213 community contributors. The Kanban system grew into a full multi-agent platform with orchestrator auto-decomposition, swarm topology, and per-task model overrides.

OpenClaw gave Hermes its architecture. Hermes gave the agent its engine and learning loop. But neither of them solved the deepest problem: memory.

Piece 3: Memory OS — The 7-Layer Brain

This is the piece that made everything click for me.

Hermes's built-in memory searches past conversations by keyword. That's useful. But it doesn't understand facts. It doesn't understand trust. It doesn't understand meaning. If you told it your preferred database was PostgreSQL three months ago in different words, it won't find that when it needs it.

Memory OS is a complete hierarchical memory architecture. Seven layers. Fully local. No cloud subscription required.

Here's how to think about it — from fastest/shallowest to slowest/deepest:

Layer 1: Workspace files
         Flat markdown files. Immediately visible.
         Like sticky notes on your desk.

Layer 2: FTS5 session search
         Full-text keyword search across all past sessions.
         Ctrl+F over your entire conversation history.

Layer 3: Trust-scored facts
         Structured facts extracted from conversations.
         "User prefers TypeScript" → confidence: 0.87
         Trust goes UP when you confirm, DOWN when you correct.
         Low-trust facts filtered out before injection.

Layer 4: Icarus fabric
         An associative knowledge web.
         "CI/CD" links to "GitHub Actions" links to "your staging setup."
         Not just storage — connected thinking.

Layer 5: Qdrant vectors
         Semantic search via local Qdrant database.
         Finds memories by MEANING, not just keywords.
         "deployment issue" also finds "production server crashed Tuesday"
         Zero shared words. Same semantic cluster.

Layer 6: LLM wiki
         A self-curating knowledge base.
         After sessions, Vault Curator v3 automatically organizes
         everything the agent learned into structured wiki pages.
         Nobody tells it to. It just does it.

Layer 7: Ground Truth hierarchy
         The official record. Explicitly confirmed facts.
         The final authority when layers contradict each other.

The Two Searches That Work Together

The layered architecture uses two fundamentally different search methods running simultaneously:

FTS5 (keyword matching):

• Fast and reliable

• Exact word matching

• Fails if you forget the exact phrasing you used

Qdrant (semantic matching):

• Slower to build

• Finds conceptually related memories across completely different words

• "production broke" finds "server crashed last Tuesday" even with zero shared vocabulary

Memory OS runs both simultaneously with BM25 hybrid scoring, then deduplicates. You get the speed of keyword search and the intelligence of semantic search at the same time.

The Retrieval Flow

You send a message
       ↓
pre_llm_call fires:
  Qdrant search     → semantic memories
  FTS5 search       → keyword memories
  Facts DB query    → trust-scored facts
  Icarus fabric     → associated concepts
  All firing simultaneously, deduplicated, injected silently
       ↓
LLM sees your message + all relevant memory
The agent "remembers" you without you saying a word
       ↓
post_llm_call fires:
  New facts extracted and scored
  Trust scores updated
       ↓
on_session_end fires:
  Vault Curator v3 runs
  Wiki pages updated
  New Qdrant embeddings created
  Session indexed in FTS5

Every conversation makes the agent smarter. Every correction updates trust scores. Every session updates the wiki. The memory isn't static — it's a living, self-organizing system.

Piece 4: OpenCode — The Specialist You Call In

The first three pieces are your personal AI infrastructure. OpenCode is different. It's not a general assistant — it's a specialist.

Built by Anomaly (thdxr). Latest version v1.15.13. You launch it inside a repo when you need serious coding done. It goes deep, finishes, and you're done.

Two Modes — Always Start With Plan

Tab to switch modes:

PLAN mode (read-only):
  Maps the codebase
  Understands architecture
  Proposes approach
  Zero side effects
  → Always start here on unfamiliar codebases

BUILD mode (full access):
  Runs shell commands
  Reads and writes files
  Browses the web
  Creates PRs
  → Only switch here after reviewing the plan

This two-mode architecture is genuinely thoughtful. Most coding agents just do things. OpenCode forces a planning phase that catches architectural mistakes before they happen.

Three Internal Agents

build    → main execution agent, full tool access
plan     → analysis-only agent, observational
@general → subagent for complex multi-step research
           build and plan delegate to it internally

The @general subagent is what handles situations like "understand how this entire authentication system works before touching anything." It does the research, builds the context, and hands it back to the build agent.

One critical warning: OpenCode has no security sandbox. The permission system is UX-only — not enforced at the OS level. For any real codebase: run inside Docker, always start in plan mode, never expose its port to the internet. This isn't optional advice. It's survival advice.

How All Four Work Together

Individually, each repo solves one piece of the puzzle. Together, they form a complete stack.

You (Telegram / Slack / WhatsApp)
              ↓
    Hermes Gateway
    always running, routes all channels
              ↓
    Hermes Agent
    Python runtime, any LLM, self-improving skills
              ↓
    Memory OS (via lifecycle hooks)
    ├── Qdrant          semantic search
    ├── FTS5            keyword search
    ├── Facts DB        trust-scored structured facts
    ├── Icarus fabric   associative knowledge web
    └── LLM Wiki        self-curating long-term knowledge
              ↓
    Skills (SKILL.md)
    the glue connecting everything
              ↓
    OpenCode
    specialist coding execution

Let me make this concrete with a real scenario.

You message Hermes on Telegram at 11pm: "Refactor the auth module and open a PR."

Here's what happens without you doing anything else:

1. Gateway receives the message on Telegram
   Routes it to the agent runtime

2. Memory OS pre_llm_call fires
   Injects: your repo structure, coding preferences,
   PR conventions, past decisions about auth module
   — all from memory, silently

3. Hermes recognizes a complex coding task
   Loads the opencode-delegate SKILL.md

4. Skill launches OpenCode in PLAN mode
   Hermes reviews the proposed plan
   Approves → switches to BUILD mode

5. OpenCode refactors the auth module
   Runs the test suite
   Opens the PR with your standard template

6. Result sent back through Gateway → your Telegram
   "PR #247 opened. 3 files changed, all tests passing."

7. Memory OS post_llm_call captures new facts
   on_session_end updates the wiki

You wake up. PR is waiting for review.
You never left Telegram.

That's the agentic loop working as designed. Not you going to the AI. The AI doing the work and reporting back.

Why This Architecture Matters

I've been thinking about this for a few days and here's the frame that keeps coming back to me:

We're at the end of the chatbot era.

The browser tab, the blank context window, the re-explaining everything every session — that's not a feature of AI, it's a limitation of the first generation of AI products. It was never the right model for knowledge work.

The right model is what this stack demonstrates: a persistent agent that lives in your environment, learns from your work, connects to your tools, and acts autonomously on your behalf.

OpenClaw established the architecture. Hermes upgraded the engine. Memory OS gave it a real brain. OpenCode gave it specialist hands.

None of this is science fiction. All of it is running right now on consumer hardware. All of it is open source.

The question isn't whether this is the future of AI tooling for developers. It clearly is.

The question is how long it takes the mainstream to catch up to what's already been built.

I'm Niranjan — Full Stack & Web3 Developer at Alkimi Exchange, M.Sc. student in Data Science & Generative AI. I write about what I'm actually learning, not what sounds impressive.

Follow me on X / Twitter | More at The Agentic World