32dots HEIDELBERG AI
Session 30

Final systems review and demo

medium
  • Defend your architecture split against the cognition/plumbing/state rule
  • Show a run log and at least one real failure — not only happy paths
  • State, in one slide, what the system deliberately does NOT do

Students should finish by defending design choices, not just showing a shiny output. A demo that only shows successes is a sales pitch; a demo that also names limits is a scientific contribution.

  • If your demo never mentions failure modes, what signal are you sending to someone who might use the system?
  • Why is a "what it doesn't do" slide often more convincing than a "what it does" slide?

A good final demo explains what the system knows, what it does, what it does not do, why the chosen architecture fits the task, and where the main risks remain. That is the difference between a demo and a defensible system.

Six-slide rule: knows / does / doesn't / architecture / humans-in-loop / failures. If you can't tell the story in six slides, you don't yet understand your own system.

sort it Click an item, then click a bucket — or drag and drop.
Prompt chain that turns a question into a structured answer
Webhook that fires when a form is submitted
User preference store (model choice, language, history)
RAG retrieval — embed query, search vector index, rerank
Retry logic with exponential back-off on API failure
Audit trail: every LLM call logged with input, output, latency
Multi-agent: Planner dispatches to 3 workers, Reviewer merges
Batch job: split 500 records, process in parallel, merge
Vector index of all published research in your lab
Cognition Dify
Plumbing n8n
State DB / store

A team presents a literature-triage assistant, shows the routing logic in n8n, the RAG grounding in Dify, explains source and memory constraints, and identifies where human review remains necessary.

▸ Use the instructor's finished build before you build yours feel what "done" looks like — then recreate it

Not loading? https://dify.32dots.de/chat/N3fhWs2RWg9kNaxm

Finished Final systems review and demo
The finished app — use this as your target
ask Ask a question about "Final systems review and demo"
  • No external reading; this is synthesis week

This week isn't about adding nodes — it's about explaining the ones you have. Both tools show up in the demo because real systems use both; your job is to defend the split.

  • **Hiding failures** — the judge will ask. Showing one failure + how you caught it is stronger than pretending there are none.
  • **Architecture as afterthought** — if slide 4 is vague, the whole demo feels like theatre. Know your split cold.
  • **Skipping "doesn't do"** — unbounded systems are unsafe systems. The refusal list is a feature.

What makes a scientific AI project credible even when it is still incomplete?

Solo prep (60 min): finish the 5-slide deck and write the one-page post-mortem. Cohort demo (10 min, scheduled separately): live walkthrough including one deliberately failing input. Rubric: (a) 5-slide deck — problem, architecture (cognition/plumbing/state), eval method, failure modes, next steps. (b) 10-minute live demo. (c) One-page post-mortem naming the biggest surprise and what you would redo.

Deliverable

Live demo, architecture note (1 page), and lessons-learned note (1 page) covering what surprised you about the Dify/n8n split.

Looking back across the 10 weeks, which one card would you insist a future cohort start with — and what would you drop to make room for one more like it?