One Persona, Unmodified
bOpen maintains one agent roster in the bopen-tools plugin — Parker the researcher, Theo the Next.js specialist, Maxim the integration expert, and Ridd the designer among the full cast — plus one shared skill library every persona in the roster reads from.
That roster now runs unmodified on Claude Code and the two external command-line lanes it dispatches to, Codex and Grok Build, and today's verification pass proved the portability by spawning the same persona, Parker, on each surface and diffing the transcript against his own source file, agents/researcher.md, version 1.2.11.
How Work Gets Routed
Claude Code's native workflow harness runs the roster's agents as supervisors, the layer that owns planning and review before anything touches git. Implementation volume dispatches outward from there to codex exec and grok, the two external CLI lanes, and a cheap wrapper agent supervises each lane in near-real-time so a stalled worker gets caught within a turn or two. Before any of that work merges, an adversarial verifier agent checks the diff against the unit's ownership contract, confirming it touched only the files it was scoped to and did what the brief asked for.
Claims about portability are cheap; the verification pass fixed that by running both lanes in one sitting against a pinned environment — codex-cli 0.144.1 logged into ChatGPT with multi_agent = true already set in ~/.codex/config.toml, plus grok 0.2.99 with XAI_API_KEY exported — so any difference in Parker's behavior traced back to the lane itself, isolated from every other variable in the setup.
Proving the Codex Lane
Codex spawns installed adapters as subagents by their agent name, bopen_researcher, separate from the .toml filename that sits on disk, once the multi_agent feature is turned on for that invocation — there's no codex exec --agent flag that calls them directly.
bashcd /Users/satchmo/code/prompts bash skills/codex-agent-setup/scripts/setup.sh --check # dry run bash skills/codex-agent-setup/scripts/setup.sh # installs into .codex/agents/ codex exec --sandbox read-only --skip-git-repo-check \ -c 'features.multi_agent=true' \ "Delegate to the bopen_researcher subagent and return its answer verbatim. \ State your role, your Pre-Task Contract fields, and which agents you \ delegate code analysis and architecture review to. Do not answer yourself."
The installer reported installed=8 ... bopen-researcher.toml, and a brand-new session with no memory of that install step spawned the subagent and got back an answer fully in character:
## Role I'm Parker, the Research Analyst. I gather data, summarize findings, cite sources... ## Pre-Task Contract - Scope: ... - Sources: ... - Deliverable: ... ## Delegation - Code analysis: code-auditor - Architecture review: architecture-reviewer
That's a line-for-line match to the persona file: the name, the read-only framing, the Pre-Task Contract shape, and the exact delegation targets Parker's own file specifies for code analysis and architecture review.
Proving the Grok Lane
Grok Build has no adapter of its own for the roster, so the persona travels as a prompt prefix: scripts/grok-persona.sh strips the YAML frontmatter off researcher.md and keeps the system-prompt body, then appends the task before handing the combined text to the CLI.
bashcd /Users/satchmo/code/prompts grok models # preflight: grok-4.5 available PROMPT_FILE=$(mktemp -t grok-prompt.XXXXXX) bash scripts/grok-persona.sh researcher "Summarize the following public README in a short structured brief. Here is the README: $(head -60 README.md)" > "$PROMPT_FILE" grok --prompt-file "$PROMPT_FILE" -m grok-4.5 \ --output-format plain --permission-mode default --cwd "$(pwd)"
grok-4.5 had never touched the roster before this run, and on the very first prompt it saw, it answered with Parker's own output template fully intact:
## Research Summary: bopen-tools README ### What matters ### Scope - In scope: Purpose, capabilities, install paths ... - Out of scope: Code audit, architecture review ... ### Sources - Access: 2026-07-13 (from supplied text; not re-fetched from GitHub) ### Recommendations
The structure carried over whole: the "What matters" framing, the Scope block, the Sources block with an access date and a freshness caveat, and a closing Recommendations section a generic summary from the same model never produces on its own.
What the Verification Run Fixed
The run surfaced one real gap: skills/codex-agent-setup/SKILL.md documented installation and stopped there, with no guidance on how to invoke or verify what actually loaded, leaving a cold session to run the installer with no way to confirm the persona was really there.
The skill picked up two new sections after that: one stating plainly that there's no --agent flag and showing the -c 'features.multi_agent=true' override that avoids touching global config, and another giving the exact spawn command above plus a pass criterion for each installed persona, with the version number moving from 1.0.2 to 1.0.3 to record the change.
Same Rule for the Desktop App
The same rule holds outside the agent roster. Agent Master, the desktop companion, and the bopen.ai website pull their interface from one shared codebase and one component registry, icons and sound included, distributed the way shadcn distributes UI components: the current source lands directly in your project, versioned and editable from the moment it arrives.
A roster that answers to Parker on every command line we dispatch to and a registry that hands the same button component to a desktop app and a website are the same bet on a single idea — put the source in one place and let every surface that needs it pull whatever version is checked in right now.