Floor 5 of 5, the foundation of the tower
Lantern
A confident wrong answer is worse than “that part isn’t working right now”.
The problem
AI tools tend to cover for their own failures. A speech service times out and the assistant answers anyway, in the same calm voice, as if nothing happened.
The rules I set
- Everything runs on the machine, and the app works offline.
- A degraded provider is a named state on the screen, never a hidden one.
- Memory stays local and is scoped to the task it belongs to.
What I built
A Next.js console in an Nx monorepo. Local providers for speech in, language and speech out sit behind health checks. Conversation memory lives in PostgreSQL with pgvector, work is queued and retried through Redis, and a small Three.js view shows which providers are healthy.
How it’s layered
- Console Chat on one side, provider health on the other.
- Providers Speech in, language model, speech out, each with a health check.
- Memory PostgreSQL and pgvector, local and scoped.
Decisions
- A health check runs before every call, and a failed one changes what the console says.
- Every answer keeps a trace of which providers were involved and how they behaved.
- Retries back off and stop. After that the console tells the user, it doesn’t keep guessing.
Where it stands
A demo system, running only in the model. It’s the floor I’d point to for how I think about failure: show it, name it, keep the trace.
Next.js · TypeScript · Nx · PostgreSQL + pgvector · Redis / BullMQ · Three.js