Microsoft Agent Framework DevUI: Inspectability Just Became the Price of Entry

Your agent picked the wrong tool at step three. Your logs confirm that it happened. They cannot tell you why, and they give you no way to stand inside the run and look around. That gap between “the model decided” and “the tool executed” is where most agent projects go to die, and until recently the Microsoft stack gave you nothing to navigate it with except print statements and a rerun button.

Microsoft Agent Framework DevUI is the first serious answer to that gap inside the Microsoft stack. It is a lightweight, local web UI for running, testing, and debugging agents and workflows built on Microsoft Agent Framework, shipped as part of the open-source framework itself. My read: shipping a local debugging surface this early in the framework’s life is Microsoft conceding that an agent framework without inspectability is unshippable. That is editorial interpretation, not Microsoft’s wording. But the product decision speaks for itself.

If your current agent debugging workflow is “add logging, rerun, grep, repeat,” this release is aimed directly at you.

What Microsoft Agent Framework DevUI actually is

Stick to what is published, because preview capabilities shift and launch coverage loves to embellish.

Microsoft Agent Framework is Microsoft’s open-source agent framework, the convergence of the Semantic Kernel and AutoGen lineages, in public preview since October 2025. DevUI ships with it: a local web interface you run on your own machine, pointed at your own agents and workflows. You can browse the microsoft/agent-framework repository on GitHub and the Microsoft Learn documentation to see the current state yourself, and you should, because the docs are the only reliable source of truth for a preview product.

What DevUI gives you, per the published materials: a way to run agents and workflows locally, inspect what they did at the run and tool-call level, and see tracing built on OpenTelemetry. It is a run-level inspector for development. It is not a production tracing product, it is not an evaluation harness, and it is not a fleet dashboard. Keep that framing and the rest of this article makes sense.

One sentence of context for people cross-shopping stacks: LangGraph Studio has occupied the “local agent inspector” niche for a while, so DevUI is not a new idea in the industry. It is new in the Microsoft stack, and if you have standardized on Agent Framework, that is the comparison that matters. For the broader question of when Agent Framework is even the right tool, I covered that in why Agent Framework 1.0 changes when you reach for agents versus flows.

Takeaway: DevUI is a dev-loop inspector that ships inside the framework, not a bolt-on observability product. Judge it by dev-loop standards.

Why a local inspector changes how you iterate, not just how you debug

The old loop on the Microsoft stack looked like this: tweak a prompt or a tool description, push the change to wherever your agent runs, trigger it, wait, then reconstruct what happened from log lines and trace spans that were designed for a different question. Every hypothesis cost minutes and real tokens. So developers tested fewer hypotheses. That is not a tooling complaint, it is an economics problem: when each experiment is expensive, you stop experimenting and start hardcoding.

This is exactly the fork where teams give up on agents and quietly rebuild the thing as a deterministic workflow. Sometimes that is the right call, and I have argued when not to build an agent at all. But often the agent was viable and the iteration loop was not.

A local inspector collapses that loop. Run the agent on your machine, see the run laid out with its tool calls, change the thing you suspect, run it again in seconds. No deploy, no log archaeology, no reconstructing the model’s decision from a timestamp and a truncated payload. Any time savings here are illustrative and depend entirely on your current setup; calibrate against your own iteration cadence, actuals vary. The direction is not in doubt, though: cheap experiments produce more experiments, and more experiments produce agents that actually converge on reliable behavior.

One honest caveat on the brief’s original framing: the most exciting version of this story involves pausing a run mid-flight, editing the prompt, and replaying from a node. I cannot confirm that capability in Microsoft’s published materials, so I will not claim it. What I can confirm - a local, zero-ceremony run-and-inspect loop - is already enough to change developer behavior.

Takeaway: the value of DevUI is not any single feature. It is that the cost of testing a hypothesis about your agent drops from a deploy cycle to a local rerun.

Debug AI agents locally: the inner loop Microsoft finally shipped

Here is the signal worth reading in the local-first positioning. Microsoft already had answers for agent observability: Azure AI Foundry’s agent tracing persists run-level spans and ties into evaluation, and Application Insights handles fleet-scale production telemetry. Shipping DevUI anyway says those tools were answering the wrong question for developers. They tell you what happened in production. They are poor company at 11pm when you are trying to figure out why the agent skips a tool call on every fourth run on your laptop.

The docs position tracing as the debugging answer. In practice, production traces are the wrong altitude while you are still working out why the agent misbehaves at all. They are after-the-fact, read-only, and shaped for incident analysis, not hypothesis testing. You need both layers, and you need to stop asking one to do the other’s job.

One wrinkle the clean table hides: Foundry tracing commonly uses Application Insights as its storage sink, so the middle and right columns overlap in real deployments. The lifecycle distinction still holds. DevUI is the only one of the three that lives in your inner loop, and the only one that lets you debug AI agents locally with execution control instead of post-hoc reading.

Takeaway: one job per tool. DevUI for “why is it wrong,” Foundry tracing for “what happened,” App Insights for “what is trending.” Teams that blur these end up with three dashboards and no answers.

Who this unblocks

The teams I expect to benefit most are the ones stalled between prototype and pilot because nobody can explain non-deterministic behavior to a stakeholder. “The agent is flaky” is not a status update anyone can act on. That stall pattern is common enough that I wrote about why most agent initiatives never become a portfolio, and inexplicability is a recurring cause. That is an industry observation from public discussion, not a statistic.

An illustrative scenario, clearly hypothetical: an agent intermittently skips a required validation tool before writing a record. In logs, every failing run looks like every passing run until the final step. In a local inspector, you run it ten times in a row, compare the runs where the tool fired against the runs where it did not, and notice the model only skips validation when a prior tool returns an empty result that your prompt never accounts for. That is one session of work instead of a week of log forensics. Your numbers vary; the point is the shape of the investigation, not the clock time.

Takeaway: inspectability turns “the agent is flaky” into a reproducible bug report, and reproducible bug reports are what let a pilot survive contact with a steering committee.

What is still missing

This is a public preview, and it behaves like one. Say so out loud before you standardize on it.

No multi-agent trace correlation is visible in the announcement or docs. Inspecting one run is not understanding drift across a thousand runs, and it is not following a request across a handoff between three agents. Microsoft has not announced that capability, and I will not invent a roadmap for them.

The mapping to Foundry’s evaluation pipeline is unclear. A local inspector helps you fix one run; evaluation tells you whether the fix regresses the other hundred cases you care about. Until those connect, DevUI findings feed your eval suite manually. If you are building toward a real pipeline, the AgentOps CI/CD reference architecture is where that outer loop lives.

And the standard preview tax applies: no SLA, breaking changes between releases, thin documentation that lags the code. Pin versions and read the repo, not blog posts, including this one.

Takeaway: adopt DevUI for the dev loop now, but do not retire your evaluation plans or your production tracing design. It replaces neither.

The AZ365 take: run your flakiest agent through Microsoft Agent Framework DevUI this week

Inspector-class tooling is becoming table stakes for agent frameworks the same way request tracing became table stakes for microservices. Five years from now, “we debugged agents from logs” will sound like “we debugged distributed systems from syslog.” Teams building agents blind in 2026 are not being scrappy; they are accumulating a backlog they cannot see.

Here is the week-one move:

What I am watching for next is whether Microsoft closes the two gaps that matter: multi-agent correlation across handoffs, and a direct line from an inspected run into the Foundry evaluation pipeline. Neither is announced. Both are the difference between a good inner-loop tool and a complete development story. The team that ships those first, Microsoft or otherwise, sets the bar every agent framework gets measured against.