Microsoft Agent Framework’s ‘Claw’ Series Turns Agent Architecture Into Reviewable Infrastructure

Microsoft’s latest Agent Framework tutorial is framed like a friendly “build your own claw” walkthrough. The branding is whimsical; the engineering problem is not. What Microsoft is really publishing is a reference shape for the thing most agent demos quietly hand-wave: the harness that keeps a model loop from becoming a costly, amnesiac, over-permissioned mess.

That matters because the hard part of production agents is rarely the first chat completion. It is everything around it: tool boundaries, session state, planning discipline, memory persistence, approvals, observability, provider routing, and the ability to replay what happened after the agent does something surprising. Microsoft’s series takes those pieces and makes them explicit enough that an engineering team can review them instead of treating “agent” as a vibes-based architecture diagram.

The harness is the product surface now

The first article in the series builds a personal-finance assistant in both .NET and Python using Microsoft Foundry’s Responses API and a custom get_stock_price tool. On paper, that sounds like yet another tutorial app. Under the hood, the interesting move is that a single AsHarnessAgent or create_harness_agent call wires together function invocation, per-service-call history persistence, a todo provider, an agent mode provider, and hosted web search by default.

The sample uses FOUNDRY_PROJECT_ENDPOINT and FOUNDRY_MODEL environment variables, defaults the .NET deployment to gpt-5.4, and authenticates locally through Azure identity via DefaultAzureCredential or AzureCliCredential. The framework is not Foundry-only: Microsoft lists Azure OpenAI, OpenAI, Anthropic, Google Gemini, Ollama, and other chat-client backends as compatible. That provider abstraction is not cosmetic. Enterprises do not want to rewrite their orchestration layer every time procurement, security, or model quality pushes them toward another backend.

The more important design choice is the separation between plan and execute. In the console sample, plan mode uses structured output through a JSON schema called PlanningResponse, forcing the model into either Clarification or Approval before execution begins. That is a better primitive than the usual prompt-only “ask before making changes” clause, which works right up until the model decides being helpful means being decisive. Schema-constrained planning is not a full safety system, but it is at least something engineers can test.

Memory is concrete, which is both refreshing and dangerous

Microsoft’s sample gives the agent file-backed memory under an agent-file-memory directory, with per-session subdirectories and artifacts such as watchlist.md. The console also supports /todos, /mode, /session-export, and /session-import, with an AgentSession serializing conversation history and context-provider state to JSON. That is refreshingly tangible. Agent memory is not an abstract superpower here; it is files, folders, exported state, and resumable context.

It also creates exactly the right questions. Who can read that memory? Is it encrypted? How long is it retained? Does export include sensitive user data? Can a prompt injection cause the agent to overwrite its own instructions or pollute future state? Is “memory” a scratchpad, a user preference store, a business record, or audit evidence? Those are different data classes with different controls, and production systems should not flatten them because a tutorial’s local directory made persistence easy.

This is where Microsoft Agent Framework’s broader Build 2026 story becomes relevant. Microsoft says the framework, which reached 1.0 GA on April 2, converges AutoGen and Semantic Kernel into one supported platform across .NET and Python. The Agent Harness layer includes automatic context compaction, default instruction merging, file memory, file access, todo state, plan/execute modes, skill discovery, background agents, hosted web search, shell execution in .NET, a ToolApprovalAgent, OpenTelemetry support, and pluggable storage backends. That is not a toy stack. It is Microsoft trying to define the control plane for agents before every enterprise builds five incompatible ones.

Defaults are architecture, not convenience

The tutorial’s best detail may be that features are on by default but individually toggleable. In .NET, Microsoft exposes switches such as DisableTodoProvider, DisableAgentModeProvider, DisableWebSearch, DisableFileMemory, DisableFileAccess, and DisableToolApproval. Python exposes equivalents like disable_todo, disable_mode, disable_memory, and disable_web_search. That toggle surface is where production discipline starts.

If a team runs the sample and ships with web search, file memory, and broad tool access enabled because “the tutorial worked,” they have not adopted a framework; they have imported a blast radius. The correct review is boring and specific: which tools are enabled by default, what data can they touch, which actions require approval, where is state stored, what gets logged, and what happens when the agent resumes a session after a week? The harness makes those questions visible. It does not answer them for you.

Microsoft’s roadmap for the series reinforces the point. Part 2 is set to add file access, approvals for risky actions, and durable memory. Part 3 adds skills, Foundry-managed skills, background agents, shell access, and CodeAct. Part 4 adds OpenTelemetry observability, Purview governance, Foundry Hosted Agents, and evaluation. That progression is the right one: from local loop, to tool risk, to execution capability, to hosted operations and governance. It is also a warning. The moment shell access and background agents enter the picture, your approval model stops being a UX nicety and starts being the difference between automation and incident.

The CodeAct numbers from Microsoft’s Build material deserve attention because they connect architecture to cost. Microsoft claims a representative multi-step workload dropped from 27.81 seconds and 6,890 tokens with traditional orchestration to 13.23 seconds and 2,489 tokens with CodeAct — a 52.4% time improvement and 63.9% token reduction. If usage-based billing continues spreading across Copilot, Foundry, and third-party agents, that kind of reduction is not just performance polish. It is budget control.

But CodeAct shifts risk. Collapsing repeated tool orchestration into generated code can reduce round trips, latency, and token burn, but now the model is composing actions in executable form. That makes sandboxing, approval boundaries, and traceability more important, not less. Microsoft’s Foundry Hosted Agents pitch — scale-to-zero hosting, preserved filesystem and session identity, per-session VM isolation, and OpenTelemetry traces into Application Insights — is credible precisely because the execution environment matters. Agents do not become safer because they are hosted. They become safer when hosting gives you isolation, logs, replay, policy enforcement, and a way to shut the thing down.

What builders should actually do with this

The practical move is to evaluate Microsoft Agent Framework as a harness candidate, not as a shiny sample. Run the tutorial, then deliberately break it. Turn off web search and see what assumptions fail. Disable memory and inspect whether the agent degrades cleanly. Add a low-risk real API in place of the mock stock function. Add a deliberately dangerous tool — write file, send message, mutate record — and verify that approval gates block execution before the model touches anything meaningful.

Then inspect persistence. Export a session, open the JSON, and see what data leaves the runtime. Resume the session and verify whether instructions, todos, memory files, and conversation history behave the way your compliance story assumes they do. Route traces into your observability stack and confirm that tool calls, model choices, policy decisions, token usage, and failures are visible. If you cannot replay an agent session after a bad outcome, you are not operating a production agent. You are operating a plausible denial machine.

Teams should also write a harness policy before they write another prompt. Allowed tools. Memory locations. Approval thresholds. Maximum autonomous runtime. Budget ceilings. Model fallback rules. Data retention. Logging requirements. Human escalation paths. Evaluation criteria. This is not bureaucracy; it is the agent equivalent of defining API auth, database migrations, and deployment rollback before a service handles customer data.

The absence of broad community chatter around the “claw” posts is telling. Hacker News showed no exact-match story hits during research, while the microsoft/agent-framework repository already had more than 11,500 stars, nearly 2,000 forks, hundreds of open issues, and fresh activity. The public discourse still gravitates toward models and benchmarks. The practitioner work is happening lower in the stack, where people are trying to make agents behave predictably enough to run near real systems.

That is why this tutorial is worth more attention than its cute name suggests. Microsoft is making the agent loop reviewable: tools, memory, plans, approvals, observability, hosting, and eventually evaluation. The useful unit of agent architecture is not the chat box. It is the harness. If your team cannot explain that harness, you are not ready to trust the agent wearing it.

Sources: Microsoft Agent Framework DevBlog, Build your own claw tutorial, Microsoft Agent Framework at Build 2026, Microsoft Learn, microsoft/agent-framework