Capstone · DocQA — answer questions about your own documents

What this lesson demonstrates

DocQA is the capstone. It’s a real (if tiny) product: an assistant that answers questions about a set of Markdown documents — the fictional “Nimbus Notes” — and only from those docs. Every concept from the earlier lessons shows up in service of that one job: a search_docs function tool doing keyword retrieval (RAG), grounding instructions, conversation memory, audit middleware, and an optional DocQA → Reviewer sequential workflow. The Go SDK ships no upstream 06-capstone sample, so this is a from-scratch port of the Python capstone.

The CLI has three modes: a one-shot question (docqa "..."), an interactive chat that remembers context, and --review, which drafts an answer and runs a second agent over it before it reaches you.

The real code

The whole agent is assembled in newDocQAAgent — the search tool, grounding instructions, an in-memory history provider, and the audit middleware, all on one Foundry agent:

return foundryprovider.NewAgent(endpoint, cred,
    foundryprovider.ModelDeployment(model),
    foundryprovider.AgentConfig{
        Instructions: instructions,
        Config: agent.Config{
            Name:            "DocQA",
            Tools:           []tool.Tool{searchDocsTool},
            HistoryProvider: agent.NewInMemoryHistoryProvider(agent.InMemoryHistoryProviderConfig{}),
            Middlewares:     []agent.Middleware{audit(auditOut)},
        },
    },
)

The instructions string is what forces grounding: answer using ONLY search_docs, cite each source as (file › section), and refuse when the docs don’t contain the answer.

What to notice

• Grounding is a tool plus instructions, not magic. search_docs returns cited passages; the instructions bind the model to them. When retrieval finds nothing, the tool returns a no-match sentinel and the model is told to refuse rather than guess.
• Retrieval is pure, deterministic Go. knowledge.go’s search() is keyword overlap with a title boost, no network — which is exactly why its behavior can be asserted offline.
• go:embed replaces the filesystem read. The docs/*.md files travel inside the binary, so retrieval works regardless of the working directory. Swap them for your own docs and rebuild.
• --serve (DevUI) is omitted on purpose. The Python capstone launched a DevUI web chat; the Go SDK has no DevUI, so --serve just prints an explanation and exits.

How it maps to the Microsoft Agent Framework Go SDK

DocQA is a survey of the SDK in one file tree: functool.MustNew for the tool, agent.NewInMemoryHistoryProvider for memory, an agent.Middleware for the audit seam, and — under --review — a two-node sequential graph run through inproc.Default.RunStreaming, watching workflow.OutputEvents to stream each executor’s output. It’s the shape a grounded Azure AI Foundry assistant takes in production: retrieval in, cited answer out, everything but the model call testable offline.

Run it

go run ./tutorial/06-capstone/docqa "How much does Nimbus Pro cost?" for one question, no args for interactive chat, or --review "..." for the reviewed path. Needs az login + FOUNDRY_PROJECT_ENDPOINT. go test ./... covers retrieval and all wiring offline; the live grounded answer is gated behind AF_LIVE=1.

That closes the series — 86 lessons from check_setup to a shippable document-QA product.

Next: AG-UI Getting Started — The Server