0.5. Resources

Which sources should you trust first?

This page is a trust map, not a link dump: it ranks where to look and says what each source is authoritative for. The one place that decides what this course actually supports is the repository itself.

There is a hierarchy, and which half of it applies depends on what you are asking:

• For "what does this course do," the installed source, the lockfile (which records exact dependency versions), and the passing tests in this repository outrank any prose, including these docs.
• For "how does the underlying tool work in general, and what is its full API," the upstream primary documentation outranks a blog post or a model's recollection.

Agent APIs move fast and most of these projects are pre-1.0, so a tutorial written six months ago can describe a schema that no longer exists.

Reach for the upstream docs when you are extending the reference beyond what the course shows — a tool option, a policy field, a CRD attribute (a field on a Kubernetes custom resource) the pages never needed:

Blog posts and conference talks are useful for orientation and design intent. They are never the version authority: the installed release, the API schema, the lockfile, and the tests decide what runs. When the upstream docs and this repository disagree, that gap is itself the signal — read How do you spot a stale resource? below.

The map below follows the same split: the repository first for this course, the upstream primary docs first for the tool in general. Orientation material sits below both and never overrules either:

flowchart TD
    Q["Your question"] --> T{"About THIS course,<br/>or the tool in general?"}
    T -->|this course| R1["agents/python/tests/"]
    R1 --> R2["agents/python/ + uv.lock"]
    R2 --> R3["agents/data/ + infra/"]
    R3 --> R4["READMEs · CHANGELOG.md"]
    T -->|tool in general| U1["Upstream primary docs<br/>+ MCP / A2A specs"]
    R4 --> B["Blog posts · talks<br/>(orientation only,<br/>never version authority)"]
    U1 --> B

Which resources ship inside this repository?

The highest-authority resource for this course is not external at all. The repository's stated contract is that docs mirror source and the source remains the verification surface, so when a page and the code diverge, the code wins.

After the clone in 1.0. System, run ls at the repository root once so the paths below have a shape. Read these in-repo artifacts as first-class references, in rough order of authority:

• agents/python/tests/ — the real behavioral contract. The offline test suite is what actually pins the agent's behavior; it runs with no model or network and enforces at least 95% combined line-and-branch coverage. If you want to know what an invariant guarantees rather than what the prose claims, read the test that asserts it.
• agents/python/ — the canonical implementation. The locked ADK agent, its tools, guardrails, and the A2A server. Every critical documentation excerpt is included from here through checked snippet regions, so the page you are reading cannot drift from the code without failing CI.
• agents/data/ — immutable seed input. The SQLite database, service logs, runbooks, and Agent Skills the agent reads. Runtime writes go elsewhere, so this dataset is a stable fixture you can rely on across exercises.
• infra/ — the canonical deployment contract. The three agentgateway profiles, the Kubernetes base and overlays, the kagent resources, the MLflow server, and the observability stack. Commands and manifests in the docs mirror these files.
• Component READMEs. README.md (humans) and AGENTS.md (coding agents) at the root, plus scoped READMEs under agents/, agents/data/, agents/python/, agents/python/evals/, and clients/web/. Start with the README nearest the code you are touching.
• CHANGELOG.md. Release-facing changes in Keep a Changelog form (entries grouped by change type) — the fastest way to see what moved between versions before you trust an older example.

Prefer any of these over a screenshot or a remembered command. The point of a source-synchronized course is that you can always check.

Which coding assistants can help?

Use whatever editor and assistant you are already productive in. The course's open-source commitment applies to the stack you ship — the model, gateway, platform, and observability the agent depends on at runtime — not to the tools you happen to type in. Nothing in this repository requires a specific editor, and no gate inspects which one you used.

An assistant is an untrusted collaborator, not an authority. Review its patches, keep credentials out of its context, and hold its changes to the same mise run check and mise run test gates as human ones. The repository's AGENTS.md gives every compatible tool one shared set of project rules, so the assistant follows the same conventions you do.

What are Agent Skills?

An Agent Skill is a small, discoverable instruction package rooted at SKILL.md, loaded only for a relevant task rather than injected into every prompt. It is a build capability, not a resources concern, so it has a home of its own. 3.2. Skills walks through the two skills the course ships, the progressive-disclosure flow, and the least-privilege allowlist.

Where can you ask questions or contribute?

The course repository is public at MLOps-Courses/agentops-open-course. Route your report to where the fix has to land — a defect in an upstream project cannot be fixed in a course issue:

• Open a course issue only for the course's own code, docs, data, or infra config — a reproducible defect or a scoped improvement in this repository.
• Send a defect in an upstream project (ADK, agentgateway, kagent, MLflow, OpenTelemetry, MCP, or A2A behavior itself) to that project's tracker, not the course.
• Follow CONTRIBUTING.md: a small fix can go straight to a pull request, but a new dependency, architectural change, or substantial chapter rewrite starts with an issue so the approach is reviewed first.
• Report a vulnerability, leaked credential, or real prompt-injection bypass through the private process in SECURITY.md, never a public issue.
• Join the upstream AAIF, CNCF, ADK, agentgateway, kagent, MLflow, MCP, and A2A communities when a question belongs to the project itself.

Maintainers should still apply the anonymous publication gate in 8.4. Documentation whenever repository, Pages, DNS, or source-link contracts change.

How can you cite or reuse this course?

The repository is dual licensed, and which license applies depends on what you reuse:

• Course prose (everything under docs/) is CC BY 4.0, in docs/LICENSE.txt. You may copy, adapt, and republish it — including in your own teaching — as long as you credit the author, keep a license notice and a link to the material, and indicate any changes you made.
• Software and repository automation (the reference agent, tests, and infrastructure) is MIT, in the root LICENSE. You may reuse and modify it freely, including commercially, as long as you keep the copyright and permission notice.

For an academic or technical citation, use CITATION.cff at the repository root, and cite the version you actually used.

8.1. License is the full treatment: the exact attribution text for each grant, the machine-verifiable mise run check:licenses drift gate, and how to license your own agent once you fork the reference.

What companion material is available?

One external companion exists: the MLOps Coding Course. It covers the broader software and model-lifecycle foundations this course assumes — packaging, testing, CI, and deployment for machine-learning systems — without the agent-specific stack. Reach for it when a gap is really about general MLOps engineering rather than agents. For anything agent-specific, the in-repo artifacts above are the companion material.

Where do the key terms live?

Any term the course teaches as a concept is defined in one line in 0.7. Glossary. The list is alphabetical and covers the vocabulary each chapter introduces — agent, tool, MCP, A2A, RAG, HITL, guardrail, trace, k3d, Kustomize overlay, WIF, and the rest. Each entry links back to the section that introduces it, so start there when a term is unfamiliar.

How do you spot a stale resource?

Check the publication date, then compare every example against the versions this repository actually pins. The pins are not scattered guesses; they live in a few known places.

If an external example uses a field, flag, or endpoint that none of those pins recognize, treat the example as ahead of or behind this repository, not as ground truth. When you do upgrade, follow the one-component-at-a-time procedure in 0.3. Ecosystem and re-run the gates. If a course link or command has genuinely drifted, open a documentation issue with the page, the observed output, and your platform.

How should you use this page later?

Come back to this page when two sources disagree, not to read it end to end. It settles one question: which source wins.

You are done when:

• You can name the authority for "what does this course do": the repository — its tests, its locked dependencies, its code.
• You can name the authority for "how does this tool work in general": that project's primary documentation, linked in the table above.
• You know where the pinned versions live, so you can tell a stale example from a current one.
• You know where a report goes: a course issue, an upstream tracker, or the private process in SECURITY.md.

Continue to 0.6. Troubleshooting when you know which of those two authorities to open first.