I stopped calling them "agents," and my system got more honest
A few months ago, I had an idea for a build. Thanks to @Jake Van Clief 's folder architecture I succeeded. I built the thing! But then someone had a question about what I had built that turned out to matter more than I expected: are the things I built actually agents? I'd been calling them that out of habit. Then the question forced me to be precise, and being precise changed the design. Sharing the three things that came out of it, because I was being loose with the word, so I post as a cautionary tale based on all the hype around "agents" right now. 1. "Agent" in 2026 means an autonomous reasoner — establishes its own path, it adapts, it learns. But there's an older meaning: a thing that acts — that has a scope, runs different types of operations, produces different effects. My things are the second kind not the first. They can't learn, can't self-modify, can't pick their own goals. Once I admitted that out loud, I stopped saying "agent" unqualified and started saying bounded executor. That not a bad thing — it was me being honest about what I had designed. Here's the interesting thing, an autonomous agent can't be audited with certainty, because what I will do next isn't predetermined. A "bounded executor" can. I removed the autonomy feature, on purpose! If you're building "agents," ask yourself which of the two words you mean, the answer changes what you can promise about them. 2. Test for drift with identity, not observation. "Drift" changes quietly over time and is something most people try to monitor for: watch outputs, catch anomalies etc. I went the other way. Every component definition in my system is content addressed: it has a hash derived from its exact content. So, the drift test isn't statistical, it's binary. Same hash at time A and time B and BOOM! byte identical! Different hash > there's a recorded, authorized change I can point to. There is no third case. The idea here is to make drift unable to happen silently by fixing that thing's behavior to an inspectable definition.