Verified 2026-07-25 against the exam guide + the official docs pages.
| # | Section | Weight |
|---|---|---|
| 1 | Foundations of Context Engineering | 16% |
| 2 | System Prompt and Instruction Design | 9% |
| 3 | Knowledge Retrieval and Genie Configuration | 20% |
| 4 | Memory Architecture with Lakebase and MLflow | 18% |
| 5 | Tool Design, MCP, and Agent Context | 13% |
| 6 | Context Compression and Compaction | 11% |
| 7 | Multi-Agent and Long-Horizon Task Design | 13% |
Assumed knowledge the exam guide names explicitly: LLM context windows · prompt engineering & few-shot construction · agent frameworks + MCP · Agent Bricks · Semantic Search + embedding models · Lakebase for memory · MLflow 3 for evaluation · Unity Catalog governance for agent tools and retrieval sources.
The 4 context failure modes (diagnose from a trace):
- Poisoning — an error/hallucination enters context and keeps getting referenced.
- Distraction — context so long the model over-focuses on history, ignores instructions.
- Confusion — superfluous content (e.g., too many tools) → wrong tool/action selection.
- Clash — contradictory info in context.
Proactive context control (before compaction is needed): Minimal tool sets · just-in-time retrieval · tool-result scoping (return only needed fields).
Attention budget — identify which context elements consume disproportionate attention and cut them:
- Verbose boilerplate system prompts
- Full tool schemas for rarely-used tools
- Unscoped raw tool outputs
- Stale conversation turns
- Duplicated retrieved chunks Fix = remove/shrink the largest low-signal block first.
Context-length degradation point — degradation shows up as falling retrieval accuracy (right chunk in context, wrong chunk cited) or falling reasoning quality (instruction drift, forgotten constraints) as the window fills. Locate the turn where the metric breaks, then intervene: compact, re-retrieve just-in-time, or clear consumed tool outputs — don't just enlarge the window.
Reasoning mode: reduced = simple/high-volume/tight token budget · extended thinking = genuinely hard multi-step reasoning · standard = default. Justify by token budget + context window impact.
Product-stack picker:
| Need | Pick |
|---|---|
| Govern what the agent may read; metadata, tags, lineage, PII/quality policy | Unity Catalog |
| Durable state/memory across sessions, transactional reads/writes | Lakebase |
| Expose governed tools/data to the agent over a standard protocol | MCP |
| Trace, evaluate, score, monitor agent quality | MLflow 3 |
Production-ready Genie Agent = instructions + sample questions + trusted SQL assets (see Sec 3).
Few-shot example selection — evaluate candidates against canonical coverage criteria, then take the minimal set:
- One example per distinct behaviour/edge case; drop any example whose behaviour is already demonstrated.
- Prefer short, representative examples over long real transcripts.
- Adding an example must buy measurable accuracy — otherwise it is pure token cost.
- Redundant examples also cause distraction, not just cost.
Miscalibrated system prompt → pick the targeted revision with least token + maintenance cost:
| Observed failure | Targeted fix |
|---|---|
| Agent ignores a rule | Move the rule up / state it once, imperatively — don't restate it 3× |
| Over-refuses or over-escalates | Narrow the guard clause's trigger condition |
| Wrong output format | Add one output exemplar, not a prose spec |
| Rarely-needed capability instructions bloat every call | Package as Agent Skills, load on demand (Sec 5) |
Two index types:
- Delta Sync Index — auto-syncs with a source Delta table, incrementally updating as the underlying data changes. Standard endpoints require Change Data Feed enabled on the source table. Embeddings either:
- Managed — Databricks computes the vectors with a model you specify, optionally saved to a UC table.
- Self-managed — you supply pre-computed embeddings in the Delta table. Converting a self-managed embedding index to a Databricks-managed index is not possible. You must create a new index and recompute.
- Direct Vector Access Index — direct read/write of vectors + metadata; you update it manually via the REST API when embeddings change. Use when an external system owns embedding updates.
Endpoints & sync:
- Standard — supports Continuous (seconds of latency, higher cost) and Triggered; both are incremental (only changed data processed). Requires CDF.
- Storage-optimized — >1B vectors at dim 768, 10–20× faster indexing, but only Triggered sync (continuous not supported) and every sync partially rebuilds the index.
Strategy: pre-inference (embedding-based, up-front/synced index) for stable corpora + low latency · just-in-time agentic (tool call / dynamic Delta query) for fresh, occasional or fast-changing data.
Chunking: structure/semantic-aware, sized to the embedding model's context length, modest overlap, matched to the query types the agent will face.
RAG pipeline over a UC-governed corpus: UC-governed source table → chunk → embed → Delta Sync Index on the authoritative table only → retrieve top-k with metadata filters → scope fields before injecting → cite. Governance is applied at the index/source layer, not by post-filtering results.
Metadata accuracy gap → fix UC table and column comments/descriptions + Genie instructions. Diagnose the failure mode from MLflow eval logs (what was retrieved vs. what was needed) cross-referenced with UC metadata, then apply the UC governance action — comments, certification, tags, or revoking access to derived copies.
📚 https://docs.databricks.com/aws/en/vector-search/vector-search · https://docs.databricks.com/aws/en/vector-search/create-vector-search
Production-ready = instructions + example SQL + trusted assets + knowledge store + benchmarks.
- Instructions limit = 100 per agent: each example SQL query, each SQL function, and the entire General instructions text block each count as one.
- Knowledge Store snippets = 200 per agent: table descriptions, join relationships, and SQL expressions (measures, filters, dimensions) share this limit. Not counted: text instructions, example SQL queries, SQL functions, column descriptions, prompt matching settings.
- Data objects: up to 30 tables or views per agent. Scale limits: 10,000 conversations per agent, 10,000 messages per conversation.
- Trusted assets = parameterized example SQL queries + SQL functions registered in Unity Catalog. When Genie uses a trusted asset to answer, it provides a verified answer.
- Benchmarks = a set of test questions run to assess overall response accuracy.
- Genie is nondeterministic → keep guidance free from conflicting or ambiguous information.
- Joins: primary and foreign keys defined in your schema are automatically saved as join relationships.
📚 https://docs.databricks.com/aws/en/genie/tune-quality · https://docs.databricks.com/aws/en/genie/trusted-assets · https://docs.databricks.com/aws/en/genie/set-up
Lakebase = a fully managed Postgres database integrated into the Databricks platform. Autoscaling compute; isolated branches for development and testing.
- Short-term memory = context within a single conversation session, via thread IDs + checkpointing.
- Long-term memory = extracts and stores key insights across multiple conversations; enables personalised responses from past interactions.
Match memory type to scope: Transient working memory → in-context scratchpad; durable cross-session facts → Lakebase.
Delta-backed state object required over an in-context scratchpad when state must persist beyond the context window, survive failures, or be queryable.
Static vs. dynamic retrieval from Lakebase:
- static = load a fixed memory slice at session start — predictable tokens, low latency, goes stale mid-task
- dynamic = query Lakebase per turn as the agent needs it — always fresh and token-lean, at the cost of per-turn latency and more failure surface.
MLflow 3 for GenAI:
- Tracing logs inputs, outputs, intermediate steps and metadata — prompts, retrievals, tool calls, responses, latency, cost.
- Scorer = a unified interface for defining evaluation criteria, returning pass/fail, true/false, a numerical value, or a categorical value. Four scorer categories:
- Built-in judges
- Custom LLM judges
- Code-based scorers
- Third-party scorers
- The same scorer works for evaluation in development and monitoring in production, keeping evaluation consistent across the lifecycle.
- Comparing runs: the most reliable context configuration is the one with the best scorer results and the least variance across runs on the specified task.
📚 https://docs.databricks.com/aws/en/oltp/projects/state-management · https://docs.databricks.com/aws/en/oltp/ · https://docs.databricks.com/aws/en/mlflow3/genai/eval-monitor/concepts/scorers · https://docs.databricks.com/aws/en/mlflow3/genai
Five Databricks managed MCP servers. Unity Catalog enforces permissions, so agents and users access only the tools and data you grant them. On-behalf-of-user OAuth scopes: genie · ai-search · sql · unity-catalog.
- Layered MCP (discovery → planning → execution) + progressive disclosure: metadata always in context; full tool/skill detail loads just-in-time → fewer tokens than loading all tool schemas upfront.
- Confused tools = overlapping descriptions → disambiguate purpose, inputs and outputs so no two tools claim the same job.
- Bloated system prompt with rarely-invoked capabilities → package as Agent Skills, load on demand; minimize baseline context cost without harming task success rate.
- Tool selection = semantic similarity (task description ↔ tool description). Good documentation helps your agents know when and how to use each tool.
- UC function tools = structured retrieval when the query is known ahead of time and the agent provides the parameters.
- Require Python type hints and Google-style docstrings
*args/**kwargsunsupported- Serverless execution is the default/recommended mode for production
- Databricks recommends adding UC functions via MCP servers over direct integration (automatic tool discovery + built-in auth).
- Near capacity → clear old, already-consumed raw tool outputs first.
📚 https://docs.databricks.com/aws/en/generative-ai/mcp/managed-mcp · https://docs.databricks.com/aws/en/generative-ai/agent-framework/create-custom-tool
- Maximize recall first (capture everything relevant), then iterate to improve precision (remove superfluous outputs).
- Preserve durable user constraints, decisions and requirements — the category most often wrongly discarded, whose loss shows up as downstream coherence failures.
- Safe to remove: consumed raw tool outputs, superseded intermediate results, resolved sub-tasks, duplicate retrievals.
- Hard-coded trimming (drop oldest N) is sufficient only when relevance correlates with recency; otherwise use semantic compaction.
- Aggressive = lower token cost, risk of losing subtle context; conservative = higher fidelity, higher cost. Pick per stakes.
- Insufficient shared context → inconsistent outputs, conflicting decisions, degraded reliability.
- Sub-agents receiving only individual task messages rather than full agent traces at dispatch time → give common ground without expanding each sub-agent's context window.
- Conflicting outputs → change context propagation: shared state store, consistent instructions, dispatch the relevant trace.
- Orchestrator context saturation → redesign sub-agent outputs to be concise, scoped and structured, without compromising task coherence.
- Boundaries too fine = excessive handoff/compression overhead; too coarse = unmanageable context window growth within individual agents.
- Strategy mismatch: linear single-thread where subtasks are independent and parallelisable → decompose into sub-agents; justify by the task's dependency structure.
Constrain retrieval to authoritative sources before deployment: grant the service principal read on certified tables only · build the index on the authoritative source only · use UC certification/tags + permissions to exclude derived copies. Never grant broad catalog SELECT "so the agent can choose."