Go agent framework packs LLMs, tools, and multi-tenancy into one kit

What it does

agent-sdk-go is a Go framework for constructing AI agents. It wraps multiple LLM providers (OpenAI, Anthropic, Google Vertex AI), tool registries, memory backends, and MCP server connections into a single library with a CLI counterpart. The SDK leans heavily on configuration-over-code: you can define agents, sub-agents, tools, and memory stores in YAML files with environment variable expansion, then load them directly into the runtime.

The interesting bit

The project treats agent definitions more like infrastructure manifests than code. You can declare sub-agents, hook in MCP servers over stdio or HTTP, and switch memory between in-process buffers and Redis from a single YAML file. It also ships with “Nina,” an MCP server that knows the SDK’s own codebase and plugs into Cursor or Claude Desktop to answer questions about itself—an unusual bit of recursive dogfooding.

Key highlights

• Supports OpenAI, Anthropic, and Google Vertex AI (Gemini) with swappable LLM clients.
• Declarative YAML configuration for agents, sub-agents, tools, MCP servers, and memory backends.
• Context-aware multi-tenancy (WithOrgID) and built-in tracing/logging for observability.
• Token usage tracking with cost estimation for Anthropic, OpenAI, and Azure OpenAI.
• MCP integration for external tools via HTTP or stdio, plus a dedicated helper MCP server (“Nina”).

Caveats

• Local models via Ollama or vLLM return Usage=nil, so token tracking and cost estimation don’t apply.
• Features like auto-generating agent configs from system prompts and vector-based memory retrieval are advertised but not demonstrated in the visible documentation, leaving their mechanics unclear.
• Enterprise guardrails and structured plan-approval workflows are listed as features but lack visible implementation detail in the README.

Verdict

Worth a look if you are building agentic services in Go and want opinionated scaffolding for memory, tenancy, and tool calling. Skip it if you prefer lightweight LLM wrappers or are already committed to Python’s ecosystem.