Should an agent be code or a declared thing with its own runtime?

I've been building agents for a while and keep facing the same issue. An agent begins with just a few lines of code—a prompt, a couple of tools, a loop. That works fine at first. But the ones that go into production expand quickly; they require more tools, budgets, retries, human involvement, and escalation rules. All of this ends up mixed throughout app code, environment variables, and any logging that gets added. Then, six months later, someone will ask, "Why did the agent do X in March?" or "Can we revert that change to its tool access?" There's no straightforward answer because the agent was never a cohesive entity. It was just code spread across the app. It seems like agents are in a similar position to where databases were before ORMs or infrastructure before Terraform. The approach is fine until the agent grows beyond its inline code form, and nobody agrees on what to do next. My co-founder and I have come up with a specific solution, so I want to be clear that we are developing in this area. The idea is to stop thinking of the agent as code and start seeing it as a manifest. You define the agent in a single file, specifying its tools, limits, and policies, as well as where human input is needed. You run it in a designated environment, and each run provides a trace of what actually occurred. The agent becomes a defined, versioned, and reversible entity instead of logic scattered throughout an app. This is similar to the shift Terraform made for infrastructure. It's open and live; there's a link in the comments for anyone who wants to try it out. Do you encounter this issue in production, or does your framework (like LangGraph) manage it well enough? How do you handle versioning, rollback, and figuring out "what did it do and why" today? Is the idea of "the agent as a defined artifact, not app code" reasonable, or is it overcomplicating things for most cases?