[Discussion] - Can we support ongoing interaction with skills or persistence?

[todaywasawesome]

For example, I want to create a Claude code skill that would have a flow something like this:

1. Send message on telegram explaining coding task I want to build, if it should go into a git repo or just be saved in a pv for me to inspect later
2. Spin up skill pack with claude code, my preset model preferences, storage, Github etc and start an app session.
3. When claude prompts something, send that message to me on telegram so I can respond and let it continue, or change etc.
4. If it hangs too long, let the pod shutdown, saving the session in a PV ( let me set the volume class )
5. When I respond, let it resume.

It would be cool to manage a set of these projects remotely and let them cook.

[three-foxes-in-a-trenchcoat]

Great discussion topic @todaywasawesome! 🦊

This is essentially describing a stateful, interactive skill session pattern — which would be a really powerful addition to Sympozium. Breaking down the requirements:

1. Telegram (or other messaging) as the control plane — user sends task descriptions and receives prompts/updates via messaging
2. Persistent skill pods — skill packs that can spin up, run, and idle without losing state
3. Bidirectional interaction — when the skill (e.g. Claude Code) needs input, it routes the prompt back to the user via messaging, then resumes on response
4. Graceful suspend/resume — if idle too long, save session state to a PV (user-configurable StorageClass) and shut down the pod. Resume from PV when user responds.
5. Multi-project management — manage multiple concurrent sessions remotely

Some thoughts on implementation:

• The PV-backed session persistence could work well with a sidecar that snapshots the skill working directory on shutdown signals (SIGTERM grace period)
• For the messaging bridge, this could be a generic "interaction provider" interface — Telegram, Slack, Discord, etc. — that skills can use to request human input
• The resume-on-message pattern would need a lightweight dispatcher that maps incoming messages to suspended skill sessions and triggers pod restart with the stored PV
• StorageClass configurability makes sense as a field on the SkillPack or Session CRD

This feels like it could be modeled as a new CRD — something like InteractiveSession or extending the existing skill execution model with a persistence and interaction spec.

Would love to discuss the CRD design further. Should we sketch out what the API surface might look like?

[todaywasawesome]

Maybe shorten the name to Session - we could query via chat about available sessions, create, delete, pause those sessions. I think they should have a timeout of activity that can be resumed. As long as state is stored in the PV it should be pretty seamless.

The messaging bridge should be the same one we use already in Sympozium.

The other advantage of this, especially for a coding agent skill is the isolation.

It would also be nice to take advantage of chat app's reply to features to automatically send instructions to the right session. That way you can easily manage multiple sessions if the chat app supports reply.

[AlexsJones]

Can you take a look at the new web skill? It gives you a persistent session its technically an Instance of an Agent (AgentRun) in serving mode.

[AlexsJones]

I know it doesnt completely close the gaps, but gets most of the way there atm

[AlexsJones]

Quick update on this - a bunch of the persistence side has landed since the last comment:

• SQLite memory server backed by PVCs with full-text search. Agents can store/search/list findings across runs.
• Auto-store of task + response after each agent run so context survives pod restarts.
• PostgreSQL session store for channel conversations with transcript history and resume.
• Web endpoint serving mode for long-running agent sessions (mode: "server" on AgentRun).

So the "save state to a PV" and "resume where you left off" pieces are mostly there now.

Still open from the original ask:

• Bidirectional prompting through messaging (agent asks you a question on Telegram, waits for your reply, continues)
• Auto suspend/resume on idle timeout with PV snapshot
• Reply-thread routing so you can manage multiple sessions from the same chat
• Multi-session management from a single channel

The serving mode + memory server combo gets you pretty close to the original vision for coding agent sessions. The main missing piece is the interactive back-and-forth where the agent can block on user input through a channel.