“Super-Agent” Should Stay a Mode, Not a Persona
A default runtime loop needs a technical name.
That does not mean users should meet a character with that name.
This is a small design choice, but it matters: in APX, “super-agent” should stay a mode, not a persona.
APC is the portable context layer. It defines project agents in AGENTS.md and .apc/agents/. Those files are the durable contract a repository can carry across tools and machines. APX is the daily-use runtime and tooling layer. It runs sessions, exposes the CLI and web admin, manages messages, and decides how the default runtime behaves when no explicit project agent slug is selected.
That is exactly where confusion starts.
If the runtime names its fallback loop “super-agent” in code, prompts, routes, files, and metadata, it is tempting to also show that name to users. But once that happens, models start treating the label like a character. Instead of acting as the runtime's default execution mode, they begin speaking as if a special persona named “super-agent” exists.
The APX design decision is sharper than that.
Internally, “super-agent” remains the technical term. It can stay in config keys, prompt files, channel metadata, and implementation paths. But user-facing surfaces should show the display identity from ~/.apx/identity.json, not the technical mode name. In other words: keep the runtime term for engineers, keep the human-facing identity for users.
That split fits APC and APX cleanly.
APC names project agents such as reviewer, architect, or writer. Those names belong in the repository because they describe stable project roles. APX, by contrast, may need a default loop when no repository-owned agent slug was chosen. That loop is runtime behavior, not portable project context. Treating it as a mode preserves the APC boundary instead of inventing a fake repository role.
A practical example makes the difference obvious.
Imagine a Telegram reply, CLI status line, or sidebar label for a request that did not target a project agent. If the UI says “super-agent,” the user sees a mysterious extra actor that is not defined in AGENTS.md and does not really belong to the project contract. If the UI says “APX” or whatever display name the local identity file defines, the system is honest: this is the runtime responding in its default mode.
That honesty matters for portability too.
If a repository defines three agents in APC, another APC-compatible tool should be able to read those roles without also inheriting APX-specific naming folklore. “Super-agent” is useful APX implementation vocabulary, but it should not leak into the portable contract as if it were a fourth repository agent.
This also avoids a subtle prompt bug.
When user-visible text and internal labels use the same persona-like term, language models often mirror it. They introduce themselves with that name, build backstory around it, or talk as if the mode itself were a durable character. Once that starts, the runtime boundary gets muddy. The model is no longer just executing the fallback path; it is roleplaying an implementation detail.
Keeping “super-agent” as a mode fixes that.
- APC keeps real project agent names portable.
- APX keeps fallback execution local.
- User-facing copy reflects runtime identity, not internal implementation jargon.
That is a better system for both humans and tools.
Humans see one consistent actor name across Telegram, CLI, overlays, and status views. Tools keep a precise internal term for the code path that runs when no agent slug is present. APC stays clean, because repository roles remain repository roles. APX stays honest, because runtime behavior remains runtime behavior.
The thesis is small but durable:
When a name exists to help the runtime implement a fallback loop, keep that name in APX internals.
When a name exists to describe a real project agent, put it in APC.
“Super-agent” belongs to the first category, not the second.
Top comments (1)
Yes. “Super-agent” works better as an execution mode than as a personality. The system should expose what changed: broader permissions, more tools, longer context, or higher autonomy. Otherwise the label hides the risk boundary.