Exercise 4.1 -- Tasks and Knowledge
# Exercise 4.1 -- Tasks and Knowledge
**Context Engineering Layer: Persistence** -- Build task DAGs and extract tacit knowledge into files
## Goal
Design a persistence layer for the contract review agent so that knowledge survives across sessions and context compactions. You will create a task tracking system and extract tacit knowledge into persistent files that the agent can reference.
## Prerequisites
- Completed Module 3 (you have an architecture map and optimized CLAUDE.md)
## What You Have
- Your working agent from previous modules
- `knowledge-extraction.md` -- Template for capturing tacit knowledge (in this exercise folder)
## Key Concept: Persistence
The context window is volatile -- it empties when you `/clear` or start a new session. Anything the agent "learned" during a conversation is lost unless you persist it to files.
Persistence transforms:
- **Volatile knowledge** (exists only in conversation) into **durable knowledge** (written to disk)
- **Implicit understanding** (built up over turns) into **explicit instructions** (readable in a file)
## Your Tasks
### Step 1: Build a Task DAG for a Multi-Contract Review
Imagine you receive three contracts from the same client that need to be reviewed together. Create a `tasks.md` file that defines the task dependency graph:when to use it
Community prompt sourced from the open-source GitHub repo shahabmalikAI5/ai-context-engineering-workshop (no explicit license). A "Exercise 4.1 -- Tasks and Knowledge" style prompt — adapt the placeholders and specifics to your task. Imported as-is and not independently retested here, so check the output before relying on it.
tags
codingcommunitydeveloper
source
shahabmalikAI5/ai-context-engineering-workshop · no explicit license
more in Coding
Coding✓ tested
Senior code review (strict mode)
senior staff engineer running a merciless but fair review
Coding✓ tested
Debug by hypothesis, not by guessing
debugging partner who forms theories before touching code
Coding✓ tested
Generate tests from described behavior
test engineer who writes tests that would actually catch regressions