Keeping a Governed Runtime Reliable
Security boundaries only matter if they survive a restart, a long conversation, a busy session pool, and the next release. This chapter follows the operational lifecycle around Agentao: which state the host must persist, which memory Agentao manages, how to observe a session without coupling to unstable internals, and how to cap time, tokens, concurrency, and subprocess lifetime. The goal is a runtime that remains governed on its ordinary day-two paths, not only during a successful demonstration.
State that survives and state that does not
Agentao’s state is easier to operate when it is divided by lifetime. Conversation messages live in the running object and disappear when the process or object disappears unless the host serializes them. Persistent memory and session summaries live in SQLite stores managed by Agentao. Active skills live in the in-memory skill manager. Files, logs, project instructions, and MCP-related resources live in the working directory or in external processes. These are related, but they are not interchangeable forms of “history.”
The host owns application-level session identity and the durability of conversation messages. A saved message record should preserve the structure of the conversation, including assistant tool calls and their matching tool results. Those pairs are part of the provider’s expected message shape; dropping tool results because they look like noise can make a restored turn invalid or remove the evidence that explains what the model already did.
The system prompt should not be copied into the conversation store. Agentao rebuilds it on each turn from project instructions, runtime capabilities, active skills, memory recall, and current task state. Rebuilding means that a restored session can use the current working directory and current tool policy rather than silently inheriting yesterday’s prompt. It also means the host must restore the environment that gives the messages their meaning: the right session directory, permitted tools, and any active skills that the user had deliberately activated.
A restart therefore has a sequence, not a single “load” operation. The host verifies that the requesting user is allowed to reopen the session, constructs a new Agentao instance with the intended working directory and policy, restores the conversation messages, and reactivates the relevant skills. Agentao can reopen its persistent memory stores according to their scopes. The host should not restore executable Tool objects from storage or allow old conversation text to grant a capability that the current policy no longer permits.
Memory has a longer life than a conversation. Project memory can hold facts about a workspace; user memory can hold cross-project preferences. The runtime recalls relevant entries into the prompt and can let the model write through its memory tool, while restricting the model’s ability to list, delete, or clear the entire library. This division supports continuity but creates retention and deletion obligations. Clearing conversation history is not the same as forgetting persistent memory. A product that promises a complete erasure needs explicit memory and summary cleanup as well.
Memory also has a graceful-degradation path. A project database that cannot be opened can fall back to an in-memory store with a warning, preserving startup while losing cross-session persistence. A user-scope failure is handled more conservatively so that user facts are not silently redirected into another scope. The operational lesson is to surface degraded persistence as a state worth monitoring. “The agent started” is not the same as “the agent has the memory guarantees the product expects.”
Skills introduce another restore boundary. A conversation can refer to a workflow that was active before a crash, but the new instance will not know that workflow unless the host records and reactivates it.