// topic 01
Foundations & Architecture
How LLMs work under the hood, where they're strong and where they break, context windows, the agent loop, tool use, and the primitives available for building on top of a model — MCP, skills, plugins, subagents, memory, and RAG — and when each one earns its place.
Overview
Placeholder — fill in with the topic's framing: why architecture literacy matters before choosing tools, and the core question this topic answers for an adoption program.
Key question: given a task, which primitive — prompt, RAG, tool, skill, subagent, or a whole plugin — is the right level of machinery, and why?
How LLMs Work
Placeholder — next-token prediction, training phases (pretraining / fine-tuning / RLHF), why models hallucinate, and what "reasoning" is actually doing under the hood.
Strengths, weaknesses, limits
| Strong at | Weak at | Hard limit |
|---|---|---|
| Pattern completion, synthesis, drafting | Precise arithmetic, long exact recall | Context window size |
| Following structured instructions | Knowing what it doesn't know | Knowledge cutoff |
| Code generation from examples | Multi-step state tracking without tools | No persistent memory by default |
Context windows
Placeholder — context window as the model's entire working memory for a turn; why "more context" isn't free (cost, latency, attention dilution); the idea of a context budget.
The Agent Loop & Tool Use
Placeholder — the read → think → act → observe loop, and why "agent" mostly means "a model calling tools in a loop with memory of its own actions."
A minimal tool-call shape
{
"tool": "search_docs",
"input": { "query": "refund policy", "top_k": 5 }
}
// model receives the result, decides whether to call another tool
// or respond — this is the whole loopPrimitives — and when to use each
Placeholder — a decision framework for choosing between these, roughly in order of increasing machinery and commitment.
| Primitive | What it is | Reach for it when… |
|---|---|---|
| RAG | Retrieve relevant content, inject into context | Knowledge is large, changes often, and doesn't need to be "always on" |
| Skill | Packaged instructions + optional scripts, loaded on demand | A repeatable task has a known best procedure worth codifying |
| MCP server | Standard protocol exposing tools/resources to any client | You need the same tool available across multiple agent clients |
| Plugin | Bundle of skills, agents, commands, hooks distributed together | You're packaging a capability for other teams to install |
| Subagent | A separate agent invocation with its own context | A task needs isolation, parallelism, or a different tool scope |
| Memory | Persisted state read back into future sessions | Continuity across sessions matters more than a clean context |
Running notes
Placeholder — day-by-day notes, open questions, and things to revisit go here.