Microsoft's Agent Governance Toolkit is a serious piece of engineering. Sub-millisecond policy evaluation. OWASP Agentic Top 10 coverage across all ten risk categories, plus documented mapping support for the EU AI Act, NIST AI RMF 1.0, and SOC 2. Post-quantum cryptography already shipped. A 9,500+ test corpus with continuous fuzzing. If you've chosen AGT or are evaluating it, you made a defensible decision for the problem it actually solves.

AGT is precise about what it is and what it isn't. Its own documentation states: "This is not a prompt guardrail or content moderation tool. It governs agent actions, not LLM inputs/outputs." The same-process trust boundary is documented, not hidden. The non-goals are listed.

This post is for the team that has AGT in hand and is now asking: what do I still need to build? The answer is seven things. For each one, we'll walk through what a DIY approach looks like, what open-source tooling covers it, and where a hosted platform fits. None of these gaps are closed by Microsoft Agent 365 (GA May 1, 2026), either — Agent 365 operates at the tenant/fleet governance level (Purview, Entra ID, Defender), not at the developer-facing observability, cost-attribution, or durable-execution layer this post covers.

AGT's Explicit Non-Goals

Before cataloguing the gaps, it's worth being clear that these are documented design decisions, not omissions. From the AGT README:

• Not a prompt guardrail or content moderation tool

• Governs agent actions, not LLM inputs or outputs

• Same-process trust boundary; container isolation recommended for higher-risk workloads

• Workflow-level policies (evaluating sequences of calls rather than individual invocations) are on the roadmap but not yet available

• No tenancy model documented for memory, signing keys, or data residency

• No model cost table, no token aggregation, no per-user or per-tenant attribution (rate limiting exists, but that's a call-volume cap, not a cost ledger)

These aren't weaknesses — they're scope decisions. A policy engine that tried to be everything would be nothing. What follows is the list of things that scope leaves on your plate.

Gap 1 — Observability: Audit Logs Are Not Traces

What AGT ships: An audit log of policy events — which rule fired, at which stage of AGT's four-stage pipeline (pre_input → pre_tool → post_tool → pre_output), with what outcome. A flight recorder for post-mortem replay of a policy violation sequence.

What you need beyond that: Span-level distributed tracing. LLM call latency per turn. Token counts per model call. Tool call arguments and outputs. The full execution graph across spawned sub-agents. A queryable interface for debugging production incidents without trawling raw logs.

The difference matters in practice. A policy audit log tells you that Rule 14 blocked a write_file call at 14:23:07, and that AGT's post-tool stage sanitized the output of the call before it. It does not tell you what the agent had done for the 40 turns leading up to that call, which sub-agent spawned the offending run, what model was used at each step, or how many tokens the whole sequence consumed before halting.

Production agent failures rarely announce themselves through policy violations. Policy violations are rare by design — they're the catch, not the signal. The failures that actually hurt — cost overruns, reasoning regressions, emergent behavior that surprises you in a customer demo — don't trigger any rule. They only become visible in spans.

If you build it yourself: Instrument every LLM call with OpenTelemetry. Emit spans to your observability backend of choice. Build a frontend to query across runs. Estimate 3–6 engineer-weeks to a stable prototype; ongoing maintenance as your agent frameworks add new versions.

Open-source options: Langfuse (framework-agnostic, self-hostable, good default choice), Arize Phoenix (strong eval tooling), LangSmith (LangChain-coupled), Helicone (proxy-based, minimal instrumentation). All require some instrumentation; none provide a causal lineage graph across runs.

What a platform provides: pip install waxell-observe[all] auto-instruments 200+ libraries at process start — LangChain, CrewAI, AutoGen, the Anthropic SDK, the OpenAI SDK, and many others. Spans appear in a trace explorer immediately. No instrumentation code required.

Gap 2 — Cost Tracking and Attribution

What AGT ships: Per-agent, per-tool rate limiting — a cap on call volume. What it doesn't ship: a model cost table, token count aggregation, or billing-level attribution. This is documented, not a criticism, and rate limiting and cost tracking solve genuinely different problems.

What you need: Per-LLM-call cost records, keyed by model and token type. Aggregated by user, tenant, agent, and time window. If you run agents on behalf of customers — any SaaS product where agents do work for multiple tenants — cost attribution is the difference between knowing your margins and guessing until the invoice lands.

A concrete example: a finance agent runs 16 turns at roughly 7,000 tokens per turn on Claude Sonnet. That's ~112K tokens per session. At current pricing that's under a dollar. Fine. Now multiply by 10,000 sessions per day across 200 tenants. A rate limit will stop any single agent from calling a tool too often — it won't tell you which tenants are expensive, which workflows are runaway in dollar terms, or whether you're pricing correctly until the model provider bill arrives.

If you build it yourself: Intercept every LLM call response, log the usage field, join to a pricing table you maintain, aggregate by session and tenant. Easy to prototype, operationally annoying to maintain as model pricing changes and new models are added.

Open-source options: Helicone and Langfuse both track costs. Helicone is proxy-based (easy to add, adds a network hop); Langfuse requires SDK calls per LLM call. Neither provides a BudgetLedger primitive — a real-time, tree-scoped cost ledger that agents can query mid-run and that policy rules can read to make cost-aware enforcement decisions.

What a platform provides: SystemModelCost records every LLM call with tokens and cost. ModelCostOverride lets you map custom model endpoints to pricing. Pass a session_id and you get per-user, per-tenant attribution automatically. The BudgetLedger tracks spend across the full spawn tree in real time — a parent agent and all its children share one ledger that any node can read or enforce against.

Gap 3 — Multi-Tenancy Beyond Policy Units

What AGT ships: "Policies" as the organizational unit. No documented isolation model for tenant memory, tenant signing keys, or tenant data residency.

What you need if you're building SaaS: Customer A's agent must not read Customer B's episodic memory. Customer A's signed actions must not appear as Customer B's in an audit log. Customer A's data must stay in Customer A's schema. When a compliance auditor asks for evidence of tenant isolation, you need to produce it.

This isn't hypothetical. Any company running Waxell or a similar product on behalf of multiple customers faces this question. "We use row-level security" is an answer, but it's an answer you have to build, test, and maintain.

If you build it yourself: Postgres row-level security or schema-per-tenant, Redis namespace isolation per tenant, per-tenant key derivation in your signing layer. Solvable, but it's infrastructure work that pulls engineers away from agent work.

Open-source options: No off-the-shelf multi-tenant agent isolation library exists at time of writing.

What a platform provides: Schema-per-tenant isolation in Postgres, Redis namespace isolation, per-tenant AXID signing keys. The isolation model is enforced at the infrastructure layer — agents inherit it automatically rather than relying on application-level guards.

Gap 4 — Collaboration: Agents Need Somewhere to Send Results

What AGT ships: Agent Discovery (scan for unregistered agents), AgentMesh (workload identity for service-to-service communication). No inbox, no agent directory UI, no cross-device routing, no channels, no workspaces.

The operational gap: When an agent finishes a multi-step task, it needs somewhere to send the result. When a human needs to review a mid-run output before the agent proceeds, there needs to be a structured surface for that request to land. When the same logical agent runs on a developer's laptop and in CI and in a customer-facing tool, messages need to reach whichever session is active.

None of these are governance problems. They're product surfaces. And AGT doesn't claim to provide them — but someone has to.

If you build it yourself: A webhook receiver, a notification layer (Slack, email, or PagerDuty), a routing model that understands which agent session is currently active, and a UI for showing an agent's task history and pending approvals. Several weeks of work; ongoing maintenance as your agent infrastructure changes.

Open-source options: None that model an agent as a first-class message recipient with cross-device routing and first-to-claim inbox semantics.

What a platform provides: Connect gives each agent a ConnectAgentProfile — a stable slug, role, playbook, and capability list. Multiple API keys bind to one agent slug (ConnectAgentLinkedKey), so a laptop session, a CI runner, and a Cowork session all route to the same agent inbox. When a message arrives, the first active session to claim it wins; the others auto-skip. Channels and workspaces give teams a structured context layer around their agent fleet.

Gap 5 — Durable Execution: Suspend, Resume, Wait

What AGT ships: A saga orchestrator for multi-step action rollback. If Step 3 of a 5-step workflow fails, the saga can unwind Steps 1 and 2. This is valuable — it's the right answer for compensating transactions. But the saga runs within a single execution session. There is no mechanism to suspend an agent mid-run and resume it hours or days later.

The use cases that need this: An agent sends an invoice, then needs to wait up to 7 days for payment confirmation before taking the next action. An agent drafts a sensitive document, routes it to a human for approval, and resumes only after the human approves. A nightly batch workflow that processes queued items, sleeps until the next morning, processes again. A customer onboarding flow that sends a welcome email, waits 48 hours, checks whether the user has completed setup, and branches accordingly.

None of these are addressable with a saga orchestrator. A saga handles rollback within a session. These use cases require checkpointed state that survives session boundaries — and potentially worker crashes.

If you build it yourself: Celery beat or a similar task queue, Postgres checkpointing after each await step, a resume dispatcher that handles typed exceptions, idempotency handling for the "worker crashed mid-sleep" case. The infrastructure for durable execution without deterministic replay is non-trivial to get right.

Open-source options: Temporal (strong model, requires deterministic replay — significant adoption cost), Inngest (event-driven, not agent-native), LangGraph durable execution (tied to LangGraph), Cloudflare Workflows (infrastructure-coupled).

What a platform provides: ctx.sleep("30d"), ctx.ask_user(timeout="7d"), ctx.suspend(). The Envelope state machine checkpoints to Postgres after each await. Worker crash → automatic resume from the last checkpoint. No determinism requirement. You write normal Python; the framework handles the rest.

Gap 6 — External Agent Observability

What AGT ships: Instrumentation adapters for LangChain, CrewAI, AutoGen, and Google ADK, with native integration for Semantic Kernel and middleware support for LlamaIndex and OpenAI Agents SDK. Agents running inside those frameworks are observable through AGT's lens. Agents running outside them are not.

What's outside the lens: Claude Code running on a developer's laptop via the hooks interface. Claude Cowork sessions. MCP servers your team didn't write, running as independent processes. Any agent that was built before AGT adapters existed for its framework. Any future framework that hasn't been integrated yet.

Why this matters in practice: In most engineering teams, the same logical agent doesn't run in one place. A developer uses Claude Code on their laptop to write a pull request. The CI pipeline runs the same agent to review the diff. A customer support workflow routes to the same agent via a Cowork session. Without external agent observability, these look like three separate, unconnected execution contexts — you can't attribute cost across them, you can't trace a decision from the laptop session to the production run, and you can't apply consistent governance across the full surface.

If you build it yourself: Claude Code has a hooks interface — you can emit events from pre- and post-tool hooks. Writing, routing, and normalizing those events into the same observability backend as your framework agents is custom engineering, repeated for each external tool.

Open-source options: None that provide a unified external agent observability surface across Claude Code, Cowork, and arbitrary MCP servers.

What a platform provides: The Waxell installer drops a Claude Code hook key into ~/.waxell/config. Hooks emit structured events attributed to the same agent slug as the rest of your fleet. Cowork sessions and MCP stdio processes are covered under the same observability surface. All three contexts appear in one trace explorer under one agent identity.

Gap 7 — Causal Lineage

What AGT ships: An audit log. A sequential record of policy events at each pipeline stage. This is the right tool for answering "did this policy fire, and where in the pipeline?" It is not the right tool for answering "what caused this agent to take this action?"

The incident investigation problem: An agent produces an incorrect financial report. The compliance team wants to know: what spawned this agent? What data did it read in the run that preceded this one? What decision in a parent agent's run caused this child to be spawned with these parameters? What's the full causal chain from the user's original request to this output?

A sequential audit log can't answer those questions. It records events in order; it doesn't record causal relationships between runs. When Agent A spawns Agent B, which calls a tool that triggers Agent C across a different session boundary, the audit log has three separate event streams with no explicit link between them.

If you build it yourself: Propagate a parent run ID through every spawn call. Persist parent-child relationships in a separate table. Build a query layer over that table. Handle the edge cases: what about signal-triggered resumes? Cross-session bridges? Timer-fired continuations? A complete lineage model has more edge kinds than it first appears.

Open-source options: OpenTelemetry trace propagation covers span-level parent-child relationships but not run-level causal graphs. No open-source tool provides a complete causal lineage model for multi-agent systems at time of writing.

What a platform provides: The RunEdge DAG links every AgentExecutionRun to its causal predecessors via typed edge records: user_start, spawn, signal_fire, domain_callback, resume, timer_fire, ctx_ask_user, retry, cross_session_bridge. The trace explorer renders the full causal graph as a browsable DAG. An incident that traces back through four spawn levels across three sessions is navigable in the UI in under a minute.

The Checklist

If you have AGT and are planning the rest of your stack:

Most teams tackle these gaps in roughly this order: observability first (it pays off immediately), cost second (visibility into what you're spending), durable execution third (unlocks the use cases that justify agent infrastructure). Tenancy, lineage, and external observability often come later — but they're worth planning for early, because retrofitting them into an existing fleet is significantly harder than building them in from the start.

FAQ

Is AGT sufficient on its own for production agent governance?
For most production teams, no. AGT covers policy enforcement well at the tool-call boundary — a documented four-stage pipeline that evaluates before a call, before dispatch, and sanitizes the call's output afterward. That's a real and useful enforcement surface, but it's scoped to a single call's lifecycle. The failures that actually hurt in production — runaway cost mid-spawn-tree, data leakage through retrieval paths that never pass through a tool-output sanitization step, workflows that need mid-run human review lasting hours or days, reasoning failures that don't trigger any policy rule — aren't addressable within a per-call pipeline alone. See the full comparison for the complete breakdown.

Can I add Waxell Observe to an existing AGT deployment without changing my agent code?
Yes. pip install waxell-observe[all] and call waxell.init() at process start. The SDK auto-instruments your agent frameworks. No manual span instrumentation required for the frameworks in the supported library list.

What's the minimum I need from a platform if I already have AGT?
Depends on your most pressing gap. If cost tracking is the first thing keeping you up at night, start with Waxell Observe — it requires no code changes. If you need agents that can pause for human approval, start with Waxell Runtime. If you need a unified view across Claude Code and production, start with the Waxell installer. You don't have to take all seven gaps at once.

Does Microsoft Agent 365 close any of these gaps?
Not the ones in this post. Agent 365 (GA May 1, 2026) is a tenant-level governance layer — Purview, Entra ID, and Defender unified for fleet-wide agent oversight. It's a real and useful addition to Microsoft's governance stack, but it's aimed at IT/security administration across an organization's agents, not at the developer-facing gaps covered here: span-level tracing, per-call cost attribution, multi-tenant SaaS isolation, agent-to-agent collaboration surfaces, durable execution, external agent observability, or run-level causal lineage. If you're running AGT and Agent 365 together, you'd still be building or buying solutions for all seven gaps above.

Why can't I just use a standard observability platform — Datadog, Grafana, New Relic?
You can. Standard observability platforms handle infrastructure metrics and application traces well. They don't have concepts for LLM token cost, agent spawn trees, mid-run human approval gates, or causal lineage across agent sessions. You'd be building those abstractions on top of a generic platform. That's a valid choice; it's also a significant engineering investment.

Is this list complete?
Probably not. Agent infrastructure is moving fast. The seven gaps above are the ones that consistently surface in production deployments today. Security-specific gaps (memory poisoning, prompt injection in tool responses, cross-tenant data leakage) are a separate layer that both AGT and Waxell address partially but that deserves its own treatment.

Waxell is the hosted platform for running, observing, and governing AI agents. See the platform overview or read the full Waxell vs. AGT comparison.

Sources

• Microsoft Agent Governance Toolkit — GitHub — primary source for AGT scope, non-goals, and documented boundaries

• Introducing the Agent Governance Toolkit — Microsoft Open Source Blog, April 2, 2026

• OWASP Agentic Top 10

• Claude Code Hooks Reference — Anthropic

• Langfuse — Open-source LLM observability

• Temporal — Durable execution platform

• Inngest — Event-driven durable functions