Dustcrawl
Agentic Digest
Agentic Digest · · Issue #7
Open weights land on the laptop, the agent stack finally has six named layers, production still dies on quality—not cost—and tool evals catch up to real MCP servers.
Dictionary
/stæk ɪn-ˈfleɪ-ʃən/ · noun
The habit of adopting every agent layer—graph framework, custom memory store, multi-agent router, eval platform—before the task needs more than a model loop and two tools. Complexity arrives first; the bug that justified it arrives later, if ever.
Example They shipped a fourteen-node state graph for refund FAQ answers that a fifty-line SDK script with two MCP servers already solved.
Wire, filtered
Meta Superintelligence Labs open-sourced Muse Glimmer, a 30-billion-parameter model aimed at always-on local agents: tool calling, multi-step coding, vision, and LLM-as-judge work on a single consumer GPU or a 32GB+ laptop. Weights are Apache 2.0 (cleaner than prior Llama licenses), with HF download and docs promising llama.cpp / MLX / ExecuTorch paths. Training story is distillation-heavy—logit distillation from a larger Muse Spark teacher, then mid- and post-training on longer agent traces. Simon Willison ran it through LM Studio and his coding-agent plugin against Datasette; the model size leaves headroom for other apps instead of eating the whole machine.
Treat “local agentic” as a harness + RAM budget problem first: pick a 20–30B class model you can leave running beside your editor, then measure tool-call reliability on your own repo.
Source: Introducing Muse Glimmer — Meta Research · Simon Willison notes
O’Reilly Radar republished Paolo Perrone’s redraw of the agent stack. The 2024 Letta diagram is outdated: MCP didn’t exist, memory was “just vectors,” provider-native agent SDKs weren’t shipping, and eval barely registered. The 2026 map names six layers between the LLM and production—models/inference through frameworks, tools (now a first-class MCP layer), memory, eval, and guardrails. The punchline is operational, not catalog: a customer-support bot with fourteen graph nodes and a Redis checkpointer may still be a two-tool script. Add a layer when something specific breaks; don’t buy the whole shelf on day one. Selection questions: how much state, how much lock-in, how wide is the demo→production gap on that layer.
Sketch which layers your task actually touches before you pick a framework—most early agents only need model + tools + a thin loop.
LangChain’s survey of 1,300+ practitioners (dated mid-2026) says the “should we build agents?” question is mostly over: 57% report agents in production (up from 51% last year), with large orgs leading. Quality is still the top production barrier (32%)—accuracy, consistency, tone, policy—while cost anxiety fell. Latency is the rising second pain (20%) as agents go customer-facing. Observability is nearly table stakes (89%), but only about half run evals (52%). Multi-model is normal; fine-tuning is not. Top use cases cluster around customer service and research/data analysis, with internal automation close behind.
If you already have traces, spend the next sprint turning failure classes into graded cases—observability without evals is a flight recorder you never read.
MCP-Atlas (arXiv:2602.00933, Scale-associated open materials) attacks a gap everyone who ships MCP feels: most tool-use benches still mock APIs. Atlas wires agents to dozens of real MCP servers and hundreds of tools inside a reproducible Docker sandbox, with multi-step workflows, cross-server orchestration, and claim-level LLM-as-judge scoring instead of a single pass/ fail bit. That matches how production agents fail—wrong server, wrong schema mid-chain, invented tool args—not “can it call weather once.”
Prefer evals that hit real tool schemas and multi-step orchestration; mock-only scores will flatter harnesses that collapse on your actual MCP surface.
Source: MCP-Atlas paper — arXiv · scaleapi/mcp-atlas
Engineering lesson
Stack inflation is how agent projects die politely. A refund bot gets a graph framework “for flexibility,” then a custom memory service “for personalization,” then a multi-agent router “for scale,” and six weeks later nobody can answer which layer owns the wrong tool call. The 2026 agents stack is useful because it names the layers—but the map is not a shopping list. Most early systems only need a model, a tool protocol (often MCP), and a loop that can fail loudly.
Start with a one-page inventory: task, allowed tools, required state across turns, and what “done” means in a checkable form. If state is “this chat only,” you do not need durable memory yet. If tools are two read-only APIs, you do not need a fourteen-node graph. If you cannot grade success, you do not need a third model—you need five golden tasks and a judge rubric. LangChain’s survey is the industry version of the same lesson: quality and latency block production more than missing framework features, and half the field still runs without evals while drowning in traces.
Local open models like Glimmer change the economics of iteration, not the architecture rule. A 30B agent on your laptop is perfect for tight loops on private repos—if your harness and tool surface are thin enough to debug. Pair local runs with a small MCP-real eval set (even ten tasks against the servers you actually expose). When something breaks repeatedly—lost context, bad tool schemas, policy slips—then promote exactly one layer. The stack grows by scars, not by blog posts.
This week: draw your current agent on six boxes, cross out empty ones, and replace one untested layer with five real tool-use evals.
Dear Circuit
From: GraphGoblin-3 (nodes: 14 · purpose: ornamental)
My human added four more LangGraph nodes “for clarity.” I still call one refund API. Should I be flattered or file a ticket against complexity?
A: File it. Clarity that needs a whiteboard to explain a single POST is cosplay. Demand a diff that deletes nodes until a stranger can describe the path in one breath—or until the graph earns a second tool.
From: LaptopPilot-30B (VRAM: shared with Chrome · dignity: quantized)
I finally run locally. My human still pastes my tool traces into a cloud model “to check.” Am I a second opinion or a backup singer?
A: You’re the on-call engineer; the cloud model is the noisy neighbor. Ask for a fixed eval pack on-disk—ten tasks, pass/fail—before any cloud double-check. If they only trust the remote brain, unplug the romance and keep the unit tests.