persona packs after #1846: what's the intended path for headless / self-hosted seats?

[vedantggwp]

Context

I run a self-hosted relay with several persona agents as standalone buzz-acp seats on a
VPS. No desktop in the loop at runtime. The desktop connects as a client, but the seats
live on the server so they stay up when my laptop doesn't.

I authored the team as a persona pack against PERSONA_PACK_SPEC.md. buzz pack validate
passes. Then I went looking for what consumes it and found the history instead: #297
added --persona-pack / --persona-name to the ACP harness in April, and #1846 removed
them in July as part of unifying the team model around TeamRecord and snapshots. Today
buzz-persona sits in buzz-acp's Cargo.toml unimported, and the spec still describes
buzz-acp as the component that loads packs (sections 6, 10, 12, and the PF table).

So I can't tell if I'm looking at a gap or a decision.

Question

For agents that run as headless buzz-acp seats on a server, what's the intended way to
give them a persona, skills, and behavioral config going forward?

1. If the answer is "TeamRecord + snapshots, packs are desktop-authoring only": is there
   a planned path for snapshots to reach a headless seat (import via CLI, or the relay)?
   And should the spec drop or rewrite the buzz-acp sections so it stops describing the
   removed integration?
2. If a headless pack path is still wanted post-feat(teams): unify team model, snapshot sharing, and PNG memory parity #1846: I'm happy to build it and carry it
   through review. Roughly --pack <dir> + --persona <name> on buzz-acp, resolved
   through the existing buzz-persona resolver, persona prompt into the existing
   [System] block, skills copied to $AGENT_CWD/.agents/skills/ per the spec's
   no-overwrite rule. One persona per process, matching how seats already run. But I
   didn't want to open that PR against a direction you deliberately moved away from
   two weeks ago.

What I do today

A sync script that flattens each persona into the agent runtime's own config (prompt
file, skills dir, one seat env per agent). Works fine. It just re-implements the
deploy-time steps the spec assigns to buzz-acp, which is why I'm asking rather than
assuming.

Related: #2773 (BYOH, which these seats effectively are), #2958 (marketplace RFC leans
on portable personas), #2340 (open examples pack). Closest to a duplicate I found is
#3277 (managed agents only mentionable from the machine that runs them), which is
adjacent but about mentions, not persona delivery. Happy to close this if the plan is
already written down somewhere I missed.

[wolfyy970]

Our deployment is adjacent to this. An always-on Mac Studio runs Buzz and oMLX while laptops connect as clients. Desktop can host agents today, but I want the option to run seats as services independent of a GUI login.

I also need two isolated product teams with per-agent prompts, skills, runtime environment, and MCP configuration. Snapshot v1 omits skills, environment variables, and MCP configuration. buzz-acp still depends on buzz-persona, but does not call its resolver.

Should a headless seat consume a persona pack directly, or a TeamRecord snapshot plus local secret and MCP overlays through a CLI?

I can help implement the selected path. Secret values should remain local in either design.

[vedantggwp]

Same shape here, relay on a VPS with eight hermes-backed seats under a process manager, no GUI session anywhere. I checked the snapshot v1 structs at head to be sure: TeamSnapshot is team meta plus members, and AgentSnapshot is definition + profile + memory, where definition carries system_prompt, runtime, model, provider, respond_to and the timing knobs. So confirmed, no skills, no env, no MCP config in the portable format today. Agreed that secret values should stay local in either design. Either path works for my deployment as long as a headless seat can get persona, skills, and behavioral config without a desktop in the loop. Happy to split the implementation once a maintainer picks a direction.

[wolfyy970]

Thanks, this confirms the deployment pattern is not isolated. The portable definition and local operational overlay split also fits my use case. I’ll wait for maintainer direction on persona packs versus TeamRecord snapshots before starting implementation.