AI Field Guide
This is where I turn what I learn while building with AI into guides, experiments, pitfalls and reusable patterns — always mapped back to Work With AI, Give AI Work and Run AI.
See how Prompt, Context, Harness, Loop and Graph Engineering fit into the three-course journey, and use the guide that matches the problem you actually have.
Nothing for the map. Bring a real task, repository or AI workflow when following a hands-on guide.
Start from the core programme or from the failure you are seeing, then use the relevant field guide, lab or future field note.
A clear mental model of where each engineering discipline belongs and a path from human-AI collaboration to delegated and operated AI systems.
One journey. Different engineering problems.
Work With AI
AI works with me. Engineer the instruction and the reality available to the model.
Give AI Work
AI works for me. Make one delegated responsibility dependable, then make continuation controlled.
Prompt → Context → Harness → Loop → Graph → Operate. This is a way to locate the problem, not a maturity checklist. Many useful tasks should stop at Prompt or Context. Many delegated jobs need a Harness but never need a Graph.
ENGINEER THE COLLABORATION.
Before handing the job over, get good at expressing intent and giving AI the right reality.
Prompt Engineering
Reduce meaningful ambiguity, define outcomes and boundaries, choose interaction modes, steer deliberately and compare prompt changes by behavior.
Open guide →Context Engineering
Choose the minimum useful context, source authority, conflicts, freshness and evidence that should legitimately shape the work.
Open guide →ENGINEER THE DELEGATED RESPONSIBILITY.
Once AI is doing the job rather than merely helping with it, the problem changes from good interaction to dependable execution.
Harness Engineering
Operationalise persistent instructions, context delivery, startup, tools, state, verification, deterministic controls, handoff and observability.
Build the harness →Loop Engineering
Move from reliable single runs to controlled autonomy with triggers, queues, verification, recovery, stopping conditions, isolation and budgets.
Build the loop →ENGINEER THE SYSTEM YOU MUST OPERATE.
When several responsibilities share state, branch, conflict, recover or affect the same business outcome, their relationships become an operating problem.
DON'T JUST READ THE GUIDE.
The reference model is strongest when theory turns into projects and copy-ready artifacts. This field guide now has the same missing middle: one evolving lab and a practical resource pack.
Lead to Appointment
Evolve one responsibility from manual baseline → Prompt → Context → delegation → Harness → Loop → Graph → final Run AI release decision.
Run the progressive lab →Why “Reply to this lead” isn't enough
The first recording-ready lesson: vague baseline → fixed acceptance criteria → one prompt intervention → measured rerun → break-it case → Context Engineering tension.
Run Episode 01 →Copy-ready resource pack
Prompt experiment, source map, context pack, AGENTS starter, handoff, loop contract, recovery record, graph decision, node contract and anchor map.
Open resources →Evidence labels
Because this site records a real journey, every empirical claim should make clear what kind of evidence supports it.
| Label | Use when |
|---|---|
| Observed | I directly saw it in my own build/run. |
| Reproduced | I repeated it under documented conditions. |
| Simulated | It happened in a classroom/test scenario, not production. |
| Designed | It is a proposed architecture/pattern not yet run end-to-end. |
| External | Another source reports it; cite source/version/date. |
| Illustrative | It is invented only to explain a concept. |
Do not quietly turn a Designed pattern or Simulated exercise into a claim about observed production behavior.
One lab method across all five disciplines
The resource pack gives you artifacts and the Lead-to-Appointment lab gives you continuity. The Lab Method gives every future recording the same evidence spine.
Baseline → Hypothesis → One intervention → Rerun → Measure → Break it → Conclude → Submit / keep.
It is not scientific theatre. It simply stops us from changing five things at once and then guessing which one mattered.
This is also my working notebook
The stable guides above are the current distilled view. The field guide should also preserve how that view was earned as I build and operate real systems.
| Type | What it records | How it should change |
|---|---|---|
| Guide | Current mental model, pattern, pitfalls, proof and when not to use it. | Revise as understanding improves. |
| Lab | Baseline → hypothesis → one intervention → rerun → evidence. | Keep reproducible. |
| Field note | A dated build, failure, surprise, fix and what I currently believe. | Do not rewrite history; add a newer note when the view changes. |
| Teardown | How a real tool/runtime implements the same ideas. | Update or date when the product changes. |
| Recording | The live reasoning, mistakes and experiment. | Layer it onto a useful written page; do not make the video the only explanation. |
The polished guide can change. A dated field note should preserve what happened then. That lets 9order be both a useful reference and an honest record of the journey.
Field notes — the journey behind the guide
The stable guides show the current view. Field notes preserve the reasoning, mistakes and corrections that led there.
Where Prompt, Context, Harness, Loop & Graph Engineering Belong — why Prompt/Context moved under Work With AI, Harness/Loop under Give AI Work, and Graph under Run AI.
How a recorded field-guide lesson should work
- Failure: show the weak or broken version.
- Likely instinct: name the fix people usually try.
- Aha: replace one misleading mental model.
- Build: change one structural element.
- Rerun: compare against the baseline.
- Break it: remove the change or inject a counterexample.
- Common traps: show realistic bad implementations.
- Look out for: teach signals that the current design is reaching its limit.
- Prove it: define observable acceptance evidence.
- Keep: leave a copyable artifact.
- Next tension: expose the next unresolved problem.
A recording without a reproducible failure and a pass test is a demonstration. The field guide should turn the recording into a lab someone can revisit later.
Architecture first. Framework second.
You do not need LangGraph, CrewAI or any particular agent framework to learn these disciplines. Frameworks are implementation choices. First understand intent, context, responsibility, state, verification, routing, authority and evidence.
The same field guide can later contain framework-specific labs and teardowns without turning the core concepts into product tutorials.