What they want is a framework for persisting stuff... that is an application level service... go ahead and build one.
Clients and daemons end up relying of fairly heavyweight protocols to chat (dbus, various DB protocols, grpc), and it feels cumbersome, and means leaving the native paradigm of the shell anyways when we drift into these protocols.
Its not an agent problem specifically: this is a meta-crisis. There is an ongoing meta-thread about "the tyranny of the application", that it contains its process and is bad at sharing, that the data is the thing and multiple tools ought be able to coordinate around the data. This extends to CLI programs too! They too are really not good at making the state they hold (as both a Model of the data and as a ViewModel over their interfaces) available, extropic.
Plan9 is as close as we've gotten to addressing this. We could implement more 9p protocol or Filesystems in UserSpacE (FUSE) programs to make their state easily available.
Turso has an interesting agentfs, which is just a filesystem that happens to be on Turso, their sqlite compatible rust database. This is a bit generic of a filesystem, isn't very application specific. But it is intended for agent use, and it uses FUSE, so is definitely notable here. It would be neat to see this adapted to expose more interesting application specific payloads. Their intro post: The Missing Abstraction for AI Agents: The Agent Filesystem https://turso.tech/blog/agentfs https://turso.tech/blog/agentfs-fuse
(The sqlite compatible backing here would also allow for interesting SQL based processing of the state too, which could be a bonus; you now have dual interfaces, fs or DB, for the same data)