How I use AI
I want to spend less time collecting the work and more time deciding what to do about it.
That has led me to build tools around the parts of my day where information is scattered or a script needs a little judgment. The morning report brings the work together. Smaller command-line tools use a model when the answer depends on what the words mean.
Here are some examples you can explore. Each story explains the real workflow, with examples you can explore. Fictional inputs and simulated responses are labeled where they appear.
A morning report that knows what to ask
From notes, messages and calendar events to a list of work I can actually act on. Walk through the evidence, the duplicates, and the decisions that stay with me.
Walk through a morning →A little judgment inside a CLI
A model picks a diagnostic. Code checks the answer and decides what can run. Try a useful answer, an invalid one, and no answer at all.
Try the decision demo →Picking up where an agent left off
How task checkpoints preserve decisions, next steps and verification across agent sessions.
Explore the examples →Giving an agent a useful health check
How a read-only CLI gathers homelab evidence and keeps missing data visible to an agent.
Explore the examples →From an idea to a shipped change
How I work with an agent from a rough problem through design, implementation and a verified release.
Explore the examples →AI on my own machine
How my local inference setup supports small CLI decisions, and what local execution does not guarantee.
Explore the examples →When the agent gets it wrong
A documented morning-report mistake: treating an old access assumption as fact, and the checks added afterward.
Explore the examples →
What I’m trying to get right
The useful part is deciding where interpretation belongs and where I need an exact check. A model can help me read a situation, but a test result comes from running the test. Permission comes from me. Keeping those boundaries visible makes these tools easier to trust and easier to fix.