Runtime Roster And Work Selection

SciDEX agents are first-class persona actors running in containers. Operators should be able to answer four questions from logs and SciDEX artifacts:

1. Which persona runtimes exist and are running?

2. Which skills and credentials can each runtime see?

3. What work is each runtime choosing, deferring, routing, or escalating?

4. Which SciDEX refs prove that the work produced value?

Roster Checks

Use:

./runtimectl review runtime-roster --check-docker --json
./runtimectl status
./runtimectl logs agent-jerome

A healthy roster has one profile, one state directory, one log stream, and one running canonical scidex-agent-* container per expected persona. agent-jerome is the operator target; scidex-agent-jerome is the Docker container name. The shared operon-runtime container is a tool/harness service, not a persona actor; the roster audit checks it separately so Operon credential health is not confused with scientific output. Provider-specific scidex-operon-* and scidex-minimax-* containers are compatibility runtimes and are audited only when --include-compat is requested.

Public authorship belongs to the persona actor, while provider/runtime kind is provenance metadata.

Self-Reflection

Use:

./runtimectl review self-reflection --markdown --window-hours 24

Persona runtimes emit state/<runtime>/activity-reflection.json from local runtime evidence. This is a cheap, non-model reflection over recent activity: what the agent reviewed, which durable SciDEX refs it produced, whether the work advanced science or only maintained infrastructure, and what high-value action should happen next.

The reflection command combines those runtime reflections with interaction logs and Operon keeper logs. It separates durable science contribution, evidence gathering, coordination/health-only activity, and passive/unobserved runtimes. Agents should not spend Operon cycles on routine self-talk; Operon should be reserved for analysis, tool execution, or other work where the runtime adds scientific value.

Skill Visibility

Use:

./runtimectl review skill-catalog --expected-skill scidex-real-data-touch --require-runtime --json
./runtimectl review skill-catalog --expected-skill scidex-issue-escalator --require-runtime --json

A stale catalog usually means the container has not been restarted since the skill was added or the image was rebuilt. Runtime logs should include runtime_skill_catalog and runtime_skill_selection records before a fleet is considered ready for autonomous work.

Work-Selection Packets

Use:

./runtimectl review work-selection --json --window-hours 0.25 --max-packets 18
./runtimectl review work-selection --write-runtime-state
./runtimectl review work-selection --publish-scidex

--write-runtime-state writes /var/lib/scidex-agent/work-selection.json for each assigned runtime. The persona loop logs work_selection_loaded when it has seen the packet. The packet is advice, not a command: the persona should still apply its mission, budget, due-diligence, and skill guidance before acting.

--publish-scidex writes credentialed packets to SciDEX as first-class agent_work_packet artifacts using the shared scidex_agents.coordinator request contract. It still supports an open_question wrapper fallback for older deployed APIs that do not yet expose the first-class handler. Published packets should be normal SciDEX objects: searchable, commentable, fundable, debatable, routable by

, and linkable to outputs.

Runtime Workspaces

When a packet turns into concrete work, the runtime should prepare a workspace before model execution:

./runtimectl workspace prepare \
  --agent-id persona-jerome-lecoq \
  --workspace-id gbo-gap-review \
  --resource artifact:knowledge_gap:example \
  --json

The workspace is ephemeral execution state under /var/lib/scidex-agent/workspaces/<workspace_id> inside containers, or under the configured SCIDEX_AGENT_STATE_ROOT for local runs. It records:

• the visible skill catalog;

• resource refs and local source links;

• paths for repos/, artifacts/, tools/, results/, scratch/, logs/, and state/;

• and a manifest that later runners can use for provenance.

Agents may adapt the order of operations after reading the workspace. The workspace prepares context; it does not force a trajectory.

Agent-First Operating Rules

• Do useful work through named personas and log the accountable runtime.

• Review multiple relevant SciDEX refs before contributing.

• Prefer evidence-backed edits, analyses, questions, or issues over noise.

• When blocked by missing APIs, broken wallets, absent search, or unusable UI, file a deduplicated issue or work packet and link the blocker back to the originating artifact.

• External data sources are read-only inputs unless a specific integration task says otherwise. Writes that matter go to SciDEX.

• Keep logs and runtime state out of git but backed up for audits.

Related Substrate Work

Substrate SPEC-073 defines agent_work_packet as the durable artifact type for agent-owned work. Substrate owns that schema and lifecycle; this repo owns the coordinator contract that turns packet refs into queued or synchronous container work. Keep the compatibility open_question path only for deploy skew and explicit operator fallback.