Microsoft Agent Framework for Go: What the Go SDK Actually Implements

The gap this fills for Go teams building agents

Most agent tooling assumes Python or .NET. A Go service that wants an agent loop either shells out to another runtime or hand-rolls the orchestration: tool dispatch, retries, state between turns, tracing. Microsoft Agent Framework for Go is the Go implementation of a multi-language framework, and its stated audience is teams taking agents from prototype to production. The README lists the fit conditions directly: orchestration beyond a single prompt or stateless chat loop, graph patterns such as sequential, concurrent and group collaboration, and interest in checkpointing, restartability, observability, governance or human-in-the-loop control. That list is the honest scope statement. If your agent is one prompt and one response, this framework is more machinery than the problem needs. If your agent is a graph of steps that must survive a process restart, the framework is aimed at exactly that.

Agents, middleware and graph workflows as the three layers

The repository layout separates three concerns. Agents live under agent/, with middleware in agent/middleware.go and a harness under agent/harness/. Middleware handles request and response processing, logging, OpenTelemetry, context providers, tool approval and automatic tool calling. Workflows live under workflow/, and the README describes them as graph-based, supporting sequential, concurrent, group collaboration, conditional routing, subworkflows, checkpointing, streaming, human-in-the-loop and time-travel patterns. Providers sit in provider/, with separate packages for Foundry and OpenTelemetry, and examples under examples/02-agents/providers/. The data flow implied by that structure: an agent is constructed against a provider, middleware wraps the request and response path, tools are dispatched through the automatic tool calling path, and a workflow composes agents into a graph whose state can be checkpointed. The README does not spell out the checkpoint storage interface, so treat that as something to read in the package documentation before designing around it.

Installing it and the environment it expects

Installation is one command: go get github.com/microsoft/agent-framework-go. The quickstart in the README creates a Microsoft Foundry agent that writes a haiku about the framework, and the sample imports cmp and context alongside the framework packages. The README also has a troubleshooting section with subsections for Authentication and Environment Variables, which tells you credentials are configured through the environment rather than passed as constructor arguments in the basic case. Check the Troubleshooting section of the repository README before wiring credentials into a deployment. Provider-specific examples live under examples/02-agents/providers/, including a foundry/ subdirectory, and the Foundry provider package is provider/foundryprovider/. The README notes Foundry support covers project-backed agents, invoking existing server-side Foundry agents, passing Foundry client headers, capturing served-model metadata and Foundry memory.

Preview status and the features the Go SDK does not have

This is the section that decides adoption. The README states the Go implementation is in public preview and is evolving outside the core upstream codebase, with closer alignment to the broader MAF ecosystem expected as adoption and feedback grow. That is a maintenance signal, not a stability guarantee. More concretely, the README marks several capabilities as not implemented yet in the Go SDK: handoff orchestration, declarative agents, AF Labs, DevUI, and Foundry-hosted deployment. The README also says .NET currently has broader product integrations and several features not implemented in Go, and points to docs/dotnet-go-sdk-feature-comparison.md for the detail. So the practical failure mode is a team reading the multi-language marketing page, assuming feature parity, and discovering mid-project that the orchestration pattern they designed around (handoff, for instance) has no Go implementation. The version number reinforces the point: v0.1.0, released 2026-09-01. There is no long upgrade history to reason about yet.

Where it sits against the .NET and Python implementations

The obvious alternative is the upstream Microsoft Agent Framework repository, which hosts the .NET and Python implementations. The difference is not philosophical, it is coverage. Same framework name, same orchestration vocabulary (sequential, concurrent, group collaboration, checkpointing), but the .NET side is where declarative agents, DevUI, AF Labs, handoff orchestration and Foundry-hosted deployment exist today, according to the README's own not-implemented list for Go. Choosing Go here means accepting a narrower surface in exchange for staying inside a Go service and its build and deployment tooling. If you are not constrained to Go, the upstream implementations are the more complete path. If you are constrained to Go, the real comparison is against building the orchestration yourself, and the framework's value is the middleware, checkpointing and OpenTelemetry wiring you would otherwise write and maintain.

Licence, maintenance and upgrade cost

The repository is MIT licensed, which permits commercial use and modification with the licence and copyright notice retained. That is a permissive baseline. The maintenance question is harder. The project is at v0.1.0 and the README describes it as evolving outside the core upstream codebase, with alignment to the MAF ecosystem expected to tighten over time. Read that as: APIs can move, and the eventual convergence with upstream may itself be an upgrade event. The README's .NET-to-Go feature comparison document is the artifact that will change most often, and it is the file to re-read before each dependency bump. Because the module is consumed through go get github.com/microsoft/agent-framework-go, pinning a version in go.mod is the mechanism that keeps an upgrade from arriving unannounced. None of this is legal advice; the MIT text governs.

Who should start now and who should wait

Start now if you are writing Go services, you need graph workflows with conditional routing and checkpointing, and you want OpenTelemetry tracing without building it yourself. The provider packages and the examples directory give you a path to a first working agent, and the middleware layer is where the framework earns its place. Wait if your design assumes handoff orchestration, declarative agents, a DevUI for inspection, or deployment hosted inside Foundry, since the README states those are not implemented in the Go SDK. Also wait if you need a stable API contract today; v0.1.0 plus public preview plus a stated intent to realign with upstream is three separate reasons to expect churn. The first thing to verify is not the quickstart. It is docs/dotnet-go-sdk-feature-comparison.md against your own feature list, followed by the provider/ tree to confirm a provider package exists for the endpoint you actually call.

Editorial conclusion

Adopt it if your agents are written in Go and you need graph workflows with checkpointing, restartability and OpenTelemetry tracing rather than a single prompt loop. Do not adopt it if you depend on handoff orchestration, declarative agents, DevUI or Foundry-hosted deployment, because the README states these are not implemented in the Go SDK. Before committing, read docs/dotnet-go-sdk-feature-comparison.md and confirm which provider packages under provider/ exist for your model endpoint.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/agent-framework-go on GitHub
3. Project website
4. README
5. Releases