agent-sdk-go: a Go agent framework that leads with its own upgrade warning

The upgrade note is inside the feature list

The most important paragraph in the README is a blockquote in the middle of the capabilities section, addressed to people upgrading an existing deployment.

Two changes are named. The first is a removal: remote configuration loading is gone. The reason given is that the feature allowed the configuration service to execute local binaries, which is a remote code execution path by another name and should never have shipped.

The second is a set of fixes for features that were silently not working, and one is called out specifically. Input guardrails had no effect whenever memory was configured. That is the worst class of bug in a safety feature: the guardrail was present, the configuration said it was on, and the request path skipped it.

A migration document is linked for every behaviour change, removal and migration path.

Putting this in the feature list rather than in a changelog is the right call and worth copying in your own projects. A framework that removes a feature for security reasons has to say so where the people deciding whether to upgrade will read it, not in a file they have to go looking for.

Sessions, skills and memory consolidation are the recent block

Five capabilities are marked as new, and three of them are about what the agent remembers between conversations.

Session persistence provides durable conversations with scoped state, listing and resume, backed by in-memory storage, Postgres or SQLite. Three backends for the same feature is a deliberate choice, since an in-memory store is what you want for a test and Postgres is what you want in production.

Agent Skills load capability bundles from disk in the `SKILL.md` format, with what the README calls progressive disclosure so a large library stays cheap. Progressive disclosure is the mechanism that makes a hundred skills viable: the index is small, and a full document is only read when its description looks relevant.

Memory consolidation distils an idle conversation into durable facts. The details matter: merges, corrections and generalizations, and the results are proposed for review rather than silently written.

That last clause is the design decision in the feature. An agent that writes its own long-term memory without approval accumulates its own mistakes permanently, and a proposal step means a human or a rule decides what survives.

Prompt caching tells you which providers honour it

The fourth new feature is prompt caching, and the description is a complaint about other frameworks rather than a claim about this one.

It is described as capability-aware caching that tells you which providers honour it, instead of silently doing nothing.

Prompt caching is a provider-side feature with provider-specific semantics. Some vendors cache a prefix automatically and charge less for a cached one; others ignore a caching request entirely. A framework that exposes a caching toggle and reports success either way is worse than one that does not offer it, because you will tune a cost model against a number that never moved.

Reporting which providers actually honour the request turns caching from a hope into a measurement. It is the same instinct as the guardrail fix above: report what happened, not what was requested.

The token usage tracking feature sits next to this one, giving built-in counting for cost monitoring and usage analytics, which is the other half of making caching verifiable.

Hooks intercept every tool call, on every provider

Hooks and plugins are the other new enterprise feature, and the tool pipeline is its sibling.

Hooks let you intercept every tool call in order to audit it, deny it, rewrite it or redact it. They ship as named plugins, and the claim is that they reach all LLM providers.

Reaching every provider is the part that separates this from a feature bolted onto one integration. An interception point that only exists for one model vendor means an agent can route around it by switching models, which for a policy control is worse than having none, because the control appears to be in place.

The tool pipeline is described as one ordered decorator chain around every tool call, again reaching all providers without touching any. Ordered is the operative word: a chain has a sequence, so you can put redaction before the call and logging after it, and the order is part of the contract rather than an accident of registration.

Background runs sit alongside them, adding run identity, a live registry and cancellation by identifier, which is what you need in order to see work in flight and stop it. An agent framework without a cancel path has a reliability problem you will meet the first time something goes wrong.

Three install routes and a headless CLI

Prerequisites are Go 1.26 or newer, with Redis optional and only for distributed memory.

As a library it is one command:

go get github.com/Ingenimax/agent-sdk-go

As a command line tool there are three routes, and the prebuilt binaries from the releases page are the recommended one. The second is a Go install of the CLI package at its latest version:

go install github.com/Ingenimax/agent-sdk-go/cmd/agent-cli@latest

The third is building from source, which is two make targets: one to build the CLI binary and one to install it onto your system path.

The CLI is described as a headless SDK, and its workflow is short. Initialise the configuration, supply a key either through an environment variable or by copying the example file to a dotenv file, then either run a single query or start an interactive chat session.

Configuration beyond the key is minimal by design. The named variables are the provider key, a model identifier, a log level and a Redis address, with the example file carrying the full list.

Four data stores and two OpenAI client majors

The dependency list is longer than the feature list, and reading it tells you what has been wired up.

There are two OpenAI client libraries at two different major versions in the same module, which is what happens when a framework supports a v1-shaped and a v2-shaped API surface at once.

For data there is a Postgres driver, a Google Cloud storage client, a Weaviate client for one vector store and Supabase libraries, including a PostgREST client, for another. Redis appears alongside an in-process Redis double used in tests, which is a good sign: the memory backends are tested against something that behaves like the real thing without needing one.

The provider surface is broader than the three names in the README. Bedrock has a runtime client, Google's generative AI interface and gRPC are present, and OAuth and Google API clients sit alongside them.

Two protocol libraries are worth noting separately. The official Model Context Protocol Go SDK is a direct dependency, and an agent-to-agent protocol library is too, which is what the example directory named for that protocol is exercising.

OpenTelemetry appears in full, with the SDK, the tracer and two OTLP exporters, one over gRPC and one over HTTP, matching the observability claim.

A Makefile that installs to /usr/local/bin

The build file is conventional and slightly opinionated, which is worth noting because one target runs with elevated privileges.

The CLI build target changes into the CLI directory and builds a binary into a shared output directory. The full build depends on that and then builds three examples from the examples tree, so a build compiles sample programs as a side effect rather than only the shipped binary.

The install target copies the binary into the system binary directory using a copy command with elevated privileges, and prints a message telling you the command now works from anywhere. That is the target to read before running it on a shared machine or in a container.

The rest is standard: a clean target that removes the output directory, a test target, a lint target wired to a Go linter, a format target, a tidy target, a protobuf generation target that calls a script, a development setup target that calls another script, and a release target that depends on clean.

One entry in the tree is worth a question. There is a Ruby file sitting at the repository root next to a Go CLI, with no explanation in the README about what it is or whether anything runs it.

Nina is an MCP server about this SDK

The SDK ships its own documentation assistant, which is a small idea with a large convenience.

Nina is described as an AI assistant that knows the codebase. It is reached over MCP, so it is configured the same way as any other MCP server: a URL and a transport in your client's configuration file. Cursor's file and Claude Desktop's configuration both take the same entry, pointing at a hosted endpoint with server-sent events as the transport.

Three tools are exposed: one to ask questions about the SDK, Go programming or development in general, one to search the SDK documentation and source, and one to report the status of the assistant's knowledge base of the SDK.

That last tool is the interesting one. A documentation assistant's answers degrade quietly as the library changes, and a status endpoint that reports how fresh its index is gives you a way to notice when it has.

It is also a demonstration of the framework's own MCP support working on itself, which is a reasonable way to introduce the integration without writing a separate example.

Editorial conclusion

Use this if you want an agent framework in Go with sessions, evaluation and hook interception rather than a thin client over a model. Read the upgrade note before anything else, because a framework whose guardrails were inert when memory was configured has cost people trust, and the change that removes remote configuration loading will break deployments that relied on it. Pin a version, read the migration document, and check that your language version matches the Go 1.26 floor.

Frequently asked questions

Official sources

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