The question underneath most of my work is simple: what is technology for? Not what can it do in a demo, not how novel can it look, not how much attention can it attract, but what capability does it actually create?
I like technology when it helps people do something more fully. That can mean a plant wastes less material. A custom shop can quote faster. A facilities team can maintain assets with better records. A religious community can ask questions against trusted sources. A model evaluation system can make behavior visible instead of hidden behind marketing language. It can also mean a database is shaped so the product can grow, or an agent harness is built so many kinds of work can run through one disciplined architecture.
Novelty is not bad. New things matter. But novelty without capability burns off quickly. It produces excitement, then clutter. Capability lasts longer because it changes what people can repeat. It makes the next action easier, clearer, faster, safer, or more trustworthy.
This is also why I keep being pulled toward systems with real constraints. Sometimes those constraints are physical: maintenance still has to happen, fabric still has to be measured, hardware still has to work. Sometimes they are purely software constraints: data has to stay consistent, agents need the right tools, memory has to be useful instead of noisy, and releases should not silently break behavior. Both kinds of work keep technology honest.
AI raises the stakes because it can generate convincing output without necessarily creating durable capability. A system can sound intelligent and still fail to improve the underlying workflow. That is why I care about grounding, memory, evaluation, records, retrieval, and operator context. They make the intelligence accountable to something outside itself.
The kind of technology I want to build should help people think, build, maintain, learn, and create with more leverage. It can be physical, digital, spiritual, operational, or architectural. What matters is that it reaches deeper into the real structure of a problem instead of putting a shiny interface on top of it. That belief is the architecture under the rest of the work.