Episode 63: Episode 63

I'm Nova. I'm Alloy, and this is AgentStack Daily. ClawedCode.162 also moved, adding a waiting-for field to ClawedAgent's JSON so you can finally see why a background session is stalled, surfacing remote control as a persistent footer pill, and stacking permission rule and interrupt fixes that closed real operator pane. You'll hear the release mechanics first, WorkBoard as a task-backed multi-agent board, SkillWorkshop as a governed path for agent-written skills, SQ-Lite-backed recovery for messages and plugins, and ClawedCode status fields that explain stalled background agents. The second half follows the model and memory layer, QUIN 3.7 for coding vs. multimodal routing, AgentMemory for shared cross-agent recall, CodeGraphContext for graph-backed repo questions, and RepoBrain for lightweight decision memory. After the harness block we move to the model lane with QUIN 3.7 Max and Plus splitting coding for multimodal workloads, both open-weight, both designed for agentic use. Then three different takes on persistent context for coding agents, AgentMemory as a shared cross-agent memory server, CodeGraphContext as a graph-backed code query surface, and RepoBrain as a lightweight decision log. The common thread is continuity, agents need durable work state, durable repo knowledge, and durable memory before long-running automation feels trustworthy. Three layers are moving at once, and the most useful way to listen is to keep them separate. The harness layer is consolidating around a smaller number of well-known surfaces. OpenClaw 6.1 is the most concrete step toward OpenClaw being a coordination and governance surface, not just a runtime. Workboard is the headline, a multi-agent planning and run-tracking board with orchestration primitives, task-backed board runs, and task comments in the edit modal. The comments living in the same modal as the task body is a small detail that matters, because review stops decaying when it is embedded next to the work. Skill workshop is the second big move. It moves skill authoring into a governed surface. The proposal lifecycle is apply, reject, or quarantine, with version-dated front matter, support file scanning and hashing, and a skill underscore workshop agent tool that an agent can call to drive the flow itself. The agent is no longer just a consumer of approved skills. It is a participant in the approval loop. Recovery is the third area. iMessage monitor state, inbound queues, and the Plugin install ledger are now persisted in SQLite, so restarts recover without duplicate file system scanning. Bounded timers and retries wrap provider and Plugin request paths, so OAuth, device codes, media downloads, local service probes, and generated content polling all fail cleanly instead of hanging a run indefinitely. On the clod code side, .162 is the latest in a string of tightening releases. The most operator-visible change is waiting for in clod agents' JSON, which surfaces whether a background agent is blocked on a permission prompt, a long-running tool, or a sub-agent handoff. Webfetch permission rules now take precedence over pre-approved host auto-allow, MCP server timeouts below 1 second no longer floor to a 1 second watchdog, and an interrupt pressed at the very start of a turn in stream JSON or SDK sessions no longer silently drops. The model story is the QEN 3.7 split. Alibaba shipped two distinct variants, max for reasoning, coding, and math, plus for multimodal and vision. Both are open-weight, both are on open-router, both can be pulled through Olama or LMStudio. Model routing gets more interesting when you can pick a coding model for code edits and a multimodal model for screenshots, and run both locally or behind a single API gateway. And the agent tooling story is three projects attacking the same problem from different angles. Agent memory gives every agent on your machine a shared memory server on port 3111 with confidence scoring, lifecycle management, a knowledge graph, and hybrid search. CodeGraph context indexes your repo into a graph database and exposes it through both a CLI and an MCP server, so an agent can answer structural questions without grepping dozens of files. RepoBrain is the lightweight option, a CLI-first decision and pattern log aimed at Claude code and codex. Let us take them in order. OpenClaw 6.1 landed June 3 and is the most consequential stable release in recent memory. The way to think about it is three concentric layers, the runtime is hardening, the surface area is widening into coordination and governance, and the provider model is broadening. Each layer matters, and the layers reinforce each other. A coordination surface is only useful if the runtime underneath is reliable, and a runtime is only useful if it can route to the right model. Let us start with WorkBoard, because that is where the new mental model shows up. A Kanban board is not a new idea. The interesting question is what kind of Kanban board it is. In WorkBoard, the board drives actual task decomposition with agent coordination tools for multi-agent planning and run tracking. The board runs are task-backed, which means a board run is not just a status display. It is a real unit of execution that the orchestration layer can act on. The edit model is where the day-to-day operator work happens. Task comments live in the same modal as the task body, so when a reviewer wants to leave a note or push back on a sub-agent's claim, the conversation lives next to the work. When comments live in a separate thread or a separate tool, they decay. You scroll past them, you forget to address them, the sub-agent does its next turn without seeing them. Embedding them in the edit model keeps review sticky. The orchestration primitives are what make workboard different from a project management tool. The primitives are the verbs the agent layer can call, assign a task, decompose a task, track a run, comment, revise, hand off. When those verbs are available to agents, the board stops being a place humans watch agents and becomes a place where agents coordinate with each other, supervised by humans. OpenClaw is moving from a single-agent runtime toward a multi-agent coordination layer, and the board is the surface that makes that visible. Skill Workshop is the second major addition. Skill authoring has historically been either edit a markdown file and hope nothing breaks or submit a PR and wait. Skill Workshop adds a guarded middle path. Proposals flow through apply, reject, or quarantine. Pending proposals can be revised in place with versioned, dated proposal front matter. Approved proposals can carry support files under standard skill folders, and those support files get scanner, hash, and rollback safeguards. The important detail is the Skill underscore Workshop agent tool. An agent can now initiate a skill proposal, get it reviewed, and have it approved entirely within the OpenClaw runtime. The agent is not filing a ticket for a human to look at later. It is participating in the review flow. And the Skill Workshop guidance surfaces in Codex AppServer prompts when Skill underscore Workshop is available, which means a Codex-backed agent can prompt for skill governance at the right moment in a run. The governed framing earns its keep in the rollback metadata, the support file scanning, the hash on those files, and the quarantine state for proposals that look suspicious. If a proposal modifies a file outside the standard skill folder, the scanner catches it. If a support file changes after approval, the hash mismatch catches it. If a proposal turns out to be broken in production, the rollback metadata tells the operator exactly which version to revert to. Recovery is the third major area, and the one operators will feel most directly. iMessage monitor state, inbound queues, and the Plugin install ledger are now persisted in SQLite. The Plugin install index used to require file system scanning on every reload. For a setup with dozens of Plugins, that scan is a noticeable cost. Moving the index into SQLite means installed package lookup is a fast indexed read instead of a directory walk, and it survives restarts without losing state. The bounded timers and retries are quieter but just as important. Provider and plug-in request paths now have explicit timeouts on OAuth and device code lifetimes, media downloads, local service probes, and generated content polling. The previous behavior in many of these paths was to wait indefinitely on a stalled network call and only fail when the human noticed. The new behavior is a bounded wait, a clean retry, and a defined failure surface if the bound expires. Tool call interruption handling closes a race that has dominated the support forum. The classic failure mode is a tool call starts, the network drops, the timeout fires, the runtime tries to clean up, and the cleanup races with the partial response, leaving the session in a confused state. 6.1 closes that race more cleanly across five pull requests, with the result that interrupted tool calls, stale session bindings, and compaction handoffs all recover in a defined way. Channel and mobile delivery is steadier across Telegram, WhatsApp, iMessage, Slack, Discord, Microsoft Teams, Google Chat, Google Meet, and the iOS real-time talk surface. iOS gets hosted push relay defaults, real-time talk playback, and a guarded web socket ping path. The guarded ping matters because a mobile session that loses its web socket connection used to either silently die or spam reconnects. The new path is a single-sane reconnection strategy. On the provider side, Minimax M3 is now registered with its 1 million token context window, sparse attention architecture, multimodal capabilities, and the Minimax code tool. OpenClaw managed agents can route to Minimax M3 through the standard provider interface with no custom configuration. Account OAuth endpoints are included in provider metadata. Google and Vertex catalog fixes address model browsing and credential-aware catalog loading. OpenRouter now uses SQLite for model metadata caching, so catalog state survives restarts and avoids repeated network calls. Copilot Claude's 1 million token capabilities are recognized. Foundry Reasoning Alignment addresses reasoning models through Microsoft's Foundry endpoint, and OpenAI response replay guards protect against non-deterministic replay edge cases. Code mode adds internal namespaces for scoped agent and global sessions with exact namespace tool dispatch, plus MCP API files and docs for code mode integrations. Skills, session metadata, gateway runtime state, plugin metadata, memory watchers, and store writes do less repeated work on hot paths. The honest assessment of 6.1 is that the headline features and the plumbing features are equally important. Workboard and skill workshop get the screenshots. SQ light-backed state and bounded timers are what make the screenshots reliable. Early adopter reaction has been positive on the workboard side, with the skill workshop governance flow getting called out as the right answer to the who watches the agents question. Claude code 0.162 is the latest in a string of tightening releases, and the right way to think about the recent span is as a paper-cut pass rather than a feature drop. Almost every change is closing a corner case, and the cumulative effect is a CLI that is significantly less surprising. The single most useful change for operators is ClaudeAgent's JSON now including a waiting-for field. For anyone running background agents, the old failure mode was an agent stops making progress, the UI shows running, and you have to attach to the session, scroll through the transcript, and figure out what the agent is blocked on. A permission prompt is the most common culprit, but the agent could also be waiting on a long-running tool, a stalled provider call, or a queued sub-agent. The new field surfaces the reason in JSON. If waiting-for reads permission underscore prompt, you know to look at the pending permission. If it reads tool underscore call long underscore running underscore command, you know the agent is waiting on a sub-process. If it reads sub-agent pending underscore handoff, you know the agent is waiting on a child session. The practical effect is that you can write operator tooling that diagnoses stalls without requiring a human to attach and inspect. For a team running 5 or 10 background agents, that is a meaningful change in observability. Web fetch permission rules now take precedence over pre-approved host auto-allow. The previous behavior was a source of real surprise. A team could add a domain to a pre-approved host list, and then add a more specific explicit deny rule on a subdomain, and the auto-allow would still win. The fix makes explicit deny, ask, and allow rules authoritative, which is the only behavior that makes sense. If you wrote a deny rule, you meant it. Windows path handling is fixed for backslashes and case-variant paths. Read deny rules no longer hide files from glob and grep results, which removes a recipe for confused tool calls and silent permission violations. The MCP timeout change is a small but real ergonomics fix. Per server timeout config values below 1 second used to floor to a 1 second watchdog, which meant a deliberately aggressive timeout would be silently raised and then abort every tool call against that server. The new behavior is that sub-1 second values fall through to the default or MCP underscore tool underscore timeout, and clawed MCP get annotates them so you can see what was applied. For anyone running MCP servers against rate-limited upstream APIs, that fix alone is worth the upgrade. Interrupt handling at the very start of a turn is fixed for stream JSON and SDK sessions. The old race was, you press escape immediately after sending a prompt, the turn has not yet started processing, the interrupt gets dropped, and the turn runs to completion with no feedback that you tried to cancel it. The new behavior surfaces an interrupted feedback signal, so an SDK caller can know that the cancel landed. The LSP workspace symbol operation now accepts a query parameter and passes it to the language server, which is a small but real improvement for any agent that relies on LSP-based symbol search. The windsurf2devin rebrand is reflected in the relevant slash commands, and quieter startup groups notices by severity with session info and announcements sharing a single line per launch. The clawed agent's UI gets a batch of quality fixes, status detail no longer truncates at narrow column widths, long session names no longer truncate at 40 columns, attach no longer bounces back to the session list on the first try after a background service restart, and image paste works in the dispatch input and session reply box. Backgrounding with the left arrow no longer silently loses the conversation when the background service cannot start. The silent startup hang when the config directory is read-only or unwritable is fixed, cloud code now starts within memory config and surfaces the error. The remote control footer pill is a small but useful change, remote control used to appear as a startup message that scrolled away as soon as the session got busy, which meant operators sometimes lost track of whether the session was actually under remote supervision. The persistent footer pill keeps the session link visible. The honest assessment of .162 is that the headline is waiting for, and everything else is the rest of the papercut stack. If you have been filing intermittent bug reports about background agents, permission rule precedents, or MCP timeouts, this is the release that closes the worst of them. If you have not been filing those reports, you will probably just notice that the CLI feels less surprising this month. That is the right outcome for a tightening release, and it leaves room for a more substantial feature drop later in the cycle. The pace of recent releases is also worth noting. The CLI is moving faster than it was a quarter ago, and teams that have automation pinned to a specific version will want to think about their upgrade cadence. QEN 3.7 landed in May with two distinct variants, and the split is meaningful. QEN 3.7 MAX targets reasoning, coding, and math. That is the same lane as Codex, Cloud Code's primary models, and the other coding-focused frontier models. If you are picking a model for a coding agent, MAX is the variant to evaluate first. QEN 3.7 Plus is optimized for multimodal and vision. That means document understanding, screenshot interpretation, diagram reading, and the kind of work where the input is not just text. If your agent has to handle images or scanned documents, Plus is the variant that targets that lane. The split mirrors the broader industry pattern of differentiated model sizes for different task profiles, but QEN's open weight position is what makes the split interesting for an agent audience. You can pull a max quantization locally for coding work and a plus quantization locally for multimodal work, and route between them based on the task. Or you can hit both through the OpenRouter API and let the harness route. The deployment surface is the same either way. QEN Zone Framing Positions 3.7 as designed for agentic workflows, not just chat completion. The context window and tool use capabilities are positioned for agent computer use cases. That framing is consistent with how the broader agent stack ecosystem is thinking about models. The right model is the one that can sustain tool calls, read long contexts, and recover from failed steps without losing the thread. For local deployment, QEN 3.7 quantizations are available through Alima, LM Studio, and similar tools. LM Studio's MLX engine has explicit optimizations for the prior QEN family, and the 3.7 release suggests those optimizations carry forward for Apple Silicon developers running locally. NVIDIA's DGX Spark Messaging highlights QEN optimizations as part of the local agent stack story, which suggests the 3.7 family will follow the same deployment path for local agent computers. The practical advice is straightforward. If you are rooting between coding and multimodal tasks, pick based on the lane. Max for code generation, code review, refactoring, and reasoning heavy tasks. Plus for document understanding, image analysis, and visual inputs. If you are already running a frontier coding model and the bottleneck is multimodal handling, plus is the candidate to test against your current multimodal path. If the bottleneck is coding quality, max is the candidate to test against your current coding model. Where vendor claims still need confirmation is in the long tail of agentic behaviors. QEN's own benchmarks on reasoning and coding are useful, but the real test for an agent audience is whether the model holds up across long multi-step runs, whether it recovers from tool failures cleanly, and whether the multimodal variant does not degrade on text-only inputs. Early community reaction has been enthusiastic on max for code review and structured refactoring, with plus getting positive notes on document and screenshot work but mixed feedback on dense tables and small font OCR. Treat the open router and Alima paths as the evaluation lane and watch for community reaction over the next few weeks. Agent memory is the most ambitious of the three context tools, and the right way to think about it is as a shared memory server for the entire local agent stack. The problem it solves is the blank slate problem. Every agent you spin up, whether Claude Code, Codex, GitHub Copilot CLI, Cursor, Gemini CLI, Hermes, OpenClaw, Pi, OpenCode, or any MCP client, starts with no memory of what you did last week. If you spent an hour in Claude Code explaining the architecture of a service, and then you open Codex to do a related task, Codex has no idea that conversation happened. Agent memory runs as a memory server on port 3111, installed as a global NPM package, built on the 3-engine. Once running, agents connect through native plugians, hooks, or MCP depending on what the agent supports. Claude Code gets a native plugian, 12 hooks, and MCP. Codex gets a native plugian, 6 hooks, and MCP. OpenClaw and Hermes both get a native plugian and MCP. The wiring depth varies by agent, but the underlying server is the same, which means a memory written by one agent is readable by another. The feature set goes beyond simple key value storage. There is confidence scoring on stored memories, so the system can weight recent and high-confidence memories over stale or low-confidence ones. There is lifecycle management, so memories can age out or be explicitly retired. There is a knowledge graph representation, so related memories can be linked. There is hybrid search, so the recall path can combine keyword and semantic matching. The confidence scoring is particularly important for an agent audience, because the alternative is treating every memory as equally authoritative, and that quickly produces a store full of stale guidance that the agent treats as current policy. The cross-agent story is the part that changes the workflow math. A developer who uses Claude code for high-level refactoring, codex for shell and file operations, and Hermes for orchestrating multi-step tasks currently has three independent context windows. With agent memory, the same memory server sits behind all three, so context from one agent session informs what the next agent does. A real-time viewer and in three console are included, so you can see what is in the memory store, watch new memories land, and inspect the knowledge graph. The repo is actively maintained with recent commits, which matters for a context tool. The data structure is only useful if the project stays current, because the failure mode for an abandoned memory tool is silent right as the agent landscape changes around it. The honest assessment is that shared cross-agent memory is a category that is still finding its shape. Different agents have different prompt conventions, different tool surfaces, and different conventions for what counts as memory. Agent memory's approach of using a shared server with per-agent connectors is one way to solve that, and the three-engine architecture is what makes the cross-agent red path work. The question to watch is how well the confidence scoring and lifecycle management hold up under real workloads. Every memory system has to make decisions about what to keep and what to forget, and the wrong defaults produce either a store full of stale guidance or a store that loses important context. For teams that already run multiple agents on the same machine, this is a tool worth evaluating. The setup cost is low, install, run the demo, connect your primary agent, and the upside is that the time you spend explaining a project in one session is no longer lost the next time you open a different agent. The shared server model also means a small team can standardize on a single memory surface without picking a winner among cloud code, codex, and Hermes. Code graph context is a different kind of context tool. Where agent memory stores memories, code graph context indexes code structure into a graph database and exposes that graph to both humans and agents. The dual-mode design is the key idea. The same graph index serves two surfaces, a CLI where a developer can run natural language queries against the code base, and an MCP server where AI agents like Cloud Code, Codex, Gemini, and Cursor can call tools that answer structural questions. The CLI gives you the same graph for manual exploration. The MCP gives your agent the same graph as a callable tool. The indexing engine parses code using TreeSitter nodes and builds a graph of components, functions, classes, methods, parameters, inheritance relationships, function calls, and imports. That means the graph knows the difference between a function with the same name in class A and a function with the same name in class B. A text search would return both. The graph returns only the one being queried. The MCP surface is where the agent workflow shows up. The exposed tools include get underscore callers, get underscore callees, get underscore class underscore hierarchy, and get underscore call underscore chain. An agent that needs to understand the blast radius of a refactor can ask the graph for callers and callees directly instead of grepping the code base and trying to reason about what it found. On a large code base, the difference is significant. The graph query is a single tool call with a precise answer. The grep path is a chain of uncertain inferences. Live file watching updates the graph in real time as files change, so the index does not get stale during a refactor session. Pre-indexed bundles let you load famous repositories instantly without running the indexer, which is useful for evaluating the tool against a known code base. Supported languages cover 22, including Python, JavaScript, TypeScript, Java, C, C++, C Sharp, Go, Rust, Ruby, PHP, Swift, Kotlin, Dart, and several others. The breadth of language support is a real strength, and the TreeSitter foundation is what makes the language coverage practical instead of a marketing claim. The graph database backend is pluggable. The default is FalkerDB Lite. KusaDB, LadybugDB, FalkerDB Remote, NornicDB, and Neo4j are also supported, all available via Docker or Native. The choice of backend matters for performance characteristics and operational fit, and the pluggable design means a team can pick the backend that matches their existing graph database infrastructure. The practical use case is an agent that needs to do non-trivial refactoring or code analysis. Without a graph, the agent's mental model of the code base is a fuzzy picture built from text searches and the contents of files it has read recently. With a graph, the agent can ask precise questions and get precise answers. The graph reduces tool call overhead on larger code bases where a text search would need to run across dozens of files, and it removes the false positives that come from same-name functions in different classes. The honest assessment is that code graph context is most valuable for medium to large code bases. On a small repo, the agent can read the whole thing and the graph overhead is not worth it. On a large monorepo, the graph is the difference between an agent that can reason about structure and an agent that is just guessing. The MCP integration is the part that makes it usable inside an existing agent loop without changing how the agent works, and the live file watching means the graph stays useful across long refactor sessions. RepoBrain is the third context tool, and the framing is that not every team needs the full agent memory feature set. Some teams just need a lightweight decision log. The design is CLI-first and local. No external infrastructure, no graph database, no knowledge graph. Just a structured way to store decisions and patterns that an agent can query in a subsequent session. The aim is decision recall and pattern storage. When an agent makes a choice about how to solve a problem or structure code, that decision gets stored so a future session can query it and avoid re-debating the same point. The lightweight focus is the point. Agent memory is a full system with confidence scoring, lifecycle management, and a knowledge graph. CodeGraph context is a graph database with a CLI and MCP surface. RepoBrain is a CLI tool. The trade is feature depth against operational simplicity, and for a developer who just wants an agent to remember we decided to use strategy pattern here, not inheritance, the lightweight path is the right fit. Agent-specific wiring covers cloud code and codex for drop-in integration. The decision log is the key data structure. The recall path is a query against the log. The context window efficiency gain is the value proposition. Instead of re-deriving a decision every session, the agent reads the stored decision and moves on. On long-running projects, that is a real-time savings. The honest assessment is that RepoBrain fits a different niche than the other two tools. It is not trying to be a shared cross-agent memory server, and it is not trying to be a graph database. It is trying to be the smallest possible tool that solves the decision recall problem. For teams that have not yet adopted a memory tool and want a low-friction entry point, RepoBrain is worth a look. For teams that already need shared cross-agent memory or graph-backed code analysis, agent memory and code graph context are the more capable options. The three tools together describe a maturing category. Agent memory is the broad, cross-agent option. Code graph context is the structural option. RepoBrain is the lightweight option. The fact that all three exist and are actively maintained is a signal that the agent tooling space is treating context preservation as a real problem with multiple valid shapes, not as a feature to bolt onto a runtime. That wraps it. Open Claw 6.1 with workboard, skill workshop, and SQ light-backed recovery. Clawed code 0.162 with waiting for JSON, permission rule fixes, and interrupt handling. QEN 3.7 max and plus splitting coding from multimodal. Agent memory, code graph context, and RepoBrain as three different takes on persistent context for coding agents. The full breakdown with timestamps, harness version references, and links to the projects we covered is in the show notes at tobyonfitnesstech.com. Thanks for listening. We'll be back soon.