A model is a poor place to do anything code can do. Code is cheaper and gives the same answer every time, so LifeOS uses it wherever it can and saves the model for judgment, language and the parts no code can handle.
The build order
Every capability is built in the same order:
-
Start from the goal.
-
Write deterministic code that does the work.
-
Wrap it in a small command-line tool that does one thing well and composes with others.
-
Write workflows, which are prompts that decide when and how to run the tools.
-
Put a skill on top that routes a request to the right workflow.
Skip a layer and the system gets shaky. A prompt that does arithmetic, parses dates or formats output will eventually get it wrong. The same job as a function gets it right every time and can be tested.
Why the command line
When every operation can be run from the command line, it can be scripted, tested and chained. The assistant uses the same tools you would, and so do hooks, scheduled jobs and other agents. Tools that follow the old Unix idea, one job each with plain text in and out, snap together into larger work without any of them knowing about the others.
In practice
Checking whether a site’s links all resolve is a script. Deciding which broken link matters most is a judgment. In LifeOS the script runs first and hands its results to the model, and the model doesn’t crawl the site by hand.