A Visible Agent Name Should Not Double as the Agent Profile

One easy way to make an agent system confusing is to let one label do two jobs.

In APX, the visible agent name and the active agent profile should stay separate.

That separation matters because APC and APX solve different problems.

APC is the portable context layer. It gives a project stable files like AGENTS.md, .apc/, agent definitions, skills, and other committed context that can travel with the repository.

APX is the daily-use runtime and tooling layer. It decides how that context runs on a real machine: CLI, web admin, Telegram, ACP, routines, direct engines, or external coding runtimes.

A display name belongs to the runtime identity side. A profile belongs to the runtime behavior side.

If you mix them, both become harder to trust.

What the repo already says

The APX codebase keeps this boundary explicit.

resolveAgentName() reads the super-agent display name from ~/.apx/identity.json, with a fallback to super_agent.name, then to "APX". That is the user-facing label.

The CLI help describes apx profile differently: it installs, activates, and configures the super-agent's "line of work," and says that with no profile active, APX behaves exactly as it always has.

Those are not the same concern.

One answers, "What do users see this agent called?"

The other answers, "What kind of work package is currently shaping the default runtime behavior?"

Why APC makes this easier

APC already keeps project agents separate from runtime identity.

A project agent in APC has a stable slug, role, model, and optional skills. That definition is part of the repository contract. It should not change just because someone wants the default APX assistant to appear as APX, Ops Desk, or another local name in Telegram or the web UI.

That is exactly why APC works as a portable layer: project truth can stay reviewable while runtime presentation stays local.

APX then adds its own runtime-only layer on top:

• identity fields for how the default assistant presents itself
• profiles for the default assistant's line of work
• channels and routines that use those choices on the current machine

What goes wrong when the two collapse

If the visible name also selects behavior, small cosmetic changes become risky.

Imagine renaming the default assistant from APX to Release Desk because that reads better in Telegram. That should change the label users see. It should not silently install a release-management behavior package.

The inverse problem is just as bad.

If you activate a profile like secretary, APX should gain that workflow package without pretending the assistant's public name must also become Secretary on every surface. Otherwise a behavior switch leaks into UI identity, logs, and user expectations.

Keeping the two separate preserves a clean rule:

• identity answers who the assistant appears to be
• profile answers what line of work it is optimized for right now

Practical example

These two commands should remain independent:

apx identity show
apx profile use secretary

The first is about runtime identity.

The second is about runtime behavior.

Neither should rewrite APC project agent files, because APC owns project context, not local presentation choices for the default runtime assistant.

That is the deeper APC/APX split in miniature.

APC keeps portable project meaning in the repo.

APX keeps local execution choices flexible: display name, active profile, channels, engines, and surfaces.

Small design rule, big payoff

When an agent platform lets one field carry both identity and behavior, debugging gets harder fast.

Users stop knowing whether a rename changed branding, prompts, capabilities, or all three.

APX is stronger when it keeps those concerns apart.

Let APC describe project agents.

Let APX decide how the default assistant should appear today.

And let profiles shape runtime behavior without hijacking the assistant's visible name.