# Microsoft Agent Framework for Go: a preview SDK for graph-based multi-agent workflows

> The Go implementation of Microsoft Agent Framework packs agents, middleware, graph workflows and OpenTelemetry into one MIT-licensed module, but it is in public preview and several MAF features are not implemented yet in Go.

**microsoft/agent-framework-go** — A framework for building, orchestrating and deploying AI agents and multi-agent workflows with support for Go.

- Repository: https://github.com/microsoft/agent-framework-go
- Website: https://aka.ms/agent-framework
- Stars: 634 · Forks: 60
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-agent-framework-go

## What microsoft/agent-framework-go solves, and who it is aimed at

Most Go code that talks to a model starts as a single function: build a prompt, call an API, print the text. That shape stops working once the task needs more than one model call in a fixed order, a tool that must be approved before it runs, or a run that has to resume after a process restart. Microsoft Agent Framework for Go is aimed at that second stage. The README frames it as an "open, multi-language framework for building production-grade AI agents and multi-agent workflows", and this repository is the Go implementation, with samples and documentation.

The intended audience is stated fairly plainly. The project lists the cases it fits: agents and workflows you expect to run in production, orchestration beyond a single prompt or stateless chat loop, graph patterns such as sequential, concurrent, group collaboration and custom routing, and interest in checkpointing, restartability, observability, governance or human-in-the-loop control. The last bullet is provider flexibility, so the architecture can change without a rewrite. If your Go service only needs one prompt and one response, this is more machinery than the problem requires.

The provider list in the README is broad: Microsoft Foundry, Azure OpenAI, OpenAI, Model Context Protocol, Agent2Agent, AG-UI and the GitHub Copilot SDK. The go.mod file backs that up with direct dependencies on the Azure identity and core SDKs, the OpenAI Go client, the Anthropic SDK, the MCP Go SDK, the A2A Go module, the AG-UI community Go SDK, the GitHub Copilot SDK and Google's genai package. That dependency set is the clearest signal of what the framework actually speaks to.

## Agents, middleware and graph workflows: the mechanism in this repository

The repository layout separates concerns into top-level directories: agent/, message/, provider/, tool/, workflow/, cmd/ and internal/. The agent/ directory holds the agent abstraction plus middleware.go and a harness/ subdirectory. The provider/ directory holds provider packages, including foundryprovider/ and otelprovider/. The workflow/ directory holds the orchestration code, with an observability/opentelemetry/ subdirectory for tracing workflow runs.

The data flow implied by that split is conventional and readable. Messages are typed in message/, tools live in tool/, providers adapt external model services to the framework's agent interface, and workflows compose agents into a graph. Middleware sits between the caller and the provider call, which is where request and response processing, logging, OpenTelemetry, context providers, tool approval and automatic tool calling are handled according to the README. Tool approval as middleware is the interesting choice: it means a human-in-the-loop gate is expressed as a wrapper around the tool call rather than as a special workflow node type.

The workflow package is the part that distinguishes this from a thin provider wrapper. The README describes graph-based workflows with sequential, concurrent, group collaboration, conditional routing, subworkflows, checkpointing, streaming, human-in-the-loop and time-travel patterns. Checkpointing is what makes restartability concrete: a run that fails partway can resume from a recorded point instead of replaying every model call. Time-travel patterns go further and let you re-enter a run at an earlier state. Neither is trivial to build correctly, and both are the kind of thing you would otherwise write yourself and get wrong.

The honest caveat is in the same section of the README: handoff orchestration is not implemented yet in the Go SDK. Handoff, where one agent passes control to another, is a common multi-agent pattern, so its absence shapes which designs are practical here today.

## Installing the Go SDK and running a first agent

The README gives one installation step. The module path is the repository path, and the current release is v0.1.0.

```bash
go get github.com/microsoft/agent-framework-go
```

After that command, the module appears in your go.mod. The repository's own go.mod declares go 1.26.0, so check that against the Go toolchain you have installed before you start; the README does not document a minimum Go version separately from that file.

The quickstart in the README is a basic agent that writes a haiku about the framework, and it begins as a normal Go program. The listing in the README is truncated at the imports, but the shape is visible.

```go
package main

import (
	"cmp"
	"context"
```

The README does not publish the full body of that sample in the text available here, so the practical next step is the examples tree rather than the README snippet. The repository ships examples/01-get-started/, examples/02-agents/ with a providers/ subdirectory, examples/03-workflows/, examples/05-end-to-end/ and examples/demos/. For a first real use, run one of the provider examples under examples/02-agents/providers/ that matches your model host, since those are the files that show credential wiring end to end.

Credentials are the part most likely to bite. The README's troubleshooting section has subsections for Authentication and Environment Variables, which means the framework expects environment-based configuration rather than hard-coded keys. It does not spell out the variable names in the text available here, so read those two subsections before running anything against a live endpoint.

## Where the Go SDK is thinner than .NET, and why that matters

Microsoft Agent Framework exists in three languages, and this repository is explicit that Go trails the others. The README points to a .NET and Go SDK feature comparison document and summarises it: the Go SDK covers core agents, tools, middleware, workflows, observability and interoperability integrations, while .NET currently has broader product integrations and several features not implemented yet in Go. That is a usefully blunt statement, and it is the single most important thing to read before choosing a language for a new agent service.

The not-implemented list is longer than a footnote. Declarative agents, AF Labs and DevUI are all marked as not implemented yet in the Go SDK. Foundry-hosted deployment is not implemented yet either, which means you can build project-backed Foundry agents and invoke existing server-side Foundry agents, but the README does not claim you can deploy a Foundry-hosted agent from Go. Handoff orchestration, as noted, is also missing.

The preview status compounds this. The README states the Go implementation is in public preview and is "currently evolving outside the core upstream codebase", with closer alignment to the broader MAF ecosystem expected as adoption and feedback grow. Read that as a warning about API stability, not a marketing line. A module at v0.1.0 that describes itself as evolving outside the main repository is one where a minor release can move things.

There is a second consideration that has nothing to do with features. The README has a Telemetry and data collection subsection. Whatever it says applies to your deployment, and it belongs on the checklist before this SDK goes into a regulated environment.

## Choosing between agent-framework-go and a lighter Go agent library

The realistic alternative is not another Microsoft product. It is a smaller, single-purpose Go library for model calls and tool loops, of which several exist in the Go ecosystem, or simply the provider SDKs directly. The go.mod here already pulls in the OpenAI Go client, the Anthropic SDK and Google's genai package, so the provider layer is not doing anything you could not do yourself.

The difference is what sits above the provider call. With a thin library you write your own loop, your own retry and resume logic, your own tracing spans and your own tool approval gate. That is fine for one agent and one tool. It becomes a liability when you need a concurrent fan-out across several agents with conditional routing and a checkpoint you can resume from, because you are now maintaining an orchestration engine that nobody asked you to write. Microsoft Agent Framework for Go's value proposition is that those patterns are already in workflow/, with OpenTelemetry wired through provider/otelprovider/ and workflow/observability/opentelemetry/ rather than bolted on.

The trade is control for structure. A thin library lets you shape every call and keeps your dependency graph small. This framework brings a sizeable transitive dependency set, including Azure identity, gRPC, OpenTelemetry and several vendor SDKs, and asks you to accept its agent and workflow abstractions. If your service is one agent with two tools, the abstractions will cost more than they return. If you are building the orchestration layer anyway, the comparison document and the workflow examples are the right place to judge whether the framework's version of it matches yours.

## Licence, maintenance and what upgrades will cost you

The repository is MIT licensed, and the LICENSE file sits at the top level alongside CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md, SUPPORT.md and TRANSPARENCY_FAQ.md. MIT is permissive: it allows commercial use, modification and redistribution with the licence text retained. It offers no patent grant, which is a difference from some other permissive licences, and it is not a copyleft licence. That is a description of the terms, not legal advice; if the dependency set or the patent question matters to your organisation, have counsel read the LICENSE file rather than this article.

The dependency set is the real licence exposure. The go.mod file lists direct requirements on Azure SDKs, the OpenAI Go client, the Anthropic SDK, the MCP Go SDK, the A2A Go module, the AG-UI community Go SDK, the GitHub Copilot SDK, Google's genai and gRPC, plus a long indirect list. Each carries its own licence, and none of that is covered by this repository's MIT file. A licence scan of the full module graph is the only way to know what you are shipping.

Maintenance is where the dates matter. The repository is not archived, and the last push was on 2026-09-10. The only listed release is v0.1.0, dated 2026-09-01. So this is a young module with a single tagged release and no published upgrade path. The README does not document a migration guide, a deprecation policy or a versioning commitment. Budget for reading the diff on every bump, and for the possibility that a preview release changes an interface you depend on.

## Conclusion

Adopt microsoft/agent-framework-go if you are writing Go services that need graph-based orchestration, checkpointing, middleware and OpenTelemetry tracing, and you can absorb preview churn in a v0.1.0 module. Do not adopt it if you need handoff orchestration, declarative agents, DevUI or Foundry-hosted deployment, which the README lists as not implemented yet in the Go SDK, or if you need a stable API contract today. Before committing, verify the go.mod Go version against your toolchain, confirm which provider package matches your model host, and check the .NET and Go SDK feature comparison document for the specific capability you depend on.

## FAQ

### What is the Microsoft Agent Framework?

According to the README, it is an open, multi-language framework for building production-grade AI agents and multi-agent workflows. This repository contains the Go implementation, while the .NET and Python implementations live in the upstream Microsoft Agent Framework repository.

### How do I install Microsoft Agent Framework for Go?

The README gives a single command, go get github.com/microsoft/agent-framework-go, which adds the module to your go.mod. The repository's own go.mod declares go 1.26.0, so check that against your toolchain.

### Does microsoft/agent-framework-go support multi-agent workflows?

Yes. The README describes graph-based workflows with sequential, concurrent, group collaboration, conditional routing, subworkflows, checkpointing, streaming, human-in-the-loop and time-travel patterns. Handoff orchestration is listed as not implemented yet in the Go SDK.

### Is Microsoft Agent Framework for Go production ready?

The README states the Go implementation is in public preview and is evolving outside the core upstream codebase. The only listed release is v0.1.0, dated 2026-09-01, and the README does not document a migration or deprecation policy.

### Which model providers does the Go SDK support?

The README lists Microsoft Foundry, Azure OpenAI, OpenAI, Model Context Protocol, Agent2Agent, AG-UI and the GitHub Copilot SDK, with more being added. Provider examples live under examples/02-agents/providers/ and provider packages under provider/.

## Sources

- [License: MIT](https://github.com/microsoft/agent-framework-go/blob/main/LICENSE)
- [microsoft/agent-framework-go on GitHub](https://github.com/microsoft/agent-framework-go)
- [Project website](https://aka.ms/agent-framework)
- [README](https://github.com/microsoft/agent-framework-go/blob/main/README.md)
- [Releases](https://github.com/microsoft/agent-framework-go/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-agent-framework-go