So when you’re thinking about AI systems, safety, and alignment, one principle to keep in mind is the ends and the means, the subject/object dichotomy, the “never confuse a person with a tool” thing Immanuel Kant was always talking about.
“But Lynn, I didn’t come here for a philosophy lecture. What does this have to do with my agents?” you might say.
Well, my astute reader, this is Enlightenment philosophy as a system design principle for smart machines. Let’s debug it.
Because the place where people mess up when they try (and usually fail) to build long-running, memory-based orchestrators isn’t mostly in the clever parts. It happens quietly as a category mistake. Some of it looks like a separation-of-concerns issue. But the deeper failure is a misunderstanding of what kind of machine you’re building.
And it’s not anyone’s fault. Most engineers were trained in a world where software is a means to an end. Request in, response out. Deterministic loops. Stateless services. You can have “smart” code and it still lives entirely inside a harness that owns the flow.
Agentic systems break that mental model, because now you’re building processes that have persistent state, memory, and the ability, even if bounded, to make decisions that aren’t fully dictated by the caller in the moment. That’s the defining trait. State and agency.
Subjects and objects
In this framing, a subject is a smart process that participates in another process as an actor. You invoke inference to manage your email, scan the categories you care about, delete what you don’t, follow up on the threads that matter, maybe even change its own tracking rules based on patterns it notices over time. You can recognize a subject because it has continuity: it carries history forward and uses that knowledge to steer what happens next.
By contrast, an object is a function. A means to an end. Prior to AI, nearly all conventional computing fell into this category. IT was, by default, a tool you point at a task. It could be complicated. It could be clever. It just didn’t persist as an actor across time. It didn’t accumulate inner context and then surprise you later with the consequences of that accumulation.
State and continuity
But reasoning alone doesn’t make something a subject.
State does.
A classic object-shaped LLM process is a RAG call that reads documents, summarizes them on cue, and disappears. It might reason beautifully, but it cannot decide what it is doing. It can’t renegotiate the goal. It can’t wake up tomorrow with a new plan. It’s acted upon, inside a deterministic loop, and it dies when the function returns.
Now take that same model and give it persistent memory, a heartbeat, a planner, tools, and permission to choose what to do next based on what it remembers, maybe instructions like “Remember: Don’t be an assh*le,” and congratulations, you've changed the underlying ontological category by building a subject-shaped process.
Classify the process before you align it
And this is where alignment talk becomes weirdly practical.
A lot of “alignment failures” are really classification failures. People treat subjects like objects and then pretend they’re shocked when they behave like subjects. Or they treat objects like subjects and start projecting intent and strategy onto something that is basically a conversation calculator with amnesia.
Even frontier research occasionally confuses these categories in analysis.
My frame is the production environment, and real world deployments. There, if you want your agentic systems to run smoothly, you’re going to want to stop for a minute and ask which role the LLM is playing, and when. Mark the boundary. Guard it fiercely. Make it explicit in the architecture, rather than loosely implied in your documentation.
Because you can’t align what you can’t classify.