The evolving application
Engineering Troubleshooting Workbench
A fictional online shop has a real-looking incident. You collect evidence, apply rules, make the workflow visible, and only then introduce a model where language and ambiguity are genuinely useful.
It runs on your machine
Python first. Docker optional.
The normal route is a Python virtual environment and a terminal command. Streamlit opens a local browser view so you can inspect evidence, state and decisions. Docker comes later as an optional production-shaped route.
It is safe to explore
Synthetic data. Read-only tools.
No real cloud account, Kubernetes cluster or production logs are required. The first scenarios use local fixtures, and every tool is deliberately narrow and inspectable.
Try the deterministic checkpoint
Run the Workbench before we add a model.
Clone the companion project, follow its macOS, Windows or Linux setup, then start with workbench. For the visual version, run python -m streamlit run app.py and change the two visible rule inputs. The first checkpoint needs no API key and no Docker.
How the system grows
Deterministic investigator
Rules, evidence, state and known routes.
Model-assisted harness
Structured proposals without giving away control.
Context and memory
Relevant runbooks, citations and durable state.
Bounded agent
A small read-only loop with budgets and a stop condition.
The boundary that keeps it honest
The model does not run the system.
model/provider → generates text or a structured proposal
harness → interprets and validates it
policy → allows, denies or asks for approval
tool/runtime → performs permitted work
state/events → record what happened
control loop → decides whether work continuesThe companion begins with a deterministic checkpoint: local fixtures, explicit rules and a visible decision trail. The code is there to be changed carefully, tested, and connected back to the lesson that explains why it behaves as it does.