profile-bound-agent-runtimes

/home/avalon/.hermes/skills/software-development/profile-bound-agent-runtimes/SKILL.md · raw

Profile-Bound Agent Runtimes

Use this skill when a product database names an agent/profile for work but the execution layer must prove that messages, jobs, credentials, and tools ran in that exact profile rather than a shared default runtime.

Governing invariant

thread/job
→ profile foreign key
→ opaque runtime reference
→ trusted internal resolution
→ exact profile runtime
→ profile-local connector capability
→ authorization gate
→ canonical business-owned record
→ profile/run-attributed audit, review, job, and UI state

A coherent profile schema is not proof of runtime isolation. Enforced routing is real only when the transport consumes the resolved runtime for every operation and fails closed instead of falling back globally.

Required sequence

Separate the profile router, runtime dispatcher, native connector, and authorization gate. Do not call all four “the connector.”
Inspect the upstream agent runtime for native named-profile routing before building a custom supervisor daemon.
Keep cross-customer isolation at a container/sandbox boundary; multiplex profiles only within one customer tenant when appropriate.
Store opaque runtime references. Resolve URLs, ports, paths, and credentials only in trusted server code.
Materialize private profile homes with restricted tools and profile-local config/secrets.
Make connectors use profile-aware home and scoped-secret APIs, never process-global environment under multiplexing.
Derive business authority from the authenticated profile binding; caller project IDs are selectors, never authority.
Promote a runtime to active only after authenticated profile-prefixed health, toolset, and skill evidence.
Route sessions, chat, runs, history, approvals, interrupts, continuations, and agentic jobs through the same profile runtime.
Prove Normal and two-business Pro isolation in disposable canaries before production cutover.

Development discipline

Preserve dirty/stale primary checkouts; work from a clean current-upstream worktree.
Establish profile/tier/migration/isolation baseline tests first.
Use focused RED→GREEN steps around executable invariants.
Keep live routing in legacy/shadow mode until readiness and isolation evidence is complete.
Commit green milestones independently; identify any intentional uncommitted RED boundary explicitly.
Do not reorganize canonical business records merely because runtime dispatch is unfinished.

Detailed references

Read references/profile-bound-runtime-enforcement.md for the full architecture, multiplex-safe connector rules, Gate identity contract, materialization permissions, job ownership, activation checks, canary matrix, and safe cutover sequence.

Read references/multiplexer-appliance-lifecycle.md for the two-process materialize→sidecar→activate lifecycle, one-contract rule, profile-local model secret rotation, idempotent Gate capability reuse, subtle portfolio/grant authorization checks, health transitions, and real-image appliance proof.