isanna turnflow
In build
A deterministic kernel for multi-turn conversation, with the model kept outside the execution path.
What it is
Turnflow runs a conversation through a seven-stage pipeline: classify, load session, plan, agent loop, inject results, compose response, persist session. The model proposes a plan; a deterministic validation boundary decides what actually runs. That separation is the whole engine — everything else follows from refusing to let generated text reach an executor directly.
The invariants
- C1
- The plan is the single execution authority.
- C2
- No execution from raw user input.
- C3
- A deterministic validation boundary sits between plan and execution.
- C4
- The language model is never in the execution path.
- C5
- The core remains domain-agnostic.
- C6
- Grounded generation resolves to grounded-with-citations, or refusal.
How it works
- Two execution classes
- Structured mutation and grounded generation are both first-class, and both governed by the same turn invariant rather than by two parallel code paths.
- Domain-free core
- Domain logic registers through a pipeline configuration. The core carries no knowledge of any product built on it.
- Transport adapters
- Telegram, WhatsApp and web chat sit behind one adapter interface, so a channel is a plug rather than a fork.
- Provider-agnostic gateway
- Anthropic, OpenAI or a local Ollama model behind one interface — the provider is a configuration choice, not an architectural commitment.
What is true today
The engine and its pipeline exist in TypeScript on Deno, with the transport adapters and the model gateway in place. The interfaces are still moving and Turnflow is not yet published.