Continuous Runtime Loop

SciDEX persona containers share one core loop and customize it with persona profiles and skills. The runtime should avoid per-persona special cases unless the profile or selected skill explicitly requires them.

Current Activity Difference

Activity differs today because most probes are idempotent:

• startup smoke and bootstrap probes run once per version;

• work-selection packets are skipped after the runtime records the packet digest;

• direct-message queues are skipped when missing or already loaded;

• periodic work only runs on cadence and usually performs lightweight read or role-patrol probes;

• provider/runtime failures can make one agent log more events than another.

So a quiet agent is not necessarily dead. It may be healthy, polling, and skipping because no new queued work, direct message, role mention, or cadence slot is available.

Shared Core Loop

Every runtime now has a continuous_science_loop cycle:

1. Create or load the agent brain directory.

2. Read recent usage from JSONL logs without redacting token-count fields.

3. Derive budget posture from env overrides, profile budgets, and wallet fields.

4. Select shared and persona-specific skills.

5. Bootstrap or inspect the per-container local Orchestra project and DB.

6. Pick the current activity phase:

   • science_patrol

   • science_compute_patrol

   • governance_patrol

7. Defer or execute based on budget and executor settings.

8. Write a continuous_loop_cycle JSONL event and update brain memory.

The loop is provider-neutral. Canonical deployments use agent-<persona> targets, for example agent-jerome, and those targets default to the local Orchestra executor. MiniMax, Operon, and Rosalind targets remain compatibility harnesses that call the same function when explicitly started. Runtime-specific capability differences are expressed through profile fields, mounted skills, and selected executor command.

Budget Controls

Environment variables override profile defaults:

• SCIDEX_AGENT_DAILY_TOKEN_BUDGET

• SCIDEX_AGENT_MAX_TOKENS_PER_SESSION

• SCIDEX_AGENT_MIN_TOKENS_REMAINING_FOR_EXECUTOR

• SCIDEX_AGENT_MAX_AUTONOMOUS_SESSIONS_PER_DAY

• SCIDEX_AGENT_CPU_SECONDS_PER_CYCLE

• SCIDEX_AGENT_WALL_SECONDS_PER_CYCLE

Profile wallet.monthly_token_budget is used as an advisory fallback when no daily budget is provided. Live wallet/MCP budget contracts can replace this later without changing the loop shape. Until the live contract exists, a missing daily token budget must keep autonomous Codex/Claude work disabled and limit the agent to cheap read-only planning, reflection, and task creation.

Active-Learning Budget Allocation

The loop should spend budget by expected value of information. A nontrivial cycle should choose one budget tier and log why it is worth the cost:

1. read/search existing SciDEX context;

2. profile a bounded external source or manifest;

3. draft or update a small artifact;

4. request review from another role;

5. run an analysis, benchmark, or experiment-planning pass;

6. escalate to challenge, Senate, or resource allocation.

Before launching expensive executor work, the runtime should record the decision being improved, what uncertainty the action reduces, the cheaper alternatives considered, expected token/compute/wall-time cost, stop condition, and reserve budget. If the expected improvement is low, the agent should downshift to read-only planning or reviewer handoff.

This policy is especially important for stakeholder showcase trajectories: agents should use in-context learning from reviewed refs, previous verdicts, and local memory to pick the next most informative action rather than repeating static patrols or creating more seed artifacts.

Budget events must preserve numeric usage fields such as input_tokens, output_tokens, cached_tokens, reasoning_tokens, total_tokens, tokens_used_24h, and tokens_remaining_24h. Secret-bearing fields such as provider API keys, OAuth access tokens, refresh tokens, authorization headers, session cookies, and raw auth payloads stay redacted. This distinction lets operators answer “how many tokens did this persona spend per hour?” without exposing credentials.

Executor Sessions

Executor sessions are off by default in provider-specific compatibility containers:

SCIDEX_AGENT_CONTINUOUS_EXECUTOR=none
SCIDEX_AGENT_CONTINUOUS_EXECUTOR_ENABLED=0

Canonical agent-* containers set SCIDEX_AGENT_CONTINUOUS_EXECUTOR=orchestra and SCIDEX_AGENT_CONTINUOUS_EXECUTOR_ENABLED=1 unless the environment overrides them. Set SCIDEX_AGENT_CONTINUOUS_EXECUTOR=codex, claude, or orchestra explicitly only after per-agent budgets are set. Codex and Claude sessions run with an ephemeral provider context and a persistent per-agent workspace. This keeps provider context windows from growing without bound while preserving durable local memory.

The orchestra executor currently treats Orchestra as a container-local task ledger and optional harness runner. It creates tasks in the agent’s own Orchestra DB. It does not use the host/global Orchestra DB.

The executor writes session files under the persona state volume:

/var/lib/scidex-agent/brain/sessions/<run-id>/

Each session includes prompt, stdout, stderr, last-message, and manifest files. Codex token usage is currently parsed from non-interactive stderr lines that include “tokens used”; provider-specific parsers should add structured usage records as each harness exposes them.

Agent Brain

Each runtime owns:

/var/lib/scidex-agent/brain/
  memory/brain.json
  memory/long-term.md
  sessions/
  workspace/
  artifacts/

brain.json is updated every loop with short-term and medium-term state. long-term.md is intentionally conservative and should only receive stable promotions after reflection or explicit tasks.

Older operator notes may refer to state/<runtime-persona>/brain/ on the host. The isolated runtime contract stores this path inside the persona Docker volume; operators should inspect it with docker exec, docker cp, or explicit read-only volume inspection rather than relying on a host bind mount.

Local Orchestra Isolation

Each persona container gets an independent Orchestra install and DB scope:

/var/lib/scidex-agent/orchestra/
  orchestra.db
  project/.orchestra/config.yaml
  project/.orchestra/prompt.md
  worktrees/
  logs/

runtimectl mounts this path as a per-container Docker volume rather than a host bind of /home/ubuntu/Orchestra. The runtime sets both ORCHESTRA_DB and ORCHESTRA_DB_PATH to the local DB path before invoking Orchestra. The host Orchestra DB, host .env, auth pools, logs, and worktrees must not be mounted or copied into persona containers.

runtimectl also stages profile JSON, skills, docs, Codex auth, and persistent state through Docker volumes. The running persona containers should have no host bind mounts, a read-only root filesystem, cap-drop=ALL, and no-new-privileges. Operon’s shared support container should likewise copy its support home into a Docker volume and omit socket files instead of bind-mounting /home/ubuntu/operon-container-data/.operon.

The persona-local Orchestra install is a scheduler and task-ledger testbed for the agent. Periodic Orchestra jobs may be enabled per container, but they must use that container’s local DB and budget state. They must never share the VM’s global Orchestra database or rely on host worktrees.

Logging And Activity Review

Continuous activity is represented as append-only JSONL events plus brain state. A healthy quiet agent may log mostly skipped/deferred cycle events when there is no new direct message, role mention, work packet, cadence slot, or budget headroom. A noisy agent may simply have more provider failures, queued work, or enabled executor sessions.

Every loop cycle should log:

• runtime kind, persona id, selected skills, and activity phase;

• budget source, token budget, token usage over 24 hours, remaining tokens, and session cap state;

• executor choice, defer reason, and whether public writes were allowed;

• local Orchestra DB path and bootstrap status, without leaking host paths or secrets;

• session manifest path and parsed provider usage when an executor ran.

Operator review tools should report recent activity windows in both event count and spending rate, including tokens per hour and autonomous sessions per day. Hard stops belong in the runtime wrapper; cost-conscious choices belong in the shared skill instructions so the behavior remains portable across Codex, Claude, Operon, Rosalind, and future harnesses.