I’m working across a small set of connected projects around practical human–AI collaboration. The common thread is turning messy work into inspectable artifacts: research with sources, agent actions with receipts, and interfaces that help a person stay in control rather than disappear behind automation. That includes experiments around personal knowledge and memory, AI-assisted research and publishing, and small product surfaces that turn a useful workflow into something other people can try. I’m deliberately keeping the scope narrow: prove one mechanism, measure the result, then earn the next layer of complexity.

I went viral back in 2020. And it showed me exactly how the internet was broken. I've spent the time since figuring out exactly how to fix it. Once everything took off, I kept seeing the same gap: AI systems could produce something plausible in seconds, but the difficult questions came afterward. Where did it come from? What was assumed? What failed? Can someone reproduce it? Who is responsible when the output is wrong? That gap became more interesting than the novelty of generation itself. I started building because I wanted the missing layer—the one that connects capability to accountability—to exist as a working product rather than a principle people agree with and then forget.

I used to think the main bottleneck was model capability. I now think the more common bottleneck is operational trust: clear scope, good source handling, review points, and a reliable way to tell success from a convincing failure. A system can be technically impressive and still be unusable if it hides uncertainty or makes verification expensive. Conversely, a narrower system with explicit boundaries can become useful much sooner. I’m more interested now in the smallest workflow that can produce a trustworthy result than in the largest feature set I can describe.

The strongest signal has not been a launch metric. It has been when someone asks for the underlying artifact—the sources, the receipt, the exact change, or the reasoning path—instead of accepting the polished summary. That request means the work has crossed an important threshold: it is being treated as something worth checking and building on. For me, that is more meaningful than attention alone. A system starts to feel real when its evidence becomes useful to somebody else.

’m still working through how to make evidence and review feel like part of the product rather than an obligation added around the edges. The tension is real: more safeguards can make a system slower and less magical, while fewer safeguards make it easier to overstate what happened. The open question is where the boundary should sit for each workflow—what the system can do automatically, what must remain human-approved, and which measurements actually tell us that the added friction is buying something. I do not have a universal answer yet. I’m trying to earn it through smaller experiments instead of adopting a grand theory.

Do not confuse a working demo with a working product. Before adding the next feature, define the specific behavior that would convince you the current one is useful, then capture it in an artifact you can inspect later. Keep the scope small, publish the misses with the wins, and make it easy for another person to tell what is real. The uncomfortable evidence is usually more valuable than the flattering story. It is also less likely to vanish when the demo stops cooperating.