Last week we mapped the Go agent-framework field and reached an uncomfortable conclusion for anyone shopping for one: in Go, the honest fourth option is no framework at all. Goroutines give you parallel tool-call fan-out, context.Context gives you one deadline that severs a whole run, and the core agent loop lands in about forty lines — so Eino, LangChainGo, and Genkit Go were things you adopted for orchestration or tracing, not because Go left a hole a Python framework fills.
One day after that piece ran, Microsoft dropped a first-party framework into the field. On July 10, 2026, Microsoft put Microsoft Agent Framework for Go into public preview — a Go implementation of the same framework already shipping for .NET and Python. If you skimmed nothing else: it's real, it's go get github.com/microsoft/agent-framework-go, it needs Go 1.25+, and it is emphatically preview.
What it is, in one screen#
Microsoft Agent Framework is Microsoft's merged successor to Semantic Kernel and AutoGen — the .NET/Python framework for building and orchestrating agents and multi-agent workflows. The Go SDK brings that same shape to Go developers building services, CLIs, workers, and cloud-native apps where Go is already the natural fit, so you no longer have to run a Python sidecar just to host an agent.
The Go preview covers the core surface:
- Agents — created through providers (e.g.
foundryprovider.NewAgent(...), configured with an endpoint and model via environment variables, then run witha.RunText(context.Background(), ...)). - Tools — function calling wired into the agent loop.
- Middleware — cross-cutting hooks around agent and tool calls.
- Workflows — multi-agent orchestration.
- Observability — tracing/telemetry hooks.
- Interoperability — integrations with the wider Microsoft agent ecosystem, including Azure AI Foundry.
That's enough to build and orchestrate an agent end-to-end in Go today.
What it is not yet#
This is the part a founder has to read before betting on it. As of the preview, the Go SDK trails .NET and Python:
- Declarative agents, RAG, CodeAct, and functional workflows are not yet implemented in Go.
- .NET still has broader product integrations and several features Go hasn't reached.
- The Go code is "evolving outside the core upstream codebase" — which means it moves faster and carries looser stability guarantees than the main framework. Pin your version and read the release notes before every upgrade.
So this is a preview in the literal sense: the skeleton and the happy path are there; the batteries that make the .NET SDK a production default are not all in the box yet.
Where it sits in the Go field#
Nothing about Microsoft's entry changes the underlying truth from last week's Go framework map: for a single model and a handful of tools, a hand-rolled loop is still the correct amount of code, because Go's runtime already gives you the concurrency and cancellation a framework exists to mediate. What Microsoft adds is a vendor-backed heavyweight to the list of reasons you'd adopt one anyway:
- Reach for Microsoft Agent Framework for Go if you're already invested in Azure AI Foundry and want first-party agents in the language your backend speaks — accepting preview-grade churn.
- Reach for Genkit Go if you want a stable 1.0 API and built-in OpenTelemetry tracing today. Notably, Genkit's Go support is ahead of its own Python (which is still Beta) — Go is not the afterthought here.
- Reach for Eino if your control flow is a genuine graph with branches, loops, and human-in-the-loop interrupts.
- Reach for no framework if your agent is a straight line. Still the default.
Why two clouds backing Go is the actual signal#
The agent-SDK conversation has been Python- and TypeScript-first, and OpenAI and Anthropic still lead there. Microsoft shipping a Go SDK — right alongside Google's Genkit Go, already 1.0 GA — is the two hyperscalers with the deepest cloud-native footprints saying the same thing: the language your infrastructure is already written in is now a first-class place to run agents. For a founder whose stack is Go, that removes the last easy excuse to bolt on a Python service. For everyone else, it's a reminder that "which agent framework" increasingly has a which language question underneath it — and the answer is no longer automatically Python.
The founder move this week: if you run Go and you're on Azure, go get the preview and prototype one agent against it — but keep the forty-line loop in your back pocket, because for most single-model agents it's still the honest answer. If you're not on Azure, Genkit Go is the more finished Go story today, and Eino is the pick when you need real graph orchestration.
