A system that asks before it acts
Why Jarvis lets models propose but never decide, and what that did to the architecture.
Draft for review. This piece has not been published yet.
The first version of Jarvis I imagined was a chat window that could do things. The version I built is almost the opposite: a database with rules, where a language model is allowed to suggest and nothing more.
Propose, never decide
Every time a model wants something to happen (send a message, spend money, change a task), it produces a proposed action. That proposal is just data. It goes through the same path as everything else:
- a policy engine checks it against kill switches, budgets and risk tiers;
- if the risk is high enough, it waits for my approval;
- only then does an executor run it, and check afterwards that it actually worked;
- the whole thing is written to an audit log that is hash-chained, so the past can't be quietly edited.
The model never calls a tool directly. It can be wrong, confused or overconfident, and the worst it can do is propose something I say no to.
What this did to the architecture
Designing it this way forced three decisions I'm glad about:
- State lives in the database, not in the prompt. Jarvis doesn't "remember" by stuffing context into a conversation. It remembers because the facts are rows in SQLite.
- There is exactly one way out. People are only contacted through an outbox table. Nothing reaches anyone by accident.
- Silence means no. An approval nobody answers expires into a denial.
The nice side effect: the entire core runs with no API key and no internet. I could test every rule before a real model was attached. When the real model layer finally went live, it slotted into a system that already knew how to say no.
The interesting part of an AI system isn't the model. It's everything around it that decides what the model is allowed to do.