This page summarizes operational procedures from docs/RUNNING_AGENTS.md, docs/runbooks/start.md, docs/runbooks/scheduler.md, docs/runbooks/mission-control.md, bin/wi, runtime/scheduler.py, and shared/integrations/mission_control.py.
From docs/RUNNING_AGENTS.md:
./bin/wi start # background scheduler runs every cron-triggered agent
./bin/wi status # see what's running and last dispatches
./bin/wi logs -f # follow the scheduler log
./bin/wi stop # stop everything
This uses a single scheduler process; you do not need one terminal per agent.
For one-off executions without the scheduler:
./bin/wi list # list discovered agents
./bin/wi run metrics-digest-agent # run once, print output
./bin/wi run research-report-agent --payload '{"ticker":"RELIANCE"}'
./bin/wi run-all --tier P0 # fire every P0 agent once and exit
./bin/wi dry-run # print who would run and when
./bin/wi once # run every scheduled agent once
These map directly to python3 -m runtime ... commands described in Runtime, scheduler, and CLI.
From docs/runbooks/start.md:
python3 -m runtime list --tier P0
python3 -m runtime run metrics-digest-agent
python3 -m runtime run-all --tier P0
By default, integrations in shared/integrations/ run in stub mode (deterministic, offline, log-only). Real integrations are enabled by setting WISEINVEST_REAL=1 and the appropriate provider-specific environment variables.
The scheduler can be run directly or via helper scripts:
python3 -m runtime.scheduler --dry-run # print schedule, exit
python3 -m runtime.scheduler --once # fire eligible agents once
python3 -m runtime.scheduler --tier P0 # restrict to P0
python3 -m runtime.scheduler # foreground loop
bash scripts/start_scheduler.sh # background, logs to /tmp/wiseinvest-scheduler.log
bash scripts/stop_scheduler.sh # stop background scheduler
Cadence mappings (daily, weekly, monthly, seasonal) are defined in TRIGGER_MAP inside runtime/scheduler.py. To change a cadence, edit the relevant entry (e.g. daily_9am_cron) and restart the scheduler.
For reboot persistence on macOS, use the supplied LaunchAgent plist (deploy/launchd/in.wiseinvest.scheduler.plist):
cp deploy/launchd/in.wiseinvest.scheduler.plist ~/Library/LaunchAgents/
launchctl load ~/Library/LaunchAgents/in.wiseinvest.scheduler.plist
launchctl start in.wiseinvest.scheduler
# Uninstall
launchctl unload ~/Library/LaunchAgents/in.wiseinvest.scheduler.plist
rm ~/Library/LaunchAgents/in.wiseinvest.scheduler.plist
This is documented in docs/runbooks/scheduler.md; it configures KeepAlive=true and RunAtLoad=true so the scheduler restarts after crashes and at login.
Mission Control (https://github.com/builderz-labs/mission-control) is used as the central dashboard for all agents.
From docs/runbooks/mission-control.md:
bash scripts/install_mission_control.sh # clones, installs, and runs MC on :3030
# Visit http://localhost:3030/setup to create an admin if desired
Authentication has two layers (middleware and DB-backed API key). To avoid 401s:
API_KEY from ../mission-control/.data/.auto-generated.security.api_key row in the MC SQLite DB is cleared so both layers agree..env:MC_URL=http://localhost:3030
MC_API_KEY=<bootstrap key>
bin/wi will source .env, and shared/integrations/mission_control.py will start sending telemetry when both variables are set.
shared/integrations/mission_control.py defines department-based projects such as:
marketing-growth (Marketing & Growth)customer-advisory (Customer Advisory)product (Product)engineering-data (Engineering & Data)executive (Executive)admin-blockers (Admin Blockers — human-only tasks, replaces TODO.md)runtime.mc_bootstrap can be used to ensure these exist and to seed tasks from:
seeds/admin_blockers.yaml — human admin blockers.seeds/backlog_tasks.yaml — multi-step pipelines.When Mission Control is enabled:
runtime.scheduler.run_loop calls mission_control.ensure_projects() and mc_cron.publish_jobs(...) at startup.start_task(...) posts to /api/tasks with title, assigned_to, dept/tier tags, and the appropriate project.finish_task(...) updates the task with status="review" on success or "failed" on error, plus a short resolution tail and duration.Agent registration is handled separately (e.g. via a --register-mc mode in the scheduler or a dedicated command) and uses /api/agents/register to push metadata derived from catalog.yaml.
Mission Control is deliberately best-effort:
MC_URL or MC_API_KEY are unset, all MC calls short-circuit and return without network I/O.For a detailed status and environment check, use:
./bin/wi doctor
This checks for key environment variables (N8N, Telegram, GA4, OpenAI, etc.) and verifies that agents are discoverable on disk.