Blog

I keep coming back to the same thing with agents: the model is not the product. The runtime is.

Give a model tools and it will do something interesting. Getting a system you can trust is different work. You have to decide what state exists before the next call, what the model is allowed to see, what actions it can take, and what evidence has to be observed before the workflow moves forward.

The parts I care about are boring in the right way: state machines, typed actions, validators, trace logs, escalation paths. The model can propose, classify, draft, or choose between bounded actions. The system around it owns the things that have to stay true.

Models are going to be wrong sometimes. What matters is whether the platform around the model can still enforce the properties you care about when that happens.

Most product ideas are too big at the start. I like shrinking them until the real workflow shows up.

A broad product makes you guess about everything at once: the user model, the data model, the interface, the edge cases, the business rules, and the trust boundary. A narrow workflow forces the important parts into view.

This is especially true for tools that touch money, rights, compliance, support, or other high-stakes decisions. The first useful version is usually a small machine: gather the right inputs, show the work, produce a useful artifact, make escalation obvious.

A workflow like that can still grow into a larger product. It just starts from a place where the invariants are visible. A blank chat box with a long prompt taped to the front usually hides the hard parts.

Personal finance is a good agent problem if you keep the scope honest. Stock picking gets the attention. The useful daily work is keeping a clean model of the plan.

The core job is ordinary and valuable: collect the facts, normalize them, find the gaps, and keep the plan current as life changes. Income, expenses, cash buffer, debt, taxes, insurance, goals, timelines, and risk tolerance all belong in one working picture.

I would use agents as planners and reviewers. One can turn messy statements into categories. One can compare the current plan against simple rules. One can draft scenarios: what changes if rent goes up, a bonus arrives, a loan is paid down, or the emergency fund target changes?

The boundary matters. Every number should have a source. Every recommendation should show the assumptions. Anything consequential should be decision prep, with the responsibility kept clear.

Built that way, the agent becomes a living planning desk: organized, recalculating, and clear about the gaps.

This site is just files: hand-written HTML, CSS, a little JavaScript, and a build script that copies things into a deploy directory.

I like that. Open the HTML, change the sentence, refresh the page. A link works or it is broken. A page says something or it is empty. The whole site can be opened locally without a database, a package install, a build cache, or a framework upgrade.

Modern frontend tools are useful when the product needs them. For this job, plain files are enough. I don't want site maintenance to become the project.

The point is to have a place to write things down. A small page that loads quickly and says what it means is still a good object.