Explore a persistent multi-channel agent runtime

[ineedjet]

Summary

Explore a persistent runtime for agent processes that need low latency, retained session context, multiple input channels, and interactive debugging beyond ephemeral GitHub Actions jobs.

Motivation

The previous StarCast experiment exposed recurring friction with Actions-only execution: cold starts, opaque debugging, lost conversational context, and difficulty refining non-interactive regulations. These observations remain useful even though the old implementation is unsupported.

Candidate architecture

• a persistent agent service loads regulations and tool definitions once;
• a gateway maps each inbound event to an output channel and role/playbook context;
• Telegram, GitHub, and HTTP are transports rather than separate agent implementations;
• production mode sends results automatically;
• an attached development mode holds outbound results for inspection, correction, and approval;
• configuration changes are proposed through pull requests and hot-reloaded after merge.

Acceptance criteria

• Compare an Actions-only model with a persistent service using concrete latency, isolation, state, cost, and operability criteria.
• Define gateway, session, tool, secret, and output-channel boundaries.
• Specify how development attach avoids leaking hidden reasoning while still exposing actionable traces, tool calls, and pending outputs.
• Decide when multiple roles share one runtime versus use isolated runtimes.
• Produce a small proof of concept only if the architecture remains justified after comparison.

Non-goal

Do not restore compatibility with the removed autonomous editorial pipeline.