Three Things, Tested Three Ways

The confusion comes from treating “the LLM feature” as one indivisible thing. It is three:

The first row is 90% of your code and needs no model at all. Get that boundary right and the rest is manageable.

Put an Interface in Front of the Model

Do not scatter client.Messages.New through your handlers. Define the narrowest interface your code actually needs and depend on that:

// Completer turns a prompt into text. It is deliberately narrow — narrower
// than the SDK — so tests can implement it in five lines.
type Completer interface {
    Complete(ctx context.Context, req Request) (Response, error)
}

type Request struct {
    System   string
    Messages []Message
    Tools    []Tool
}

type Response struct {
    Text       string
    ToolCalls  []ToolCall
    StopReason string
    Usage      Usage
}

This is just the dependency-inversion habit that makes any external service testable, and it earns its keep faster here than almost anywhere else. Two things fall out of it:

Your business logic never imports the SDK. It imports your Request and Response types. When the SDK’s union types change shape, one adapter file changes.

The fake is trivial. No HTTP, no fixtures, no mocking library:

type fakeCompleter struct {
    responses []Response
    err       error
    calls     []Request // recorded for assertions
}

func (f *fakeCompleter) Complete(_ context.Context, req Request) (Response, error) {
    f.calls = append(f.calls, req)
    if f.err != nil {
        return Response{}, f.err
    }
    if len(f.responses) == 0 {
        return Response{}, errors.New("fakeCompleter: no responses left")
    }
    resp := f.responses[0]
    f.responses = f.responses[1:]
    return resp, nil
}

Returning a queue rather than a single value is what lets you test multi-turn loops: the first call returns a tool request, the second returns the final answer.

Test the Loop, Not the Model

An agent loop has plenty of logic worth testing, none of which needs a model. Does it stop when it should? Does it return a result for every tool call? Does it hand a tool failure back rather than aborting?

func TestLoopReturnsResultForFailedTool(t *testing.T) {
    fake := &fakeCompleter{responses: []Response{
        {StopReason: "tool_use", ToolCalls: []ToolCall{
            {ID: "t1", Name: "lookup", Input: []byte(`{"id":"missing"}`)},
        }},
        {StopReason: "end_turn", Text: "I couldn't find that record."},
    }}

    agent := New(fake, map[string]ToolFunc{
        "lookup": func(context.Context, []byte) (string, error) {
            return "", errors.New("not found")
        },
    })

    got, err := agent.Run(context.Background(), "look up record missing")
    if err != nil {
        t.Fatalf("Run() error = %v, want nil", err)
    }
    if got != "I couldn't find that record." {
        t.Errorf("got %q", got)
    }

    // The failure must reach the model as a tool result, not abort the loop.
    second := fake.calls[1]
    result := findToolResult(t, second, "t1")
    if !result.IsError {
        t.Error("tool failure was not marked as an error result")
    }
}

That test catches a real bug — a loop that drops the failed call instead of reporting it — and runs in microseconds with no API key.

The same approach covers the rest of the loop’s contract — the invariants from the agent-loop article: that it stops at MaxIterations, that every tool_use block gets exactly one result, that results come back in one message. Table-driven tests fit this beautifully, since each case is just a different queue of canned responses.

Golden Files for Prompt Assembly

Prompt building is string manipulation, and it drifts. Someone adds a field, reorders a section, changes a heading — and unlike code, a prompt regression produces no compile error and no failing assertion, just slightly worse output that nobody attributes to the change.

Golden files make the diff visible in review:

var update = flag.Bool("update", false, "update golden files")

func TestBuildSystemPrompt(t *testing.T) {
    tests := []struct {
        name   string
        cfg    Config
        golden string
    }{
        {"default", Config{}, "system_default.txt"},
        {"with_tools", Config{Tools: allTools}, "system_with_tools.txt"},
        {"terse_mode", Config{Terse: true}, "system_terse.txt"},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := BuildSystemPrompt(tt.cfg)
            path := filepath.Join("testdata", tt.golden)

            if *update {
                if err := os.WriteFile(path, []byte(got), 0o644); err != nil {
                    t.Fatal(err)
                }
                return
            }

            want, err := os.ReadFile(path)
            if err != nil {
                t.Fatal(err)
            }
            if diff := cmp.Diff(string(want), got); diff != "" {
                t.Errorf("prompt changed (-want +got):\n%s", diff)
            }
        })
    }
}

Run go test ./... -update to accept a change deliberately. The point is not that the golden file is correct — it is that changing it requires saying so out loud, in a diff a reviewer can read.

This also catches the caching bugs from the prompt caching article before they cost you anything. A golden test on the system prompt fails the moment somebody interpolates time.Now() into it, because the output differs on every run.

Which suggests a second, blunter test worth having:

func TestPromptAssemblyIsDeterministic(t *testing.T) {
    // Go randomises map iteration order, so a prompt built by ranging over a
    // map differs run to run — and silently never caches.
    first := BuildSystemPrompt(cfg)
    for i := 0; i < 20; i++ {
        if got := BuildSystemPrompt(cfg); got != first {
            t.Fatalf("prompt is not deterministic on run %d", i)
        }
    }
}

Twenty iterations is enough to make a randomised map order fail essentially every time.

Integration Tests, Behind a Build Tag

You do need a handful of tests that touch the real API — enough to catch an SDK upgrade that changed a union type, a model id that no longer resolves, or streaming that broke. But they cost money and need a key, so they must not run on every go test ./...:

//go:build integration

package llm_test

func TestStreamingReturnsCompleteMessage(t *testing.T) {
    if os.Getenv("ANTHROPIC_API_KEY") == "" {
        t.Skip("no API key; skipping integration test")
    }
    // ... real call, assert on shape rather than content
}

go test ./...                    # fast, free, no key
go test -tags=integration ./...  # the real thing, on demand

Assert on shape, never on wording. resp.Text being non-empty, StopReason being end_turn, Usage.OutputTokens being greater than zero, a streamed message accumulating to the same content as a non-streamed one. Those hold across model versions. “The answer contains the word Paris” does not, and a flaky test that fails once a month teaches your team to ignore failures.

There is a middle option that gets you a long way for free: point the SDK at a local httptest.Server via the ANTHROPIC_BASE_URL environment variable and serve canned JSON. That exercises the real SDK — its parsing, its retry behaviour, its streaming decoder — without a key or a bill. It is the closest analogue to what go-sqlmock does for the database layer: a real driver, a fake server.

It is also the only sane way to test the paths you cannot easily provoke on purpose:

// Rate limiting: does the caller back off, or hammer?
mux.HandleFunc("/v1/messages", func(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Retry-After", "1")
    w.WriteHeader(http.StatusTooManyRequests)
    fmt.Fprint(w, `{"type":"error","error":{"type":"rate_limit_error","message":"..."}}`)
})

Do the same for a 500, a connection dropped mid-stream, and a malformed body. Those are the failures that actually page you, and they are trivial to simulate and nearly impossible to trigger on demand against the real API.

The Refusal Case Nobody Tests

Worth its own paragraph because it is so easy to miss: a safety refusal comes back as HTTP 200 with StopReason set to refusal. Your error handling never fires. Code that goes from if err != nil straight to reading the first content block treats it as an empty answer.

func TestRefusalIsNotTreatedAsEmptyAnswer(t *testing.T) {
    fake := &fakeCompleter{responses: []Response{
        {StopReason: "refusal", Text: ""},
    }}

    _, err := New(fake, nil).Run(context.Background(), "...")
    if !errors.Is(err, ErrDeclined) {
        t.Errorf("got %v, want ErrDeclined", err)
    }
}

One line in the fake, and you have covered a branch most production code does not have at all. The sentinel-error pattern behind ErrDeclined is the one from error handling in Go.

Evals: For Quality, Not Correctness

Everything above tests whether your code is right. None of it tells you whether the answers are any good. That needs a different instrument, and the mistake is trying to force it into go test.

An eval is a fixed set of inputs, run against the real model, scored rather than asserted:

//go:build eval

func TestClassificationAccuracy(t *testing.T) {
    cases := loadEvalCases(t, "testdata/eval/classification.jsonl")

    var correct int
    for _, c := range cases {
        got, err := classify(context.Background(), realClient, c.Input)
        if err != nil {
            t.Fatal(err)
        }
        if got == c.Want {
            correct++
        } else {
            t.Logf("MISS: input=%q got=%q want=%q", c.Input, got, c.Want)
        }
    }

    accuracy := float64(correct) / float64(len(cases))
    t.Logf("accuracy: %.1f%% (%d/%d)", accuracy*100, correct, len(cases))

    // A floor, not an equality check. Below this, something regressed.
    if accuracy < 0.90 {
        t.Errorf("accuracy %.1f%% below the 90%% floor", accuracy*100)
    }
}

Two things make this useful rather than annoying. The threshold is a floor, not a target — you are detecting regression, not demanding perfection. And the misses get logged, because the list of what it got wrong is the actual output; the pass/fail is almost incidental.

Run evals when you change a prompt, a model, or an effort setting — not on every commit. They cost money and take minutes.

What Not to Do

Do not assert on model wording. strings.Contains(resp, "Paris") passes today and fails after a model update that phrases it differently. It is not testing your code.

Do not set temperature to zero and call it deterministic. Sampling parameters are not even accepted on current models, and identical output was never guaranteed regardless.

Do not mock the SDK’s types. Mocking anthropic.Message and its union blocks is a lot of work to test the adapter you wrote to avoid exactly that. Fake your own interface instead.

Do not let integration tests run by default. A test suite that needs an API key is a test suite that new contributors cannot run, and CI cost that grows with every push.

Do not skip testing the error paths because they are “just the SDK’s job”. Rate limits, refusals and mid-stream disconnects are the failures you will actually see in production, and they are the cheapest things in this article to cover.

Checklist

• A narrow interface between your logic and the SDK; business code never imports the SDK.
• A fake with a queue of canned responses for multi-turn loops.
• Unit tests for the loop’s contract: one result per tool call, errors handed back, iteration cap honoured.
• Golden files for prompt assembly, plus a determinism test.
• Integration tests behind //go:build integration, asserting on shape not wording.
• An httptest.Server for 429s, 500s and truncated streams.
• A test for the refusal path.
• Evals behind their own tag, scored against a floor, misses logged.

Conclusion

“You cannot test LLM code” conflates the model with the code around it. The code around it — the prompt builder, the parser, the loop, the tool handlers, the error branches — is ordinary Go, and it becomes easy to test the moment there is an interface between it and the SDK. Push non-determinism out to the edges, cover the edges with evals scored against a floor, and the rest of your suite stays fast, free and green.

The Loop, In Full

Here is a complete manual loop. It is worth reading once even if you end up using the SDK’s runner, because everything that goes wrong later is easier to diagnose when you know this shape. It assumes you already have a client and know how to read a response — if not, start with calling an LLM from Go.

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"

    "github.com/anthropics/anthropic-sdk-go"
)

func main() {
    client := anthropic.NewClient()

    addTool := anthropic.ToolParam{
        Name:        "add",
        Description: anthropic.String("Add two integers"),
        InputSchema: anthropic.ToolInputSchemaParam{
            Properties: map[string]any{
                "a": map[string]any{"type": "integer"},
                "b": map[string]any{"type": "integer"},
            },
        },
    }
    tools := []anthropic.ToolUnionParam{{OfTool: &addTool}}

    messages := []anthropic.MessageParam{
        anthropic.NewUserMessage(anthropic.NewTextBlock("What is 2 + 3?")),
    }

    for {
        resp, err := client.Messages.New(context.Background(), anthropic.MessageNewParams{
            Model:     "claude-opus-5",
            MaxTokens: 16000,
            Messages:  messages,
            Tools:     tools,
        })
        if err != nil {
            log.Fatal(err)
        }

        // Append the assistant turn BEFORE handling the tool calls.
        messages = append(messages, resp.ToParam())

        var toolResults []anthropic.ContentBlockParamUnion
        for _, block := range resp.Content {
            switch variant := block.AsAny().(type) {
            case anthropic.TextBlock:
                fmt.Println(variant.Text)
            case anthropic.ToolUseBlock:
                var in struct {
                    A int `json:"a"`
                    B int `json:"b"`
                }
                // block.Input is raw JSON — parse it, never string-match it.
                if err := json.Unmarshal([]byte(variant.JSON.Input.Raw()), &in); err != nil {
                    log.Fatal(err)
                }
                result := fmt.Sprintf("%d", in.A+in.B)
                toolResults = append(toolResults,
                    anthropic.NewToolResultBlock(block.ID, result, false))
            }
        }

        if resp.StopReason != anthropic.StopReasonToolUse {
            break
        }

        // All results from this turn go back in ONE user message.
        messages = append(messages, anthropic.NewUserMessage(toolResults...))
    }
}

Five things in there are load-bearing, and four of them are easy to get subtly wrong.

resp.ToParam() converts the response into a history entry. You must append the assistant’s turn — including its tool-call blocks — before you send the results, or the next request has results referring to a call that does not exist in the conversation.

Parse the tool input; never pattern-match the raw string. variant.JSON.Input.Raw() gives you the JSON to unmarshal. Current models vary their JSON string escaping (Unicode escapes, escaped forward slashes), so anything doing strings.Contains on the serialised input is a bug waiting for a release.

All tool results go back in a single user message. anthropic.NewUserMessage is variadic for exactly this reason. Splitting results across several messages technically works, and it quietly teaches the model to stop issuing parallel calls — which halves your throughput for no visible reason.

StopReason is the exit condition, not “did I see any tool blocks”. Check it after you have appended the results, not before.

Every tool call needs a result. If the model asked for three tools and you return two results, the next request is malformed. Including for the one that failed — which brings us to the most useful trick in this whole article.

Errors Are Results, Not Exceptions

The instinct when a tool fails is to abort the loop. Usually that is wrong. Hand the failure back to the model as a tool result flagged as an error, and it will very often recover on its own — retry with a corrected argument, try a different tool, or tell the user what went wrong:

out, err := h.run(ctx, variant)
if err != nil {
    // isError = true. The model sees the failure and can adapt.
    toolResults = append(toolResults,
        anthropic.NewToolResultBlock(block.ID, err.Error(), true))
    continue
}
toolResults = append(toolResults, anthropic.NewToolResultBlock(block.ID, out, false))

That third parameter is isError. Getting this right turns a class of hard failures into self-correcting ones.

One caveat worth stating plainly: the error text goes into the model’s context, so do not put a raw database error with connection strings and internal hostnames in there. Return the error you would show a careful external user. This is the same discipline as deciding what a sentinel error exposes at your HTTP boundary, which I covered in error handling in Go.

Let the SDK Drive

Once you understand the loop, you mostly do not want to maintain it. The Go SDK’s tool runner handles the iteration, and generates the JSON schema from your struct tags:

import "github.com/anthropics/anthropic-sdk-go/toolrunner"

type GetWeatherInput struct {
    City string `json:"city" jsonschema:"required,description=The city name"`
}

weatherTool, err := toolrunner.NewBetaToolFromJSONSchema(
    "get_weather",
    "Get current weather for a city",
    func(ctx context.Context, in GetWeatherInput) (anthropic.BetaToolResultBlockParamContentUnion, error) {
        return anthropic.BetaToolResultBlockParamContentUnion{
            OfText: &anthropic.BetaTextBlockParam{
                Text: fmt.Sprintf("The weather in %s is sunny, 22°C", in.City),
            },
        }, nil
    },
)
if err != nil {
    return err
}

runner := client.Beta.Messages.NewToolRunner(
    []anthropic.BetaTool{weatherTool},
    anthropic.BetaToolRunnerParams{
        BetaMessageNewParams: anthropic.BetaMessageNewParams{
            Model:     "claude-opus-5",
            MaxTokens: 16000,
            Messages: []anthropic.BetaMessageParam{
                anthropic.NewBetaUserMessage(anthropic.NewBetaTextBlock("What's the weather in Kyiv?")),
            },
        },
        MaxIterations: 5,
    },
)

message, err := runner.RunToCompletion(ctx)

Note the namespace: this lives under client.Beta.Messages, and the types are the Beta* variants — BetaTextBlock, not TextBlock. Mixing the two is the most common compile error here.

MaxIterations is not optional decoration. Without a ceiling, a model that gets into a retry rut can loop until your context deadline, and you pay for every turn. Set it to the smallest number that lets legitimate work finish.

If you need to inspect or gate each step — approvals, audit logging, a check before a destructive tool runs — you do not have to drop back to a manual loop. The runner exposes NextMessage() and an All() iterator so you can step it and look at each message, and its Params field lets you adjust the next request. Reach for the manual loop only when you want control the runner genuinely does not expose.

Running Tools Concurrently — With a Limit

When the model asks for four tools in one turn, running them sequentially wastes the whole point. But the naive concurrent version is the same mistake Go developers make everywhere else:

// Don't. One turn can ask for many tools; this has no ceiling.
for _, call := range calls {
    go run(call)
}

Use a bounded group. The results still have to come back in one message, in a fixed order, so index into a preallocated slice rather than appending from goroutines:

import "golang.org/x/sync/errgroup"

results := make([]anthropic.ContentBlockParamUnion, len(calls))

g, gctx := errgroup.WithContext(ctx)
g.SetLimit(4) // whatever your slowest downstream can absorb

for i, call := range calls {
    g.Go(func() error {
        out, err := h.run(gctx, call)
        if err != nil {
            // Not a group error: hand it to the model instead.
            results[i] = anthropic.NewToolResultBlock(call.ID, err.Error(), true)
            return nil
        }
        results[i] = anthropic.NewToolResultBlock(call.ID, out, false)
        return nil
    })
}
if err := g.Wait(); err != nil {
    return err
}

messages = append(messages, anthropic.NewUserMessage(results...))

Each goroutine writes one distinct slice element, so no mutex is needed — different elements are different memory. Appending to a shared slice from several goroutines is a different story, and so is writing to a shared map; concurrent map writing and reading in Go has the failure mode in detail.

Notice that a tool failure returns nil from g.Go. Returning the error would cancel gctx and kill the sibling tool calls, when what you actually want is to report that one failure to the model and let the others finish. The full set of tradeoffs around SetLimit and error propagation is in worker pools in Go with errgroup.

Designing the Tools Themselves

The loop is the easy part. Tool design is where agents get good or stay bad.

The description is the API documentation, and its reader is the model. A tool called search described as “searches” will be called wrongly and often. Say what it searches, what it returns, and when not to use it. Most “the agent keeps doing the wrong thing” problems are description problems.

Fewer, broader tools beat many narrow ones. Twenty tools that each wrap one endpoint force the model to plan a long chain and give it twenty chances to pick wrong. One query_orders tool with a few well-named parameters usually outperforms get_order, list_orders_by_user, list_orders_by_date and count_orders.

Constrain the schema. Enums, required fields and explicit types are enforced before your handler runs. Every constraint you express in the schema is a class of invalid call you never have to validate by hand.

Make results terse. Tool results occupy context on every subsequent turn of the loop. Returning a 400-row JSON dump costs you tokens on turn two, turn three and turn four. Return the fields the model needs to decide what to do next, and nothing else.

Be deliberate about side effects. The model will call your tools in orders you did not anticipate. Anything that writes, sends, charges or deletes wants an approval gate — step the runner and confirm — or, at minimum, idempotency so a double call is harmless.

Guardrails That Actually Matter in Production

A tool loop has a cost profile unlike a normal handler: every iteration resends the whole conversation. The bill grows quadratically with the number of turns if you are not careful, and three things keep it honest.

Cap the iterations. MaxIterations on the runner, or a counter in your manual loop. Non-negotiable.

Bound the wall clock. A deadline on the context that covers the whole loop, not each request:

ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)
defer cancel()

Cache the prefix. Every turn resends the system prompt and the full history. Without prompt caching you pay full price for all of it, every iteration — this is where agent loops get expensive, and it is the one lever with no quality tradeoff at all. It gets its own article.

Then there is the interaction between concurrency and rate limits. A pool of four tool calls, times however many concurrent user requests, times however many turns each — an agent loop is a very effective way to discover your own rate limits. The token-bucket approach from rate limiting Go APIs works just as well pointed at your own outbound calls as at inbound traffic.

Observability, Or You Are Flying Blind

When a loop misbehaves, you need to see what the model actually saw. Log per iteration:

slog.Info("agent turn",
    "iteration", i,
    "stop_reason", resp.StopReason,
    "tools_called", toolNames,
    "input_tokens", resp.Usage.InputTokens,
    "output_tokens", resp.Usage.OutputTokens,
    "cache_read", resp.Usage.CacheReadInputTokens,
)

With a request-scoped logger carrying the conversation id (the pattern from the slog post), you can pull the entire trajectory of one run out of your logs — which is the difference between “the agent is flaky” and “on turn three it called search with an empty query because the description was ambiguous”.

Pitfalls

Conclusion

The loop is twenty lines and you should write it once by hand, then let the runner own it. After that, the work that actually improves an agent is not loop code at all: sharper tool descriptions, tighter schemas, terser results, a hard iteration cap, and enough logging to reconstruct a bad run. The interesting engineering is in the tools, not the loop around them.