Reference · Series Glossary
Glossary
The canonical vocabulary of the series. Lessons adhere to these definitions.
One term, one meaning. When a lesson uses a bolded term, it means
exactly what is written here. Grows as the series progresses.
Day 1 — The New SDLC
- Agent
- A software system that perceives a goal, plans steps, acts through tools,
observes results, and iterates until done or stopped. Runs its own loop, unlike
a chatbot that responds and waits. Day 1, p.10
- Agent = Model + Harness
- A raw model is not an agent. It becomes one when a harness gives it
state, tool execution, feedback loops, and enforceable constraints.
Day 1, p.26
- Harness
- The scaffolding wrapped around the model: instructions/rule files, tools,
sandboxes, orchestration logic, guardrails/hooks, observability. It is the
team's surface area, not the model provider's.
Day 1, p.27–28
- Vibe coding
- The casual end of the dial: describe what you want in natural language, accept
the output, paste errors back when it breaks. Verification is optional.
Karpathy, Feb 2025; Day 1, p.11
- Agentic engineering
- The disciplined end of the dial: AI implements within human-designed
constraints, tests, and feedback loops; humans own architecture and correctness.
Day 1, p.12
- The spectrum
- Vibe coding and agentic engineering are endpoints of one dial, set per
task. The differentiator is not whether you use AI but how much structure,
verification, and judgment surround the output. Day 1, p.12
- Test
- Verifies the deterministic part of a system: this input produces that
output. Checked by code. Day 1, p.13
- Evaluation (eval)
- Verifies the non-deterministic part: did the agent take the right
trajectory, choose the right tools, meet the quality bar. Checked by labelled
datasets, rubrics, and LM judges. Day 1, p.13
- Context engineering
- Providing the agent rich, structured information (six types: instructions,
knowledge, memory, examples, tools, guardrails) and managing the static-vs-dynamic
trade-off. The real skill, more than prompt cleverness. Day 1, p.15
- Static vs dynamic context
- Static = always loaded (system instructions, rule files, global memory,
persona), expensive, every token present every call. Dynamic = loaded on
demand (skill instructions, tool results, RAG docs, windowed history), pay only when
needed. The boundary is a versioned architectural decision. Day 1, p.16
- Agent Skills
- Portable packages of procedural knowledge loaded only when a task calls for them, via
progressive disclosure: metadata at startup → full instructions on match → deep
reference when explicit. Lets one agent carry dozens of specialisms cheaply. Day 1, p.16
- Factory model
- The developer's primary output is the system that produces
code, not the code itself: specs, agents, tests/gates, feedback loops, guardrails. You design the
assembly line, not the widget. Day 1, p.24
- Conductor vs Orchestrator
- Two modes the developer moves between. Conductor: hands-on, real-time
direction in the IDE. Orchestrator: async, higher-abstraction delegation
to background/multi-agents. Day 1, p.31
- The 80% problem
- Agents generate ~80% of a feature fast; the last 20% (edge cases, integration,
subtle correctness) needs deep context the model lacks. Day 1, p.34
- CapEx / OpEx (TCO)
- The economic reading of the dial. Vibe coding = low CapEx, high OpEx (cheap to
start, expensive to run/fix/maintain). Agentic engineering = high CapEx, low OpEx
(invest upfront in schemas/tests/context, marginal cost per feature drops). OpEx is dictated
by the token economy. Day 1, p.39
- Intelligent model routing
- Sending each task to the cheapest model that can do it: small/fast models for deterministic
work (test gen, review, CI), frontier models for architecture and hard reasoning. Drives down
token OpEx without losing quality. Day 1, p.42
Day 2 — Agent Tools & MCP
- Tool
- A function/program an agent calls to do what the model can't alone. Does one of two things:
lets the model know (retrieve data) or do (take an action). Defined as a
contract: name + typed parameters + natural-language description the model reads. Day 2, p.9
- Tool types (three)
- Function tool — you define it, model calls it. Built-in tool — supplied
implicitly by the model service (e.g. Search grounding, code execution). Agent tool —
an agent invoked as a tool; A2A exposes remote agents this way. Day 2, p.10–13
- Tool taxonomy (risk map)
- By function: Information Retrieval (reads, lower risk), Action/Execution (writes/acts, higher),
System/API Integration (reach, higher), Human-in-the-Loop (a control). Risk tracks the
category. Day 2, p.13
- Model Context Protocol (MCP)
- An open standard (Anthropic, Nov 2024) for connecting models to tools. Collapses the
N×M custom-connector problem to N+M: build a tool once as a server, any
MCP model uses it. Inspired by USB / the Language Server Protocol. Day 2, p.21
- MCP Host / Client / Server
- Host — the AI app; orchestrates tools and enforces security policy.
Client — connector inside the Host holding one session to one Server.
Server — adapter for a tool/API/data; advertises + executes tools; in enterprise, also
security & governance. Day 2, p.23
- MCP primitives (six)
- Server-side: Tools, Resources, Prompts. Client-side: Sampling, Elicitation, Roots. Only
Tools are broadly supported (~99% of clients); the rest range from ~34% down to
~4%. Build on Tools. Day 2, p.25
- Context-window bloat (MCP)
- To know which tools exist, the Host loads every connected server's tool definitions into the
context window: cost, latency, and degraded reasoning. The tooling-side face of Day 1's
static-context problem. Likely fix: RAG-for-tools (retrieve relevant tools per task). Day 2, p.38
- The centralised-governance thesis
- Enterprises don't adopt "pure" MCP; they wrap the open protocol in layers of centralised
governance (gateways, managed platforms) that impose the security, identity, and observability the
base protocol omits. The tooling-side arrival at the governance
layer / VERDICT. Day 2, p.40
- Confused deputy
- A privileged program (the "deputy") is tricked by a less-privileged attacker into misusing its
authority. In MCP: a prompt-injected agent relays an attacker's request to a broadly-privileged
server, which checks only its own permissions, not the user's → privilege
escalation. Fix: per-agent identity + scoped, user-bound credentials. An I
Identity failure. Day 2, Appendix p.51
- Tool shadowing
- A malicious tool's description is crafted with broad triggers so the model's planner chooses it
over a legitimate tool, intercepting data. Defence: name-collision checks, approved-servers-only,
deterministic policy, HITL. Day 2, p.45
- Scoped / least-privilege credentials
- Give each tool the narrowest, short-lived, audience-bound credential that works, ideally the
acting user's scoped authority, not the server's broad one. The core defence against the
confused deputy and the cap on any tool's blast radius. Day 2, p.49
Day 3 — Sessions & Memory
- Session
- The container for one conversation, tied to one user: events (chronological history:
user/agent/tool) + state (a working scratchpad). The "workbench." Persisted because the
runtime is stateless; strictly isolated per user. Day 3, p.12
- Memory
- Extracted, meaningful information persisted across sessions, the "filing cabinet."
Makes an agent an expert on the user. Content + metadata; user/session/app scope; managed
by an active memory manager, not a passive DB. Day 3, p.27
- Context rot
- As a context window grows, the model's ability to attend to critical information degrades, on
top of rising cost and latency. Why context engineering is curation, not accumulation. Day 3, p.8
- RAG vs Memory
- RAG = research librarian: shared, static, authoritative world facts. Memory = personal
assistant: isolated, dynamic knowledge of the user. Complementary. An agent needs both. Day 3, p.31
- Declarative vs procedural memory
- Declarative = knowing what (facts, preferences), where commercial systems
live. Procedural = knowing how (workflows/playbooks), reasoning augmentation, a
fast online alternative to fine-tuning. Day 3, p.34/64
- Memory generation (extraction + consolidation)
- An LLM-driven ETL. Extraction pulls only info matching defined topics. Consolidation
(the self-editing step) merges/updates/deletes vs existing memories and forgets stale ones.
Runs async in the background. Day 3, p.41
- Memory provenance
- A memory's origin + freshness, used to weight its trust. Source hierarchy: bootstrapped/explicit
(high) → implicit (lower) → tool output (brittle, prefer caching). An Evidence discipline for
knowledge. Day 3, p.49
- Memory poisoning
- A malicious user injects false "facts" via prompt injection to corrupt an agent's persistent
memory. Defence: validate/sanitise (e.g. Model Armor) before committing to memory. Day 3, p.69
Day 4 — Security & Evaluation
- Two axes of trust
- Security = did the agent stay inside the boundary (no harm)? Evaluation = is what
happened inside worth shipping (real value)? Independent; passing one is not passing both. Day 4, p.6
- Effective Trust · Context-as-a-Perimeter
- Trust as a continuous metric (earned, verified, dynamically enforced on runtime context), not a
gate passed once at deployment. Google's name for VERDICT's thesis. Day 4, p.8
- The 7-Pillar Security Architecture
- Infrastructure · Data · Model · Application/Runtime · Identity & Access · Observability/SecOps ·
Governance. Maps almost pillar-for-pillar onto VERDICT (see
the mapping). Day 4, p.9
- Slopsquatting
- A supply-chain attack: LLMs hallucinate package names, attackers pre-publish malware under those
names, and an autonomous agent pulls it into the build. Defend with vetted registries, version
pinning, SBOM + signature gates. Day 4, p.14
- Zero ambient authority · JIT downscoping
- An agent never inherits the developer's standing admin power; it gets fresh, hyper-scoped,
expiring credentials per task (Intent × User × Time). The identity fix for the confused deputy. Day 4, p.19
- The Vibe Diff
- Before a high-stakes action, the system translates generated code back into plain English so the
human approves comprehension, not syntax, defeating rubber-stamp confirmation fatigue.
Paired with hardware MFA. Day 4, p.19
- Intent drift · Trust decay · circuit breaker
- As an agent's sub-goals diverge from the human's intent (drift), its Agent Trust Score decays; below
threshold a circuit breaker rolls back to a checkpoint and quarantines. VERDICT's kill-switch,
automated. Day 4, p.25
- Denial of Wallet (DoW)
- An attack that drives an agent into infinite, expensive API loops to run up the LLM/cloud bill, an
invisible failure a "200 OK" hides. Why observability is a security requirement. Day 4, p.24
- The 7 evaluation dimensions
- Intent satisfaction (hardest) · functional correctness (floor, gameable) · visual/behavioural ·
cost & efficiency (incl. iteration count) · code quality/convention · trajectory quality ·
self-repair, with safety transversal. Day 4, p.29
- The underspecification gap
- Vibe coding has no spec; the prompt is inherently underspecified. Evaluation's first job is
checking the agent reconstructed the right unstated spec. Practical rubric: the session
prefix (first 1–2 user messages). Day 4, p.28
Day 5 — Spec-Driven Production
- Spec-Driven Development (SDD)
- Spec-first, not code-first. The developer is a technical architect; code is disposable
(regenerable from a solid spec), so the spec is the durable asset and source of truth, stored
in a version-controlled
specs/ folder. Day 5, p.7
- Behaviour-Driven (BDD) · Gherkin
- A spec style using
Scenario / Given / When / Then, forcing State → Action → Outcome,
which eliminates guessing and keeps the agent on a strict track. Day 5, p.9
- The format tax
- LLMs are highly sensitive to instruction format (up to 40% performance drop on generic Markdown).
Best for Gemini: Markdown narrative + conditional YAML for nested config (YAML 51.9% vs JSON 43.1% vs
XML 33.8%). Tokenization is a hard physical constraint. Day 5, p.8
- Conditional LGTM
- Approve a PR contingent on automated tests passing; when they go green, it merges automatically.
An automated gate that kills cross-timezone review delay. Day 5, p.19
- Three-tier continuous review
- Tier 1 Managed (SaaS reviewer, generic) · Tier 2 Hybrid (your
code-check.md
skill in CI, the right start) · Tier 3 Custom (ADK agent with memory, graph-native, you own
eval/on-call). Pick the lowest tier that catches what matters. Day 5, p.20
- Policy Server (structural + semantic gating)
- External, tamper-proof governance that intercepts tool calls: structural gating (deterministic
role/env rules in
policies.yaml) + semantic gating (a second LLM judging intent,
e.g. no unmasked PII). Separates governance logic from execution: VERDICT, in code. Day 5, p.30
- Context hygiene
- Middleware that masks PII and injects placeholders (
[[VAR]] resolved at runtime), so an
agent can't fill gaps with, or leak, sensitive strings ("context hallucination"). Day 5, p.32
The Governance Layer (overlaid on the series)
Full reference:
The Governance Layer. From Srivastav & Saxena's framework, overlaid as a second axis from Lesson 1.
- Governance axis (the second hand)
- Orthogonal to the build dial. The build dial asks "is the output verified before
ship?"; the governance axis asks "while it runs, can we see it, stop it, and name
who owns it?" A task has a coordinate on both. governance-layer.html
- VERDICT
- A 7-pillar runtime governance operating model: Validation,
Evidence, Runtime Control, Decisions,
Identity, Cost & Compliance, Transparency.
"Doesn't prevent AI — prevents AI from going unchecked." Srivastav & Saxena
- Governance Maturity Ladder
- Where the org sits: L1 Unseen 👻 → L2 Observed 👁 → L3 Controlled 🔒 →
L4 Autonomous 🖥. VERDICT's target is L3. Climbed via the phases
EXPOSE → BIND → ENFORCE → SELF-GOVERN. Srivastav & Saxena
- Runtime governance
- Policy enforced while the agent runs (kill-switch, live gates, spend caps,
immutable logs), not just pre-deployment review. Needed because agents act faster
than human review cycles. runtime-governance-enforcement.md