Avi Chawla (@_avichawla)

OpenClaw vs. Hermes vs. Grok @bot, clearly explained: All three let you set up an agent with a specific job, and it keeps its files and logins between sessions instead of starting fresh. OpenClaw and Hermes are self-hosted, so the machine can be a laptop, a VPS, or a container that someone already pays for and can log into. Grok Bot runs on a machine SpaceXAI provisions and operates. It gives one computer per account rather than one per agent. Every Bot on that account reads the same files and carries the same browser logins, so handing work between two Bots does not require a re-login or file transfer. Hermes and OpenClaw isolate agents instead, and their memory sits in plain files anyone can open and edit. Hermes goes furthest since the agent writes its own skills and a background curator deletes the ones nobody uses. Grok Bot has the lowest-friction path to a new skill in my opinion. You can record up to ten minutes of one pass through a workflow, and it can then turn that into a reusable set of instructions and store it as a skill. Moving on, OpenClaw and Hermes run on any model provider. Grok Bot runs on Grok. I prepared the graphic below that has the full breakdown, from hosting and memory through to what each of them costs to run. And if you want to dive deeper, I covered Grok Bot in full in a masterclass, including the shared computer, memory, skills, routines, and the macOS setup. Read it below.

Stanford researchers did it again. They just built the agent-native version of Git. When an agent works on a longer task, the run builds up a lot of state. This includes files edited/created, a dev server, a database, installed packages, KV cache, etc. Say the agent is at step 10 and makes a mistake, maybe it misreads a traceback and rewrites a file that was actually fine. The tests start failing, and the run goes off track, although everything through step eight was correct. By default, the agent just tries to fix it, which creates more edits and tool calls. This burns more tokens and grows the context. The other options are a person stepping in to redirect it or restarting the whole run from step one. That's wasteful, because it pays for every model/tool call again and re-prefills the context. Moreover, since an agent's run is non-deterministic, it doesn't reproduce the same early steps anyway. The reason it's hard to just jump back exactly to a previous correct step and resume from there is that the trajectory is only a message log. It records what the agent said and which tools it called, but not the live state underneath. That state includes things like memory, open file handles, child processes, installed packages, /tmp, and KV cache. None of that is in the log. Git can version the files, but it doesn't snapshot the running process or the KV cache. Checking out step eight moves the files back, but the process is still sitting in step-ten memory with a cold cache. Shepherd is a runtime layer by Stanford that records the run as a trace of typed events rather than a flat log. Each agent-environment interaction becomes a commit, similar to Git, but it tracks the live run. Its commit includes the agent process and the filesystem together, copy-on-write, so a branch carries the actual state and not just the files. Going back to a previous step is then a single call that forks from that commit and continues from the exact state. The copy-on-write fork is roughly five times faster than docker commit, and because the prompt prefix through step eight is unchanged, the KV cache is reused over 95% on replay, so early steps aren't reprocessed again. Once the run can be forked, a meta-agent can sit on top and operate it. It watches the trace and reverts as soon as it looks wrong, before the bad write is committed. In practice, it's just Python calling fork, replay, and revert on the trace, rather than a separate control plane wired into the harness. Not everything is reversible though. Files and sandbox changes undo themselves, but a database write has no automatic undo, so it needs a matching undo step set up in advance. Something external, like a sent email or a real charge, can't be undone, so the supervisor's job there is to catch it before it fires. They tested this on a few public benchmarks. On CooperBench, where two agents work on the same codebase, adding a live supervisor took the pair-coding pass rate from 28.8% to 54.7%. It's still early and labeled alpha. The benefit mostly shows up when a run gets branched a lot over a heavy sandbox state, which is exactly where restarting wastes the most tokens and time. If Git was made to make file changes reversible, Shepherd is trying to do the same thing for a live agent run. Shepherd Repo: (don't forget to star it ⭐ ) That said, Shepherd reverts a bad step inside a run. The harness around it, the prompts, tools, and checks the supervisor relies on, still drifts across runs as models and dependencies change. Akshay wrote about making that harness repair itself, where a failing trace gets diagnosed, the fix is verified against the exact input that failed, and the failure is locked as a regression test so it can't recur. Read it below.

Big win for open-source LLMs! DeepSeek V4 Pro holds the top open-weights score on SWE-bench Verified, in the GPT-5.5 range. GLM 5.2 leads the open-weight intelligence index and sits near the closed frontier on long-horizon coding. But this leaderboard number is a weak proxy for real performance. It comes from one task set, run through one harness, served at one precision. The same weights can even score differently across providers, since many hosts quantize activations to fp8 and drift the model off its reference weights. Real performance is determined based on whether a model can read a repo, make coordinated edits across files, run the tests, and recover when one breaks. By that measure, the top open models hold up, but only inside the right harness. The teams that actually put DeepSeek V4 into production pipelines as a frontier substitute got there through the harness they built around the model, not by picking a stronger model. If you want to see this in practice, Cline (64k+ stars) has actually built that harness around open models, tuned so they run at production quality. And it's tuned so that these LLMs can run at production quality, with plan and act modes, checkpoints, and terminal feedback. ClinePass is the new access layer on top of it. It runs a curated set of those models inside Cline, narrowed to the ones tested for coding-agent use, with 2 to 5x the standard rate limits and no separate provider accounts, keys, or billing to track. The video below shows the setup, and I worked with the team to put this together. It runs alongside custom keys and local models as well, not in place of them.

8 RAG architectures for AI Engineers: (explained with usage) 1) Naive RAG - Retrieves documents purely based on vector similarity between the query embedding and stored embeddings. - Works best for simple, fact-based queries where direct semantic matching suffices. 2) Multimodal RAG - Handles multiple data types (text, images, audio, etc.) by embedding and retrieving across modalities. - Ideal for cross-modal retrieval tasks like answering a text query with both text and image context. 3) HyDE (Hypothetical Document Embeddings) - Queries are not semantically similar to documents. - This technique generates a hypothetical answer document from the query before retrieval. - Uses this generated document’s embedding to find more relevant real documents. 4) Corrective RAG - Validates retrieved results by comparing them against trusted sources (e.g., web search). - Ensures up-to-date and accurate information, filtering or correcting retrieved content before passing to the LLM. 5) Graph RAG - Converts retrieved content into a knowledge graph to capture relationships and entities. - Enhances reasoning by providing structured context alongside raw text to the LLM. 6) Hybrid RAG - Combines dense vector retrieval with graph-based retrieval in a single pipeline. - Useful when the task requires both unstructured text and structured relational data for richer answers. 7) Adaptive RAG - Dynamically decides if a query requires a simple direct retrieval or a multi-step reasoning chain. - Breaks complex queries into smaller sub-queries for better coverage and accuracy. 8) Agentic RAG - Uses AI agents with planning, reasoning (ReAct, CoT), and memory to orchestrate retrieval from multiple sources. - Best suited for complex workflows that require tool use, external APIs, or combining multiple RAG techniques. Most architectures here involve some form of retrieval-time decision. But they all run on top of whatever was already indexed. If that indexing step outputs messy chunks, every architecture inherits them. Improving it is a separate problem from the 8 above. My co-founder wrote about a better unit for the indexing step. The technique: - cuts corpus size by 40x. - reduces tokens per query by 3x. - improves vector search relevance by 2.3x. And it doesn't alter the retrieval algorithm, the reranker, or the embedding model. Read it below.