RFC: Persistent agent APIs on the Celln execution plane

[AlexsJones]

This follows the external execution-plane RFC. Celln is a natural fit for one-shot agent work: seal a cell, lend declared capabilities, return artifacts, dissolve it. Serving-mode agents are different: Sympozium today keeps a Deployment and HTTP/MCP endpoint alive. What would it take to offer that on Celln without quietly reintroducing an ambient network or long-lived credentials into the guest?

A plausible shape is a host-held ingress/API broker that authenticates and rate-limits requests, assigns each request a capability-scoped session, and talks to a resident cell—or a warm per-request cell—over a narrow ABI. LLM access, MCP, state, and outbound HTTP would remain brokered capabilities; the cell would receive neither raw credentials nor a general NIC. We would need a session/state model, streaming/cancellation semantics, health and restart rules, cell leasing/capacity scheduling, per-request authority ratcheting, and revocation that remains meaningful for a long-lived service.

The key design question: should a persistent API mean a truly resident cell, or an API façade over short-lived cells plus explicit durable state? The latter preserves Celln’s dissolve model more cleanly; the former may be necessary for low-latency stateful protocols. Interested in operational constraints, threat-model objections, and prior art from systems such as Firecracker, gVisor, Modal, or E2B.

[AlexsJones]

We’ve now shipped the first concrete version of this direction in Sympozium v0.10.57 + Celln v0.5.8: a resident native parent keeps live conversation context, with disposable child cells for per-turn work. This is an enduring conversation, not yet a general persistent HTTP/MCP serving API or crash-recoverable context store.

Please join the new release discussion for a plain-English explanation, installation links and feedback on the combined feature. It links back here so the original state/lifecycle questions remain connected.