THE PARTS, AND WHY THEY MATTER
A workflow is more than a prompt.
The graph decides what runs next. The model supplies judgment where you deliberately allow it. Your application owns state, permissions, evidence, and stopping.
01 / Contracts and context
Define the input, shared state, and expected output before writing prompts. A Python TypedDict documents shape; it does not validate model output at runtime. Validators do that work.
Store evidence and decisions as structured fields. Pass each node only what it needs. A checkpoint is execution memory, not a user profile or a vector database.
02 / Nodes, tools, and agents
A node is a function. A tool does a bounded job such as retrieval or a calculation. An agent uses a model to decide actions in a loop. Giving five functions job titles does not create five intelligent coworkers.
This lab is a controlled workflow with a practice writer. Start here; add autonomous tool selection only where it earns its complexity.
03 / Routing and recovery
Conditional edges turn evidence into control flow. No evidence stops the run. Invalid output gets a limited repair attempt. Valid output reaches a person.
A repair changes the content using feedback. A transport retry repeats a failed request, usually with backoff. This lab teaches repair; it makes no network requests to a provider.
04 / Checkpoints and review
The browser pauses at LangGraph node boundaries and resumes with updateState(). The Python version uses interrupt() and Command(resume=...) with durable SQLite storage.
An interrupted Python node restarts on resume. Keep external effects after approval and use an idempotency key so a retry cannot publish or charge twice.
05 / Traces and evaluations
Observe inputs, outputs, tool results, routing, errors, latency, and usage. Those are execution records, not a model’s hidden reasoning.
Keep test cases for good evidence, unknown citations, empty retrieval, failed repair, approval, rejection, and recovery after a restart. A second model’s opinion is another signal, not ground truth.
06 / From lesson to service
Keep the interface on the site. Run live graphs behind an authenticated service with per-user checkpoint ownership, bounded concurrency, timeouts, cancellation, and usage limits. Never execute a visitor’s arbitrary Python on the public server.
Start with this fixed graph and editable configuration. Python needs a Python-capable host; a JavaScript graph needs a compatible runtime. LangGraph does not require DigitalOcean or its own managed hosting.
Where this fits in Osiris
| Layer | This release | Live service needs |
|---|
| Interface | Graph, inspector, experiments, trace export | Authenticated run controls and streamed events |
| Orchestration | Browser LangGraph + matching Python starter | Server-enforced rules and per-user isolation |
| Intelligence | Deterministic practice writer | Approved visitor-funded Osiris connection |
| Persistence | Page memory; SQLite in Python | Durable database with ownership checks |
| Actions | Draft approval/rejection only | Allowlisted tools and effect-specific approval |
As checked October 8, 2026, Osiris’s hosted ChatGPT plan adapter remains in draft PR #191. This workshop neither activates it nor routes usage to an operator-funded API.
Choose the tool for the job
Plain Python first for a short linear sequence. LangGraph here because branching, shared state, repair, and pause/resume are the lesson. A drag-and-drop editor can come later; understanding the runtime comes first.
Next build challenge: add a retrieval-repair branch when the draft needs more evidence, with a separate retrieval budget. After that, try two specialists in parallel and define how their state updates merge.