A 24/7 multi-agent monitoring fleet

What changed. Scheduled collection and synthesis produce artifacts for review; irreversible actions still require a human decision.

Stack. multi-agent orchestration · file-backed memory · scheduled jobs · multimodel routing

Context

An operator running a research and monitoring desk cannot read every overnight feed by morning. Positions, public-market prints, news, and geopolitical watches arrive on different clocks. A monitoring assistant needs explicit source checks and output evidence to distinguish current collection from a stale brief. The studio needed a fleet that would still make sense after a model swap — context in files, not in a vendor’s chat history.

This is an operating system for collection and synthesis. It is not an investment product and it does not publish returns.

Task

Design a set of specialised agents that collect, structure, and criticise overnight, then hand a human a brief at the point of action. Jobs must keep running when one model vendor blips. Success of a job must be visible as an artifact, not as a chatbot saying it is done. Architectural decisions and daily operations must not live in the same process.

What we built

Three agents with separate responsibilities. An operational agent sits on Telegram as the daytime entry point: questions, monitors, morning briefs. A research agent runs in the background — hypotheses, checks against data, writes into the knowledge base without waiting for a prompt. An architectural agent sees the whole system in scheduled sessions: new components, documentation, coordination protocols.

Scheduled jobs cover public-data collection, research and operational checks such as state snapshots, reconciliation and backups. Scenario analysis feeds review briefs and alternative interpretations; it does not authorise action.

Memory is files. A linked long-term record, a kanban for agent tasks, a wiki capped so agents read compiled pages instead of raw dumps, a shared hourly state.json, inbox files between agents, and JSONL reports from every cron. A model change can reuse the stored record, subject to checking that the new model and tools interpret it correctly.

Models are routed by cost and job: a mid-tier model for briefs, a senior model for architecture and synthesis, a local model for cheap watchdogs, a fast external model for parallel red-team narratives, a small model for mechanical extraction.

Risk is layered: an intraday snapshot on a timer and on move triggers; a deterministic morning audit against historical percentiles; a cross-cycle diff that only surfaces material change; a weekly what-if that asks several models for shock narratives and synthesises them. The operational agent does not grade its own homework.

What changed

The desk receives structured digests instead of a blank morning. Collection runs overnight. A person still owns send, spend, and publish. Keeping the operating record on disk supports continuity; a model upgrade still requires compatibility and outcome checks.

What we would do differently

Attach an external evidence check to every cron from the start: the expected artifact structure, source-check time, payload dates and coverage. File modification time alone does not prove freshness; an unchanged hash can be valid when the source was checked and has not changed. File-backed memory was the right bet. The failure mode we learned later on other pipelines — a job that exits zero and writes nothing — was already available here. The dashboard should have treated a missing report as a failed night, not as a quiet one.

Related service: AI agents and automation