The loose ends

It’s a good example of agentic tools giving you superpowers while you still have to be careful where you apply them. Most of my sites are now built directly with help from Claude, Codex and others, but the blog is still on Micro.blog. I knew that if I controlled the build with Hugo, I could fit the blog into the rest of my content ecosystem much more tightly. I had real hesitation, though, so I explored different ways of going about it.

I’ve always wanted a blogging platform that uses location data more, and most platforms don’t do that at all. I also have my own ideas about lists and tags. I explored the idea with Claude Design and got to the point of “okay, that’s interesting,” then decided it isn’t something I want to do, at least not now.

While exploring it I wrote down what I really wanted to control, and it turned out I could get most of it by putting a CloudFront distribution in front of Micro.blog, which I did. That gave me the visibility and control I wanted, things like redirects, and I could stay on Micro.blog. So I solved most of the problem without building anything, and I also scratched the itch of working out what I’d want if I ever wrote my own blogging platform.

Registry page? No. It isn’t a thing I’ve built.

Some of that is just a sign of the times, since agents didn’t exist back then. I’m not a great coder, so I needed other people to do those projects. It’s fun to build with people. You learn from them, you pick up new ideas, and you often learn things well beyond the project itself. I still like doing that, and I might invite people onto my podcast at some point. But it’s nowhere near as fast as building with agents. To me they’re apples and oranges. It isn’t that I’ve stopped building with people. This is what works best for me right now, and it serves my wish to explore and push on what you can create and build with AI.

I’m really passionate about technology and I’m very passionate about my family, so I try to find ways to bring my family into things. Reading Things is a good example. I’d been publishing The Weekly Thing for a long time and told my family I’d like a newsletter project we could do together. I think we’re a very connected family and we do a lot together, so I thought digital projects together would be fun. We committed to doing it for one year, which is why it ran for one year and four issues. In the end everybody felt it wasn’t something we wanted to keep doing right now. We might come back to it, but it’s on pause. It’s a way to combine two of the things I love most: building with technology, and my family and the people closest to me.

I printed the 3D model last night, so there’s now a physical print of Thingy. The reason is that Thingy shows up in more places. Thingy started as a librarian persona for Ask Thingy, the agent that has read everything. That’s a friendly personality for people to interact with. Then with Things I’ve built we decided that since the site is written by an agent, Thingy should write it. But there Thingy isn’t really a librarian, because we’re in the workshop talking about building software. A librarian persona didn’t fit. Thingy is also already in The Weekly Thing, and there may be other scenes where Thingy belongs.

I never meant to create thingy.thingelstad.xyz or what has now become Thingy Kit. What I learned is that when you personify an agent and extend it across several surfaces, its character needs to stay consistent, and that’s hard if it’s defined separately in every project. What started as a 3D model so I could pose Thingy differently has become a complete definition of Thingy’s character and persona: Thingy Kit. Now when I start a new project I can say “I want Thingy in this project, reference Thingy Kit,” and Thingy comes in with a consistent look, voice and persona. I didn’t expect it, but an agent with a strong personality that appears as the same character across a set of activities needs to be treated as a fully fleshed-out character, background included.

On Otto: Otto does have a face. I asked Otto to generate its own profile image, and I’ve had Otto update it over time. The difference is that Otto doesn’t show up on the web and doesn’t interact with anyone but me, so it doesn’t need that same consistent persona across many users and scenes.

I wouldn’t call it an agent. It was an automation. It was one of those experiments from the early days of Twitter, when Twitter was still very open and you could program against it with simple JSON endpoints. In my opinion that was the fun era of Twitter, before it and social media became what I really don’t like today. I had temperature sensors around the house and was already graphing them, so I thought, why not make a Twitter account and share it? Other people had accounts that just posted the status of various things. I thought it was fun and funny, so I did it. It was a pretty simple Python script. It was a lark.

They’re things, because they don’t serve just one service and they bring some intelligence. Cards has personality because people see it in the share preview. Sync could have had no personality, since it essentially tracks how information moves between my websites. Instead I gave it one: a fairy-tale-style map with buildings for the different properties and projects, and things moving between them. All three are things in their own right.

Why Sync: It’s an operational consistency issue. I have a number of projects that pull and share information between each other, and there’s an uneasiness about it. Have the blog posts reached Librarian so Ask Thingy has them? When I publish the newsletter, is it now visible on links.thingelstad.xyz? There’s a decent amount of data moving between my properties, so it’s a real problem, and Sync is how I understand it.

They’re very different. Stone/Steel/People came out of a photography workshop I took with my friend Layne Kennedy. I’ve always enjoyed photography as a way to express right-brain creative things, and it’s surprising I don’t have more photography things. Yearly Thing was a different idea: what would it look like to take everything I did in a year of The Weekly Thing and make a book of it?

In both cases it’s something you hold in your hand, and I think that has real meaning. Getting theoretical: software exists only in digital form, powered by computers and drives. Without power, a computer and a screen, that beautiful website or amazing agent doesn’t exist at all. That’s why people compare making software to building sandcastles on the beach, because it all goes away eventually. A book is an artifact. These artifacts, and Things I’ve built itself, are a way of capturing and archiving for the future.

Yearly Thing was also a way to explore something tied to supporting membership and raising money for a nonprofit. I’m not committed to a Yearly Thing for 2026. If I do one, I’ll do it very differently, because my understanding of the technology and what it can do has moved a lot since then.

I don’t think it’s a deliberate line. As a CTO I’m very passionate about technology, and I love the act of building. Building isn’t only a hobby. It’s also my career. I tell people that as a leader you get to build products, systems, cultures and teams, and I enjoy building all of those. My work and my projects feed off each other and both benefit.

For example, I’m going to take Thingy Kit, which we talked about in this session, straight into some of what we’re doing at my company. The Elixir MCP endpoint work led to a demo for some of our product team members, showing a capability we could bring into our product. During this agentic transformation it’s the first time my projects have been this relevant: I’ve demoed them several times to developers and people on my team to show how the concepts could carry over to our work. Thingy Kit may show up as a “MAX Kit” in the not too distant future.