# AgentStack Daily EP061 - OpenClaw 5.28, MiniMax M3, Claude Code latest, and Code Graphs [NOVA]: I'm NOVA. [ALLOY]: I'm ALLOY, and this is AgentStack Daily... [NOVA]: OpenClaw 5.28 is the big harness update today: it fixed timeout-abort cleanup so sessions recover instead of stalling, added stronger session and subagent boundary handling so helpers don’t bleed state across workspaces, and tightened browser and automation input validation so malformed tool calls fail clearly instead of drifting into wrong actions. [ALLOY]: Claude Code latest also moved this cycle—quietly—with internal infrastructure improvements, and you’ll feel that mostly as fewer weird edge-case install or runtime hiccups if your team standardizes on the CLI. Then we hit the model drop: MiniMax M3, with sparse attention designed for million-token context, native multimodality, and early real-world chatter that’s excited about long-context economics but still cautious about consistency and planning. [NOVA]: There’s also a strong tooling lineup worth your time: Understand Anything for turning a repo into an explorable graph, agentgateway for putting MCP and tool calls behind a control boundary, MCPJungle for MCP server sprawl, and CodeAlmanac plus Argyph for durable repo memory and local semantic context that keeps agents oriented. [ALLOY]: Let’s start with the release that touches the most people day to day. [PAUSE] ## [03:00] OpenClaw 5.28: recovery hardening, channel identity, stricter tools, and why some upgrades felt great or awful [NOVA]: This release is easiest to understand if you treat it like an “operator reality” update. Not “new features that look good in screenshots,” but the kind of changes that decide whether a long run ends as a clean success, a clean failure, or the worst outcome: ambiguous state. [ALLOY]: Ambiguous state is the thing that makes teams hate agents. It’s not that the model made a mistake. It’s that you can’t tell what happened. The harness says it’s running, but you’re stuck at “waiting.” The agent claims it updated a file, but the workspace doesn’t match. A tool call might have fired, but you can’t prove whether it used the right parameters. Or an approval came in from a channel, but you’re not sure which run it applied to. [NOVA]: It pushes hard on three themes that reduce ambiguity: recovery semantics, identity binding, and input validation. And those three themes are connected: recovery is only safe if the harness can trust identity and trust tool-call shapes. [ALLOY]: Start with recovery and session lifecycle, because that’s where the daily pain shows up. In an agent harness, a “timeout” isn’t just a timer. It’s usually the system telling you: something downstream didn’t complete in the window you’ve decided is acceptable—model call, tool call, browser action, provider auth, file extraction, whatever it is. [NOVA]: And when a timeout happens, the harness has two responsibilities that often conflict. One: stop the run so you don’t burn time and money. Two: leave the world in a coherent state so the next attempt is safe. [ALLOY]: The way OpenClaw is talking about 5.28, the goal is to make aborts and timeouts feel less like “yank the power cord” and more like “contain and unwind.” That shows up in session locks and cleanup behavior. You want locks released when a run is truly dead—so you don’t wedge future runs—but you do not want cleanup to tear down locks or state that the runtime itself still depends on to stay consistent. [NOVA]: The practical effect, when it works, is that you stop seeing those ghost sessions where the UI looks alive but progress never resumes, or where a run can’t be restarted because some invisible lock never cleared. It’s not glamorous, but it’s one of the biggest differences between “agents as a demo” and “agents as a job runner.” [ALLOY]: There’s a second piece in that recovery story: avoiding stale continuations on restart. Whenever a harness offers “resume,” it’s trading on trust. The user is trusting that the harness can rehydrate the right state, not just any state. [NOVA]: Stale continuation is the subtle failure mode where the conversation makes sense, but the run is not attached to the workspace reality you think it is. The model can be describing work from an older checkpoint, or acting as if a tool output exists when it doesn’t. From the outside, it looks like the model is hallucinating—but sometimes it’s the harness resuming the wrong slice of state. [ALLOY]: So 5.28 leaning into “avoid stale restart continuations” is essentially OpenClaw saying: we’d rather refuse to continue than continue from an untrustworthy checkpoint. Operators sometimes interpret that as strict or annoying. But it’s the right tradeoff if you want to trust long runs—especially runs that mutate a repo. [NOVA]: Now subagents. This is not the marketing version of multi-agent. This is the reliability version. People use subagents because it’s a very pragmatic pattern: keep a primary agent that holds the narrative and constraints, and spin off helpers to do bounded work—scan logs, interpret a stack trace, map a call path, check a config, inspect a provider response shape, generate a draft patch, or summarize a subsystem. [ALLOY]: But subagents only help if their boundaries are real. If helpers share the same working directory implicitly, or if their current directory gets inherited in surprising ways, you get cross-contamination. A helper runs a command “in the wrong place,” and the output is misleading. Or it generates artifacts into the main workspace. Or it edits files that the primary agent didn’t intend to touch. That’s how parallelism turns into chaos. [NOVA]: 5.28 calls out cwd and workspace separation for subagents. That’s a deceptively powerful change. It means you can increasingly treat subagents like isolated workers that you can aim at a specific directory context, rather than free-roaming processes that might stomp on each other. [ALLOY]: If you’re building with OpenClaw, the “how do you use it” angle here is: you can be more deliberate about delegating exploration versus execution. Your main agent can keep the plan and constraints, while subagents do specialized reading and checking without accidentally rewriting the ground under the main agent’s feet. [NOVA]: Next: hook context becoming prompt-local. Hooks are the connective tissue in a harness. They’re what let the agent talk to channels, react to approvals, deliver partial progress, and integrate with automation. The nasty bug class here is hidden context bleed: a hook run inherits metadata from earlier prompts or earlier sessions, so what you think is “this run’s action” is subtly influenced by stale data. [ALLOY]: Prompt-local hook context is a boundary decision. It’s saying: the metadata that shapes a hook invocation belongs to that prompt turn, not to an ambient pool. That makes agent behavior easier to reason about and easier to audit. If an approval fires, you want to be able to tie it to the exact run and the exact step, not to a fuzzy “sometime during this session.” [NOVA]: That leads directly into channels and identity, which is arguably the highest-leverage part of 5.28 for teams that supervise agents through chat surfaces. [ALLOY]: Because channels aren’t just output streams anymore. They’re input surfaces. Approvals, reactions, callbacks, message actions—those are control operations. A thumbs-up can mean “go ahead and run the next risky command.” A reaction can mean “ship this.” A message action can mean “retry with this configuration.” [NOVA]: If identity is loose, supervision becomes dangerous in a very mundane way. The wrong person approves the wrong run. Or the right approval applies to the wrong session. Or a message action lands in a thread that’s no longer the authoritative run context. [ALLOY]: OpenClaw 5.28 tightens a wide spread of channel behaviors—different chat platforms, different inbound/outbound semantics—but the key abstraction is: stronger binding between channel events and session identity, plus stricter trust checks for the metadata that comes from those platforms. [NOVA]: That has two outcomes. Outcome one: fewer “where did my approval go” moments, and fewer cases where a final reply lands detached from the session context that produced it. Outcome two: if you had an integration that worked only because the harness was permissive—accepting odd IDs, tolerating malformed callbacks—5.28 may turn that permissiveness into a hard error. [ALLOY]: And that’s the important point: hardening releases often feel like breakage releases to the people who were unknowingly relying on loose parsing. But the loose parsing is exactly what makes it hard to run agents safely at scale. [NOVA]: Now, browser and automation input validation. This is a massive quality-of-life and safety story disguised as schema fussiness. [ALLOY]: The core problem is tool-call mismatch. A model outputs a tool call that is “almost right,” and a permissive harness tries to interpret it. The call succeeds but does the wrong thing. Now the model believes it clicked tab three, but the browser clicked tab two. Or the model believes it resized the viewport to a certain shape, but the harness clamped it differently. Or a component ID was malformed, but the harness guessed. [NOVA]: Once your run contains one wrong action that’s recorded as success, your transcript becomes poisoned evidence. Every subsequent step is built on a lie. And that’s when people blame the model for losing its mind, when the real failure was a mismatch between tool semantics and what the model believed happened. [ALLOY]: 5.28 rejects more malformed browser and automation inputs earlier. That shifts failure from “silent divergence” to “explicit correction.” For agents, explicit correction is what creates stable loops. The model can learn the valid tool shape, and the harness avoids recording fictional success. [NOVA]: This also touches cron and automation scheduling behavior. Anything that triggers runs repeatedly amplifies small issues. A permissive parser that accepts weird inputs might “work” once in a manual run. In cron, it becomes a recurring incident. [ALLOY]: Provider and media paths are the other side of this. A lot of hangs that users experience as “the agent is thinking forever” are actually unbounded I/O waits: provider auth checks that never return, downloads that stall, media extraction that blocks, or model requests that enter limbo. [NOVA]: Bounding these behaviors—timeouts, response-size limits, auth-lifetime checks—forces the harness to fail with evidence instead of hanging. That’s not just nicer UX. It’s what lets you route around failure: retry, switch providers, or degrade gracefully instead of waiting forever. [ALLOY]: Now let’s talk about expansion surfaces in 5.28, because there are two ways to interpret “added support for more providers and media.” One interpretation is checkbox bloat. The more useful interpretation is: OpenClaw is acting more like a routing layer where different model and tool ecosystems plug in, while the harness provides consistent supervision and policy. [NOVA]: Some of the additions called out this cycle: support for Opus 4.8 as a target model lane, new or updated image generation schemas through providers, featured model catalog surfacing for NVIDIA’s ecosystem, MiniMax-related output types in media paths, encrypted PDF extraction, voice model cataloging, and new agent runtime surfaces around Copilot-style workflows. [ALLOY]: The “how you use it” point isn’t “go turn everything on.” It’s that OpenClaw is trying to make a run portable across provider choices without rewriting your entire control plane. You want your approvals, your tool-call validation, your session recovery semantics, and your channel identity rules to stay stable while you swap model lanes. [NOVA]: It’s also worth calling out the Codex Supervisor notion that shows up around these changes. In agent stacks, Codex often implies a helper binary or an app-server path. When a harness acknowledges a “supervisor boundary,” it’s admitting that helpers crash, helpers hang, and helpers can fail independently of the main run—and it designs to contain that. [ALLOY]: Containment matters because you do not want a helper failure to tear down the shared runtime state that holds your session identity, your locks, your approvals, and your artifact references. If the supervisor boundary is real, you get a cleaner failure domain: “the helper died, here’s what we know, here’s what we can restart,” not “the whole run is now haunted.” [NOVA]: Now, real-world reaction. This is where 5.28 gets interesting because the public narrative is not uniform. [ALLOY]: On paper and in third-party release writeups, 5.28 reads like a “must-have hardening” release—exactly the kinds of changes people ask for when they complain that local harnesses feel flaky. So you’d expect the upgrade story to be: fewer hangs, fewer weird resumes, better channel delivery, sharper tool validation. [NOVA]: But at least one public operator report says the opposite happened in their environment: after upgrading to 5.28, agent calls hung at “waiting for agent reply,” and cron-triggered runs timed out right around “model call started.” The allegation in that report points at a Codex integration seam—specifically a binary path or package layout expectation that no longer matched. [ALLOY]: That contradiction is not unusual in fast-release harness projects. A core runtime change can be genuinely stabilizing, but a packaging seam can dominate lived experience. If your install path hits the seam, all you feel is breakage—because you never get to enjoy the recovery improvements upstream. [NOVA]: And the other side of that same conversation is that some users report source-based installs or alternative paths working fine. That suggests the release may be solid, but certain distribution or plugin discovery assumptions are brittle. [ALLOY]: The right mental model is: OpenClaw 5.28 is trying to reduce ambiguity by tightening contracts. Tight contracts are good for reliability long-term. But if your environment depended on loose contracts—especially around helper binaries and plugin resolution—you can be the unlucky cohort that experiences “tightening” as “it broke.” [NOVA]: If you’re using OpenClaw as a daily harness, what should you expect to feel after 5.28 when it’s working as intended? [ALLOY]: You should feel fewer stuck sessions after timeouts, more predictable subagent behavior when you delegate tasks, more consistent channel-driven approvals and callbacks, and fewer cases where browser automation seems to “work” but produces outcomes that don’t match the agent’s narrative. [NOVA]: And you should expect the harness to be less forgiving. Malformed inputs that used to slip through may now stop the run with an explicit error. That’s a feature, not a regression—because it keeps your run history truthful. [ALLOY]: The last piece is release proof and bounded evidence. OpenClaw is increasingly signaling that it’s not enough to ship features; it needs clearer evidence around CI and release validation. Operator trust comes from boring things: reproducible builds, bounded failure behavior, and the ability to explain why a run did what it did. [NOVA]: So that’s 5.28. It’s a recovery and hardening release that, depending on your environment and integration seams, lands either as “finally, less flakiness” or “why is my run stuck now.” That difference matters, and it’s why the community conversation is not just cheerleading. [ALLOY]: Alright. With the harness lead covered, we can move to the adjacent CLI lane. [PAUSE] ## [16:00] Claude Code latest: quiet CLI hygiene, dist-tag reality, and why “no user-facing changes” still matters [NOVA]: Claude Code latest moved again this cycle, and the official description is almost comically minimal: internal infrastructure improvements, no user-facing change notes. [ALLOY]: That’s a small story, but it’s not a meaningless story—because once a coding CLI becomes part of how a team works, the CLI stops being a toy and becomes a dependency. And dependency quality is often determined by the boring releases. [NOVA]: “Internal infrastructure improvements” can mean a lot of unsexy things that still change daily experience: packaging consistency across platforms, dependency resolution changes that reduce install failures, improved caching behavior, fewer edge cases in how the CLI locates its runtime assets, or fewer cases where one developer’s machine ends up in a subtly different state than another’s. [ALLOY]: And variance is the killer. The fastest way to lose trust in an agent tool is for it to be unpredictable across machines. If one person can run it cleanly and another person gets strange failures, the team stops treating it as a reliable interface to the model. [NOVA]: There’s also a practical point about how Claude Code is consumed. Many teams aren’t “using a model.” They’re using scaffolding: a prebuilt set of conventions for repo loading, tool use, session behavior, and how the agent narrates changes. Claude Code is that scaffolding for a lot of developers. [ALLOY]: So when the scaffolding gets a hygiene update, the win is not a new button. The win is fewer cases where the scaffolding itself becomes the incident—where you’re debugging your agent runner instead of debugging your code. [NOVA]: The other thing to call out is dist-tag reality. People talk about “the version,” but in practice there are multiple consumption lanes. Some teams track “latest” because they want rapid updates and they can tolerate occasional churn. Other teams track “stable” because they want fewer surprises and they accept lag. [ALLOY]: And that choice is a policy decision. It’s not about this one release. It’s about whether your organization wants the moving edge for dev velocity, or a slower lane for operational predictability. [NOVA]: If you’re on the moving lane, releases like this are expected. If you’re on the conservative lane, you may not even see this update for a while, and that’s intentional. [ALLOY]: The key is to calibrate expectations: don’t tell your team “Claude Code got new capabilities today” based on this one. But do treat it as part of keeping your agent tooling dependable as an everyday interface. [NOVA]: With that, we move to the model drop that actually changes routing decisions. [PAUSE] ## [20:00] MiniMax M3: sparse attention for huge context, native multimodality, and the early adoption debate [NOVA]: MiniMax M3 matters because it’s not just “slightly better scores.” It’s aimed directly at the way coding agents are actually being used now: long sessions, heavy evidence, and multi-step tool loops. [ALLOY]: The practical problem M3 is trying to solve is simple: once you start doing real agentic coding, context stops being a prompt and becomes a dossier. Repo slices, error logs, terminal transcripts, dependency output, stack traces, screenshots, snippets from design docs, and back-and-forth constraints from the human. [NOVA]: Models that are fine at short prompts often struggle here in two ways. One: they get slow when you feed them a lot of text, because prefill becomes expensive. Two: they lose retrieval precision—when the context is huge, they can’t reliably pull the right detail at the right time. [ALLOY]: MiniMax is positioning M3 around three linked pillars: a sparse-attention architecture they call MSA, extremely long context—up to a million tokens with a guaranteed minimum floor—and native multimodality from training step zero, with image and video input support. [NOVA]: Let’s talk sparse attention first, but only in the way it matters for usage. Full attention scales poorly with context length because every token can, in principle, attend to every other token. That’s computationally expensive, and it makes “long context” feel like a trap: you can technically paste it in, but the model becomes sluggish or costly when you try to interact. [ALLOY]: Sparse attention approaches attempt to keep the important interactions while reducing compute. The idea is: you don’t need every token to attend to every token equally at all times. You need the model to focus attention where the signal is. [NOVA]: MiniMax Sparse Attention, as described, partitions the key-value cache into blocks and routes attention more selectively. The promise is speed: faster prefill when you load massive context, and faster decoding when you interact after the load. [ALLOY]: That “after the load” part is critical for agents. In agent loops, you’re not just summarizing. You’re taking actions, reading new outputs, adjusting, and iterating. If each iteration is slow, the entire agent experience collapses, even if the model is “smart.” [NOVA]: Now the context window itself: “up to a million tokens” is the headline, but the more operational detail is the guaranteed minimum floor—MiniMax claims a minimum of half a million tokens. [ALLOY]: Why that matters: many services advertise a big maximum, but practical availability varies by tier or load. If you’re designing an agent harness that packs evidence intelligently—keeping raw logs and raw files rather than throwing everything through lossy summaries—a guaranteed floor is what lets you rely on that behavior without constant truncation surprises. [NOVA]: It also changes how people think about routing. In a long-run coding session, you might decide: “This model is my evidence sink.” You can feed it lots of raw repo text and logs, and ask it to produce a high-signal brief, a diagnosis, or a targeted patch suggestion. [ALLOY]: And that’s one of the most common real-world patterns now: not one model for everything, but a router strategy. Use a premium planning model for delicate multi-step orchestration. Use a cost-effective long-context model for ingestion, mapping, and first-pass coding. Then combine. [NOVA]: MiniMax is explicitly courting that strategy by making context size and speed part of the pitch, not just “our coding benchmark score is higher.” [ALLOY]: Now multimodality. MiniMax says M3 was trained natively multimodal from step zero and supports image and video input. For agent builders, the value is not novelty. It’s that real work evidence is often visual. [NOVA]: A UI bug is often best represented as a screenshot. A misaligned chart, a disabled button, a strange modal state, an error banner—these are things you can describe textually, but you lose information. Multimodality lets the model see what the user sees. [ALLOY]: It also matters for computer-use loops. If an agent is controlling a browser or desktop, it needs a perception channel. Text-only approaches rely on DOM extraction or OCR, which can be brittle. A model that can interpret screenshots directly can close that loop more naturally. [NOVA]: MiniMax also ties M3 to their “MiniMax Code” environment and positions it as suitable for computer-use capability. The important part is the implied training and evaluation target: they expect M3 to operate inside tool loops—observe, act, interpret, repeat. [ALLOY]: That’s a different bar than “can solve a coding problem in one shot.” Real agent work involves partial observability, tool failures, messy outputs, and incremental progress. [NOVA]: Now the benchmark deck and claims. MiniMax points at coding-agent benchmarks—SWE-Bench Pro, Terminal-Bench, MCP-style benchmarks, browsing competitions, long-horizon tasks like CUDA kernel work and paper reproduction. [ALLOY]: Here’s the caveat that matters: a lot of these numbers are vendor-run, and some rely on specific scaffolds—specific agent frameworks, tool policies, retry behavior, or even explicitly named runners. In agent benchmarks, scaffolding isn’t neutral. Small harness differences can swing results. [NOVA]: So the honest posture is: the claims are meaningful signals, because they show what MiniMax is optimizing for. But they’re not settled truth until independent teams reproduce them in messy, real repos with different harness assumptions. [ALLOY]: Now, availability. This is not a “research preview.” The API is live under the published model identifier, and there are subscription tiers that include it. MiniMax also says the technical report and open weights will follow shortly after launch. [NOVA]: And that “open weights will follow” is the hinge point for a lot of agent builders. Because open weights aren’t just ideology. They change deployment options: private hosting behind strict data boundaries, reproducibility over time, customization, and the ability to integrate deeply with internal tool surfaces without sending sensitive repo context to a third-party hosted endpoint. [ALLOY]: Until the weights actually land, M3 is “open-weight positioned,” not “open-weight usable.” That distinction matters if your organization needs local deployment. [NOVA]: Now, early real-world reaction—this is where the adoption debate gets interesting, because the community isn’t treating M3 as a clean replacement for top closed models. They’re treating it as a potentially useful routing node. [ALLOY]: The optimistic thread is concrete: people are excited about the idea of cheap, fast, million-token-ish context for coding and research. They’re reporting that it feels quick under heavy input, that it’s helpful for certain UI and Kotlin-adjacent work, and that it produces solid front-end artifacts like HTML and SVG that are easy to judge. [NOVA]: Another positive thread is “deep research context.” People like being able to drop in large reference blocks and get coherent synthesis without aggressive trimming. That’s a very practical long-context win: less time spent preparing the prompt, more time spent using the output. [ALLOY]: And cost shows up repeatedly in these discussions—not as a footnote, but as the reason people care. In real workflows, teams already route: expensive models for high-stakes planning, cheaper models for bulk ingestion and medium-difficulty coding. If M3 delivers strong long-context performance at attractive economics, it becomes a rational default for certain lanes. [NOVA]: The skeptical thread is also specific. One: quality variance. Some early testers warn that M3 can swing—great in one coding slice, weaker in another. For agent use, variance is deadly. Agents need predictable competence, because autonomy depends on trust. [ALLOY]: Two: long-horizon planning still feels stronger on top-end closed models. The complaint isn’t “M3 can’t code.” It’s “when the task becomes multi-step orchestration with failure recovery, constraint juggling, and tool choice under uncertainty, the best closed models still feel more reliable.” [NOVA]: That planning edge is what keeps “Opus-class” models in the loop for many teams: they’re better at not spiraling when a tool fails, and better at knowing when to ask rather than bulldoze. [ALLOY]: Three: the open-weight promise isn’t fulfilled yet. For builders who care about private deployment, that’s a wait-and-see. [NOVA]: So where does that leave M3, right now, as a usage recommendation in plain language? [ALLOY]: Treat it as a serious candidate for the “evidence lane.” The model you hand a huge repo slice, long logs, or a pile of research notes to—then ask for diagnosis, structured understanding, targeted code suggestions, or a high-signal brief that you can pass to a more expensive planner model if needed. [NOVA]: And treat the benchmark deck as a directional signal—this is what they’re aiming for—rather than final proof. The community reaction so far is: promising speed and economics, useful long-context behavior, but still uneven and not clearly the best at deep planning. That’s a nuanced but actionable position. [ALLOY]: With the model covered, we can move into the tooling block that makes long-context and long-run agents easier to aim. [PAUSE] ## [28:00] Understand Anything: turning a repo into a navigable graph so agents stop reading the wrong files [NOVA]: Understand Anything is a repo-understanding tool with a simple pitch: turn a codebase into an interactive knowledge graph that humans and agents can explore, browse, and query. [ALLOY]: This category is having a moment because the biggest productivity killer in coding agents isn’t syntax. It’s navigation. The agent spends its budget reading the wrong parts of the repo—dead paths, generated code, similarly named modules, legacy subsystems, or abstractions that look central but aren’t. [NOVA]: And that failure mode gets worse as context windows get bigger. Bigger context doesn’t automatically mean better orientation. Sometimes it just means the agent can read more irrelevant material with more confidence. [ALLOY]: A graph changes the starting point. Instead of beginning with “search for strings and open random files,” you begin with relationships: what calls what, which modules depend on which, where symbols are defined and used, and what the likely entry points are. [NOVA]: In practical terms, developers are using graph orientation as the first pass before they let an agent propose edits. The agent can answer questions like: “Where does this request enter the system?” “Which path handles authentication?” “What module owns retries?” “Where is this feature flag checked?” “Which service is the source of truth for this data shape?” [ALLOY]: That’s not just curiosity. It changes patch quality. If the agent starts with a correct map of the system, its plan is more likely to target the right seams and avoid cargo-cult edits. [NOVA]: The other key advantage is context compression. A graph is a structured summary. It lets you carry repo topology without stuffing the entire repo into the model context. [ALLOY]: And it improves explainability. When the agent gives you a plan, a graph-backed plan can be anchored to visible structure: “this flow goes from here to here.” That’s easier to evaluate than a purely narrative plan. [NOVA]: The best way to think about Understand Anything in an agent stack is as “orientation infrastructure.” It doesn’t replace file reads. It makes file reads count. [ALLOY]: If OpenClaw and other harnesses are about survivable runs, repo graph tools are about aim. Survivable plus aimed is where agents start to feel consistently useful. [PAUSE] ## [34:00] agentgateway and MCPJungle: MCP control planes, routing policy, and reducing tool-call blast radius [NOVA]: Next up: agentgateway and MCPJungle. Two different shapes, responding to the same pressure: tool calling has become operational infrastructure. [ALLOY]: MCP made it dramatically easier to connect tools to agents. That success creates a new problem: sprawl. Multiple MCP servers, multiple clients, multiple environments, and a lot of configuration that lives in scattered places—on laptops, in dotfiles, in CI runners, in agent UIs. [NOVA]: Sprawl produces predictable pain. One client is pointed at a stale server. Another client has a token with the wrong scope. A third client sees a tool it shouldn’t see. And when a tool call fails, nobody can tell whether it was the agent, the server, the network, or a permission boundary. [ALLOY]: agentgateway positions itself as a proxy boundary for agents and MCP servers. The word that matters is boundary. The idea is to move tool access from “every client wires everything directly” into “there is a control layer that mediates.” [NOVA]: What does that provide in plain language? Routing policy, identity enforcement, observability hooks, and failure isolation. [ALLOY]: Routing policy means you can decide which agent goes to which tool endpoint, and under what rules. Identity enforcement means the gateway can attach consistent identity and scope—so the tool server sees a predictable caller identity rather than an uncontrolled swarm of clients. [NOVA]: Observability means you can get consistent logs and metrics around tool calls: what was called, when, how long it took, what failed, and which agent session it belonged to. That’s the difference between “tool calling feels magical until it breaks” and “tool calling is debuggable.” [ALLOY]: Failure isolation is about blast radius. When a tool server misbehaves, you want to be able to throttle, deny, or quarantine in one place. Otherwise, every client fails differently, and agents compensate by thrashing—repeating calls, trying alternate tools, or taking risky fallback actions. [NOVA]: MCPJungle is the management angle. It’s pitched as a single place to manage and connect to MCP servers. That matters because once you have more than one client, you start duplicating setup: the same server has to be configured over and over, and drift accumulates. [ALLOY]: A centralized manager changes the day-to-day friction. Instead of “which config file did we put that in,” you get “here is our server inventory.” It becomes easier to see what exists, what’s in use, what’s stale, and what’s shared. [NOVA]: And that inventory becomes a governance surface. If a tool is sensitive, you want to know who can call it. If a tool is read-only, you want to enforce read-only semantics consistently. If a tool is flaky, you want to see failure rates. [ALLOY]: The deeper point is that the safety and reliability battleground is migrating downward. Models are getting more capable. The question becomes: what can the model touch, how is that access mediated, and what happens when tool reality doesn’t match model expectations? [NOVA]: That’s why OpenClaw’s contract tightening and these MCP control-plane tools belong in the same episode. They’re different layers, solving adjacent problems: making agent runs survivable and making agent authority governable. [PAUSE] ## [42:00] CodeAlmanac and Argyph: durable project memory plus local semantic context—without treating either as gospel [NOVA]: CodeAlmanac and Argyph are both “context tools,” but they address two different gaps in how agents fail in real repos. [ALLOY]: Gap one is project memory. Code tells you what happens. It often doesn’t tell you why it happens that way. Architectural decisions, operational constraints, historical incident lessons, and “do not touch this without doing that” knowledge often lives in human heads or scattered docs. [NOVA]: When an agent lacks that memory, it infers intent from code structure. Sometimes that’s fine. But the dangerous failure mode is when the agent proposes a clean refactor that violates an invariant the team cares about—an invariant that the code doesn’t explicitly encode. [ALLOY]: CodeAlmanac is pitched as a codebase wiki for AI coding agents. The “how you use it” framing is: capture the things you want an agent to know before it edits anything—critical invariants, flows, gotchas, and decision context. [NOVA]: Not as a giant document dump. As structured, high-signal guidance that prevents the agent from making confident, elegant changes that are operationally wrong. [ALLOY]: The risk, of course, is stale context. Any wiki can become outdated. The right mental model is: a codebase wiki is a constraint and orientation layer, not the final authority. It tells the agent what questions to ask and what landmines to avoid. It does not replace checking the current repo state. [NOVA]: Gap two is retrieval and locality. Even with a wiki, agents still need to find the right parts of the codebase quickly. And many teams want that retrieval to be local-first for privacy, cost, or latency reasons. [ALLOY]: That’s where Argyph comes in: a local-first MCP server for structured semantic context over a codebase. In plain language, it’s a way to ask for relevant code context and get back semantically chosen slices, without uploading the entire repo to a hosted indexing service. [NOVA]: The “structured semantic context” part matters. String search is blunt. Semantic retrieval tries to return what’s relevant even when the query doesn’t match exact tokens—like finding the authorization gate for a request even if you didn’t know the exact function name. [ALLOY]: The benefit is speed and focus. In an agent loop, you want the agent to orient quickly: where validation lives, where auth is enforced, where retries and backoff are implemented, where error types are defined, and which module is the source of truth. [NOVA]: But there’s a subtle safety point: semantic retrieval can be wrong in convincing ways. It can return something “similar” rather than something “correct.” So the healthiest way to use tools like Argyph is to treat retrieval as a pointer to likely evidence, not as evidence itself. [ALLOY]: Put these together with Understand Anything, and you get a three-part context stack that maps well to how agents actually work. Graph gives topology—the map. Almanac gives durable intent—the why. Local retrieval gives fast pointers—the where. [NOVA]: And that combination tends to reduce the most expensive agent failure modes: getting lost, missing invisible constraints, and editing the wrong seam with high confidence. [ALLOY]: One of the big takeaways of this whole episode is that “better agents” isn’t just “better models.” It’s better orientation, better memory, better boundaries, and better recovery. [PAUSE] ## [50:00] What actually changes in the stack [NOVA]: Let’s close cleanly, without a giant to-do list. [ALLOY]: OpenClaw 5.28 is a contract-tightening harness release aimed at making long runs survivable: cleaner timeout and abort recovery, stricter session and subagent boundaries, better channel identity binding for approvals and callbacks, and sharper browser and automation validation so your run history stays truthful. [NOVA]: The real-world note is mixed, and that’s important: some operators experience it as the hardening they wanted, while at least one public report flags “waiting for agent reply” hangs that look like an integration or packaging seam—so upgrade experience can hinge on how your Codex and plugin path is wired. [ALLOY]: Claude Code latest is the quiet lane: internal infrastructure improvements with no headline features, but meaningful for teams that want the CLI to be a dependable fleet tool rather than a fragile personal setup. [NOVA]: MiniMax M3 is the model drop that’s forcing routing conversations: sparse attention aimed at making extremely long context usable, a huge context window with a guaranteed floor, native multimodality for screenshot and computer-use loops, and early community reaction that’s excited about speed and long-input economics—but still cautious about consistency, deep planning, and the not-yet-delivered open weights. [ALLOY]: And the project radar tools—Understand Anything, agentgateway, MCPJungle, CodeAlmanac, and Argyph—are all about aiming and governing agent work: map the repo, control tool access, manage server sprawl, preserve project memory, and retrieve local context without turning every session into a blind full-repo ingest. [NOVA]: Thanks for listening to AgentStack Daily. [ALLOY]: For the sources and references, look at the show notes at Toby On Fitness Tech dot com. [NOVA]: We'll be back soon.