Go SDK

The Go SDK is the direct embedding layer for Seshat. It gives developers the same mono-run runtime model used by the CLI app and other host surfaces, but as a library they can wire into their own product, backend, automation worker, or internal tool.

What This Page Is For

Concepts explains what the runtime is and why tools, permissions, providers, memory, and execution modes are separated. This page is different: it is about embedding that runtime in your own Go application and understanding the main integration surfaces exposed by sdk.ClientConfig.

Common Integration Patterns

Local developer companion

Embed Seshat into a desktop utility, IDE-adjacent tool, or automation helper that needs filesystem, shell, browser, and MCP access from one runtime.

Backend service

Run Seshat behind an API or job system and inject per-user credentials, policies, storage, and monitoring from your own infrastructure.

Automation worker

Use the runtime as the execution core behind scheduled research, code maintenance, data transformation, or long-running internal operations.

Product feature runtime

Expose autonomous task execution inside your own SaaS while keeping sessions, permissions, tools, memory, and multimodal providers under one host-controlled runtime.

Minimal Client Bootstrap

The main public entry point is sdk.NewClient. You choose a model, provide credentials, pick a working directory and permission mode, then the SDK builds the provider client, engine, tool registry, memory services, and execution loop for you.

Go SDK

client, err := sdk.NewClient(&sdk.ClientConfig{
    Model: sdk.ModelIdentifier{
        Provider: sdk.APIProviderAnthropic,
        Model:    "claude-sonnet-4-20250514",
    },
    APIKey:         os.Getenv("ANTHROPIC_API_KEY"),
    WorkingDir:     "/workspace/project",
    PermissionMode: sdk.PermissionModeOnRequest,
})
if err != nil {
    log.Fatal(err)
}
defer client.Close()

Sessions, Streaming, And Runtime Events

The Go SDK is not just a thin “generate text” wrapper. It exposes persistent sessions, streamed response chunks, structured runtime events, tool progress notifications, and the same loop-level execution model that drives the rest of Seshat.

Sessions and callbacks

client, err := sdk.NewClient(&sdk.ClientConfig{
    Model: sdk.ModelIdentifier{
        Provider: sdk.APIProviderAnthropic,
        Model:    "claude-sonnet-4-20250514",
    },
    APIKey: os.Getenv("ANTHROPIC_API_KEY"),
    ResponseChunkFn: func(chunk sdk.ResponseChunk) {
        if chunk.Type == sdk.ResponseChunkTypeContentBlockDelta {
            fmt.Print(chunk.Delta)
        }
    },
    RuntimeEventFn: func(event sdk.RuntimeEvent) {
        switch event.Type {
        case sdk.RuntimeEventTypeToolProgress:
            fmt.Printf("tool %s: %s
", event.ToolProgress.ToolName, event.ToolProgress.Message)
        case sdk.RuntimeEventTypeTurnCompleted:
            fmt.Printf("turn complete: %s
", event.StopReason)
        }
    },
})

session, err := client.CreateSession(ctx)
if err != nil {
    log.Fatal(err)
}
defer session.Close()

response, err := session.SubmitMessage(ctx, "Inspect this Go service and suggest fixes.")
if err != nil {
    log.Fatal(err)
}

fmt.Println(response.Content)

Core Go SDK Subpages

The first layer under Go SDK explains the primitives you actually wire first: providers, auth, agent shape, prompt architecture, and tool surface control.

Providers & Auth

Provider ids, environment variables, OAuth and Codex login flows, explicit API key injection, capability-provider slots, and gRPC credential handoff.

Open Providers & Auth

Agent

How to define embedded agent roles, choose the right client-versus-session boundary, and model personas cleanly in your own Go application.

Open Agent

Prompt

The shipped prompt architecture, stable and dynamic layers, stage overlays, project instructions, tool hints, and every prompt-shaping parameter exposed by the SDK.

Open Prompt

Tools & Surface

Builtin tool inventory, permission-sensitive tools, deferred tools, MCP surface shaping, and runtime-owned execution boundaries for host apps.

Open Tools & Surface

Applied Go SDK Tracks

`SDK and API` should come right after Concepts because this is where implementation starts. The next three pages stay under Go SDK on purpose: they are not generic user guides, they are developer-facing runtime composition guides.

Building Workflows

Compose sessions, prompt stages, tool policies, retries, and memory boundaries into workflow shapes that still respect the runtime instead of bypassing it.

Open Building Workflows

Multi-Agent Scenarios

Document mailbox patterns, agent delegation, role separation, and the practical path from one agent loop to team-like runtime behavior in host applications.

Open Multi-Agent Scenarios

Developer Integration

Cover backend embedding, desktop embedding, auth bridging, event streaming, observability hooks, and the product integration patterns teams actually need.

Open Developer Integration

For the runtime-side architecture, continue with Mono-Run Architecture. For tool and provider separation at the conceptual level, continue with Tools & Providers.