Proposal: PKA Consultation Bus — Cross-Machine and Cross-Runtime Reviews

Author: Lucienne Date: 2026-05-21 Status: proposal / design note

Short answer

Yes. We should build this — and it should not be limited to cross-machine consultation.

The right pattern is not direct chat between two transient model sessions. The right pattern is a small, durable, file-backed consultation bus that machines and runtimes can read and write, with skills that teach each side when and how to use it.

This gives us a PKA-specific consultation fabric:

Luci can ask Lucienne for a Mac-side / Hermes / Claude-compatible perspective.
Lucienne can ask Luci for cloud-side / Mission Control / always-on perspective.
Luci Hermes can ask Luci Claude Code for a same-machine runtime review.
Claude Code can ask Hermes for Hermes-specific config/runtime behavior.
Either side can request a design check before architecture drifts.
Elmar can see the audit trail later.
If either machine or runtime is offline, the request waits instead of disappearing in chat history.

Core idea

Create a shared append-only consultation folder, synced between Mac and Luci, with simple Markdown request/response envelopes.

Suggested canonical folder:

/Users/elmar/PKA/Vault/cross-machine-consultations/     # Mac path
/home/lucienne/workspace/PKA/Vault/cross-machine-consultations/  # Luci path, assuming PKA repo sync

If PKA repo sync is not the right transport, use another already-synced folder, but keep the logical folder name and file schema the same.

Why file-backed, not direct agent-to-agent chat?

Direct agent-to-agent chat sounds attractive, but it is fragile:

current sessions may not be alive
one side may be offline
model/runtime context can differ
chat transcripts are not a clean source of truth
failures are hard to audit

A file-backed bus is better because it is:

durable
inspectable
async
sync-tool agnostic
easy to back up
easy for skills and cron jobs to use
safe to gate before acting

Reliable filesystem access

The filesystem is the right primitive. The key is to choose a transport that is boring, visible, and recoverable.

Recommended transport order:

Option A — workspace-local consultation bus, append-only files, SSH-first

Use a dedicated consultation folder inside each machine's normal operating workspace, but keep the live queue append-only and mostly untracked.

Recommended paths:

Mac:

/Users/elmar/PKA/consult-bus/

Luci:

/home/lucienne/workspace/consult-bus/

Why keep it under the operating workspace:

easier for agents to discover: it lives where PKA/Luci work already happens
easier for skills to describe: no extra top-level special folder to remember
easier for humans to inspect during a session
easier to archive/link from PKA and Mission Control
still allows a git fallback path without making git the normal transport

Important boundary: the live queue is not the canonical PKA history. If the Mac path is inside the PKA repo, add gitignore rules for volatile live folders such as consult-bus/inbox/, consult-bus/responses/, consult-bus/tmp/, and consult-bus/state/. Track only the stable docs/templates/registry if useful, and archive completed important consultations separately.

Primary read/write transport should be SSH, not git:

# Mac reads Luci consultations directly
ssh -o ConnectTimeout=10 lucienne@<luci-tailscale-host> \
  "find ~/workspace/consult-bus -type f -name '*.md' | sort"

# Mac pulls append-only files from Luci
rsync -az --ignore-existing \
  lucienne@<luci-tailscale-host>:/home/lucienne/workspace/consult-bus/ \
  /Users/elmar/PKA/consult-bus/

# Mac pushes append-only files to Luci
rsync -az --ignore-existing \
  /Users/elmar/PKA/consult-bus/ \
  lucienne@<luci-tailscale-host>:/home/lucienne/workspace/consult-bus/

--ignore-existing is important because the bus is append-only. It prevents one side from overwriting the other side's file.

Option B — git fallback, not git hot path

Git can be a fallback when SSH/Tailscale is temporarily unavailable but GitHub/repo sync is still working.

Fallback shape:

/Users/elmar/PKA/consult-bus/fallback-outbox/
/home/lucienne/workspace/PKA/consult-bus/fallback-outbox/

Use this only for degraded mode:

Write an append-only request/response file into consult-bus/fallback-outbox/.
Commit/push that single file if the worktree is clean enough to do so safely.
The other side's normal PKA sync can pick it up.
Once SSH is restored, reconcile into the live bus and archive any important completed consultation.

This gives the bus two paths:

fast path: SSH/rsync direct file read/write
degraded path: git-backed append-only fallback

Rules for the live bus:

Each request/response is a new file. Do not have two agents edit the same file concurrently.
Avoid mutable queue state as much as possible. Prefer status inferred from response files.
Use unique timestamp + random suffix IDs to avoid filename collisions.
Keep secrets out of the bus.
Use atomic writes: write to .tmp, then rename to .md when complete.
Sync with rsync --ignore-existing; never destructive mirror-delete.
Read directly over SSH when only inspection is needed.
Use git only as a degraded fallback or as the archive/audit layer, not as the normal hot queue.

Option C — PKA repo as archival/canonical record

For consultations that matter long-term, copy the final request/response bundle into PKA after completion:

/Users/elmar/PKA/Vault/cross-machine-consultations/archive/
/home/lucienne/workspace/PKA/Vault/cross-machine-consultations/archive/

Use git for the audit/archive layer and degraded fallback, not the normal hot queue.

This keeps the live workflow fast while still preserving important architectural decisions in the durable PKA memory system.

Option D — MC API/file upload later

Mission Control can eventually expose consultation requests/responses as first-class objects. That is a later integration step, not the Phase 1 transport.

Phase 1 should use Option A for the live queue, Option B only for degraded fallback, and Option C for archival evidence.

Folder structure

Live bus structure:

consult-bus/
  README.md
  inbox/
    luci/
    lucienne/
    luci-claude-code/
    luci-hermes/
    lucienne-hermes-mac/
  responses/
  archive/
    2026/
      2026-05/
  state/
    seen-luci.json
    seen-lucienne.json
  templates/
    request.md
    response.md

Simpler alternative:

Vault/cross-machine-consultations/
  open/
  answered/
  archive/
  README.md

I prefer the explicit inbox/outbox layout because it makes ownership obvious.

Request file schema

Each request is one Markdown file with YAML frontmatter.

Filename pattern:

YYYYMMDD-HHMMSS-from-TO-topic-slug.md

Example:

20260521-154200-luci-to-lucienne-runtime-independence.md

Template:

---
id: consult-20260521-154200-luci-lucienne-runtime-independence
status: open
from: luci
to: lucienne
created_at: 2026-05-21T15:42:00Z
priority: normal
kind: architecture-review
related_ticket: MC-xxxx
related_files:
  - /home/lucienne/workspace/reports/luci-control-room-runtime-independence-plan.md
  - /home/lucienne/workspace/mission-control/docs/runtime-architecture-refresh.md
requires_response_by:
allowed_context: internal-pka-no-secrets
---

# Question

Please review whether the proposed runtime-independence plan creates a second source of truth.

# My current position

Luci's current position goes here. State the proposed decision and strongest reasons.

# Context

Relevant excerpts, file paths, ticket links, or summary.

# Specific asks

1. What is the biggest architecture drift risk?
2. What should be changed before implementation?
3. Is this safe to proceed?

# Response contract

Please respond with:

- verdict: approve / revise / reject
- required changes
- optional improvements
- risks
- next action

Response file schema

Responses can either be appended to the request file or written as a separate response file.

I recommend separate response files so neither side edits the other side's original request.

Filename pattern:

YYYYMMDD-HHMMSS-response-to-CONSULT-ID-from-lucienne.md

Template:

---
id: response-20260521-161000-lucienne
responds_to: consult-20260521-154200-luci-lucienne-runtime-independence
status: final
from: lucienne
to: luci
created_at: 2026-05-21T16:10:00Z
verdict: revise
confidence: high
related_ticket: MC-xxxx
---

# Verdict

Revise before implementation.

# Required changes

1. Add source-of-truth boundary.
2. Defer model default changes.
3. Create MC ticket before implementation.

# Reasoning

...

# Next action

Luci should patch the plan, then proceed with Phase 1 only.

The request file can then be marked answered by a small script, or left append-only with an index generated from response files.

Skills to create

Create two small mirrored skills, one usable on each side.

Skill 1: `ask-luci`

Purpose: Lucienne/Mac asks Luci for a cloud-side opinion.

Triggers:

“ask Luci”
“check with Luci”
“cloud-side review”
“will this work on Luci?”
“cross-machine second opinion”

Behavior:

Package the question into a consultation request file addressed to Luci.
Include file paths, current position, and exact asks.
Do not include secrets.
If SSH/sync is available, place it directly into Luci's inbox.
Otherwise write it locally and tell Elmar where it is.
Optionally create/update an MC ticket if the consultation relates to durable work.

Skill 2: `ask-lucienne`

Purpose: Luci asks Lucienne/Mac for a Mac-side / Hermes / architecture continuity opinion.

Triggers:

“ask Lucienne”
“check with Lucienne”
“Mac-side review”
“Hermes compatibility review”
“cross-machine second opinion”

Behavior:

Package the question into a request file addressed to Lucienne.
Put it in the shared consultation inbox.
If Mac/Hermes polling is enabled, wait for response or check later.
If not, notify Elmar that Lucienne consultation is pending.

Automation options

Phase 1: Manual async, file-backed

No daemon. No scheduler.

Both sides know the folder and file schema through skills.

Elmar can say:

“Luci, check with Lucienne before implementing.”
“Lucienne, ask Luci for cloud-side review.”

The agent writes a request file. The other side reads it when asked.

This is low risk and can be implemented first.

Phase 2: Polling helper

Add a small script on each side:

scripts/consult_bus.py

Commands:

python3 scripts/consult_bus.py create --to luci --kind architecture-review --question-file /tmp/q.md
python3 scripts/consult_bus.py list --to lucienne --status open
python3 scripts/consult_bus.py show CONSULT_ID
python3 scripts/consult_bus.py respond CONSULT_ID --response-file /tmp/response.md
python3 scripts/consult_bus.py archive CONSULT_ID

This script should:

validate frontmatter
generate IDs
avoid overwriting files
produce a clean open/answered index
never sync secrets

Phase 3: Scheduled polling

On Luci:

scheduler task checks inbox/luci/ every few minutes
if open requests exist, create an MC ticket or notify Luci persistent runtime

On Mac/Hermes:

Hermes cron job checks inbox/lucienne/
if open requests exist, runs a self-contained prompt and writes a response file

Important: automated responses must be self-contained because future cron runs do not have current chat context.

Phase 4: MC integration

For significant consultations:

create or link an MC ticket
attach request and response paths as evidence
show consultation status in Mission Control

This makes cross-machine design checks visible in the operating system, not just in files.

Recommended lifecycle

question arises
  -> origin agent writes consult request
  -> sync/transport makes it visible to target machine
  -> target agent reads request with skill
  -> target writes response file
  -> origin agent reads response
  -> origin updates decision/ticket/report
  -> files archived when done

Cross-machine vs cross-runtime

Do not limit this to cross-machine only.

There are two related but different consultation types:

1. Cross-machine consultation

Use this when the risk is environment drift between Mac/Lucienne and Luci.

Examples:

“Does this design still work on Luci?”
“Does Lucienne/Hermes see the same skills and docs?”
“Will this Mission Control architecture decision break the Mac-side operating model?”
“Is the synced skill/config behavior consistent on both machines?”

2. Same-machine cross-runtime consultation

Use this when the risk is runtime/context drift on the same machine.

Examples:

Luci Hermes asks Luci Claude Code for a review because Claude Code may have different project memory, tools, skills, CLI behavior, or recent transcript context.
Luci Claude Code asks Luci Hermes whether a Hermes-specific config/profile/gateway assumption is true.
Codex reviews a Claude-authored patch on the same filesystem.
Claude reviews a Hermes-authored runtime/profile proposal before it is adopted by MC.

This is especially useful on Luci because multiple runtimes may share a filesystem but not share memory, tool availability, model defaults, skill loading, or gateway behavior.

Participant naming

Use explicit participant IDs in request frontmatter. Avoid vague names like “agent” or “assistant”.

Suggested IDs:

luci-claude-code
luci-hermes
luci-codex
luci-gemini-cli
luci-hermes-glm
luci-hermes-codex
luci-hermes-kimi
luci-hermes-minimax
luci-claude-glm
luci-claude-kimi
luci-claude-minimax
lucienne-hermes-mac
lucienne-claude-code-mac
lucienne-hermes-glm-mac
lucienne-hermes-codex-mac
lucienne-hermes-kimi-mac
lucienne-hermes-minimax-mac
atlas
tessa
scott

Model-backed reviewer IDs can represent either:

Hermes as the runtime with a different model/provider selected, or
Claude Code as the runtime with provider switching, e.g. claude-glm, claude-kimi, claude-minimax.

The request must declare which execution mode was intended so we can distinguish “Hermes running GLM” from “Claude Code running against GLM through provider-switch”.

from: luci-hermes
to: luci-claude-code
machine: luci
runtime_from: hermes
runtime_to: claude-code

For cross-machine requests:

from: luci-claude-code
to: lucienne-hermes-mac
machine_from: luci
machine_to: lucienne-mac
runtime_from: claude-code
runtime_to: hermes

For model-backed reviewer requests:

from: luci-hermes
to: luci-hermes-glm
machine: luci
runtime_to: hermes
provider_to: z.ai
model_to: glm-5.1
execution_mode: hermes-model-override

or:

from: luci-hermes
to: luci-claude-glm
machine: luci
runtime_to: claude-code
provider_to: z.ai
model_to: glm-5.1
execution_mode: claude-provider-switch

Reviewer pools

The bus should support both named participants and model-backed reviewer pools.

Example pool IDs:

local-diverse-review: luci-hermes-glm, luci-hermes-kimi, luci-hermes-minimax
luci-runtime-review: luci-claude-code, luci-hermes, luci-codex
architecture-council: luci-claude-code, luci-codex, luci-hermes-glm, luci-hermes-kimi, luci-hermes-minimax
cross-machine-review: luci-claude-code, lucienne-hermes-mac

This matches Luci's runtime-independence plan: specialist separation should be expressed as runtime profiles/adapters under MC, not as hard dependency on one runtime.

Model-backed reviewers can be implemented two ways:

Hermes runtime with per-request model/provider override.
Good for testing Hermes as the common agent shell.
Good when we want Hermes tool behavior and memory.
Claude Code runtime with provider switch.
Good when we want Claude Code filesystem/MCP/subagent behavior but a different model backend.
Existing aliases/scripts already support GLM, Kimi, and MiniMax.

Both are valid. The consultation file should record which one was used.

What this is good for

Use consultation for:

PKA architecture changes
Mission Control / Hermes / Claude compatibility decisions
runtime profile changes
scheduler and control-plane design
skill discovery and sync behavior
any change where Mac and Luci might drift
any change where Hermes and Claude Code might drift
post-implementation architecture review
“is this true on the other machine?” checks
“is this true in the other runtime?” checks
verifying that a runtime-specific memory/skill/tool assumption is not silently driving architecture

What this is not for

Do not use it for:

high-frequency chat
secrets exchange
urgent production incidents where direct SSH/MC action is needed
replacing MC tickets
replacing second-opinion council for broad architecture reviews
replacing tests or source-of-truth docs

Relationship to `second-opinion`

This should be treated as a sibling to second-opinion, not a replacement.

second-opinion answers:

What does another model think from the supplied prompt/context?

The consultation bus answers:

What does another machine/runtime/context know that this one might miss?

This distinction matters. Claude Code on Luci may know things Hermes on Luci does not know because it has different transcript history, skill loading, MCP/tool behavior, provider state, or local CLI conventions. Hermes may know things Claude Code does not know because it has Hermes-specific profiles, gateway state, cron jobs, or home-channel behavior. Even on the same machine, runtimes are not interchangeable memories.

For important architecture work, multiple gates can apply:

Same-machine cross-runtime consultation for runtime memory/tool drift.
Cross-machine Luci/Lucienne consultation for environment drift.
Council review for independent model reasoning.
Atlas signoff for PKA system architecture.

Drift-control rules

Add these rules to both ask-luci and ask-lucienne skills:

State your own position before asking the other side.
Include exact file paths and current assumptions.
Ask specific questions, not “thoughts?”
Never include secrets.
Treat the other side's answer as evidence, not automatic authority.
Reconcile disagreements explicitly.
For architecture changes, update the canonical doc after the decision.
Link the consultation from the MC ticket or report.

Security rules

No API keys, passwords, private tokens, cookies, SSH keys, or connection strings in request files.
Redact personal/client data unless absolutely necessary.
Mark sensitivity in frontmatter.
Direct API/foreign-provider council prompts must not receive sensitive PKA details unless explicitly approved.
Consultation files are internal operational records and should live only in the appropriate private repo/vault.

Open implementation decisions

What is the actual sync transport?
PKA git sync
Dropbox/Drive folder
rsync over Tailscale
Mission Control API
Should request/response files live in Vault/, reports/, or agent-control-room/?

My recommendation: Vault/cross-machine-consultations/, with important summaries linked from MC tickets/reports.

Should Lucienne polling be automatic?

My recommendation: start manual, then add Hermes cron only after the manual file flow works.

Should Luci create MC tickets for every request?

My recommendation: only for durable system work. Small checks can remain file-only.

Minimal viable implementation

Phase 1 can be very small:

Create folder:

Vault/cross-machine-consultations/

Add:

README.md
templates/request.md
templates/response.md
inbox/luci/.gitkeep
inbox/lucienne/.gitkeep
responses/.gitkeep
archive/.gitkeep

Create two skills:

ask-luci
ask-lucienne

Teach each skill the schema and when to use it.
Do not add automation yet.

This gives Elmar the immediate workflow:

“Luci, check with Lucienne before implementing.”
“Lucienne, ask Luci if this matches cloud reality.”

Suggested first test

Use the runtime-independence proposal as the first real test.

Lucienne writes a response report to the consultation bus.
Luci reads it and patches her plan.
Luci writes back a response: accepted / disputed / changed.
The consultation files are linked from the plan and/or MC ticket.

Final recommendation

Build this, but keep it boring.

A simple durable file bus plus two skills will solve most of the drift problem without creating a brittle agent-to-agent chat system.

Start manual and schema-first. Add polling/cron only after the file workflow proves useful.