Running, monitoring, upgrading and recovery
4 min read
Running Remy
In steady state Remy runs itself. Once a relationship manager / financial advisor has installed it, their overnight pipeline is a set of scheduled tasks that run as that user, in a fresh chat each, under their own permissions. There is no central batch job to operate: the unit of operation is one user's schedule set.
Run | Trigger | What it touches | Typical duration |
|---|---|---|---|
Inbox | 04:45 daily | Mailbox read; document folders write | Minutes |
Mine (refresh) | 05:00 daily | All connectors read; client memories write | Scales with changed records; usually well under an hour |
Monitors | 05:20–06:10, staggered | Memory read; actions register, alert ledgers, letters write; web search for radar and screening | Minutes each; referrals is the heaviest web run |
Meeting briefs | 06:00 daily | Calendar read; meetings register, briefs write; PDF render | Minutes |
Actions sync | 06:20 daily | Mailbox Sent Items read; actions register write | Seconds |
Dashboard | 06:30 daily | Registers read; dashboard and JSON stores write | Seconds |
The first run per user is different: it mines the whole book once (five clients in parallel), which is the slow step. Everything after is incremental - unchanged records are never reprocessed.
What "healthy" looks like
The dashboard's Overnight card shows last night's run as succeeded.
Every mining and monitor report lists the sources used and none unexpectedly unavailable.
The scheduler's task list shows one enabled task per skill, no duplicates.
The check skill reports skills mounted, connectors reachable, scheduled tasks enabled, side panel resolving, versions consistent.
Monitoring and signals
Signal | Where | Meaning |
|---|---|---|
Refresh did not run | Dashboard Overnight card; scheduler status cache | A scheduled task did not fire or failed. Check platform scheduled tasks, then the connector it depends on. |
Source unavailable | Every run's report; install report | A connector was down or unauthorised. The run limited its conclusions and said so; nothing was guessed. Fix the connector; the next run catches up. |
Web search not connected | Radar, screening, referrals reports | These skills report and stop. Expected where web search is not approved. |
Step skipped | Install report | A step was reported skipped with a reason - valid; silence would be the error. |
Identity unconfirmed | Mining report; identity map | A client could not be matched with confidence in a system; nothing was mined from it. The user or an administrator confirms. |
Version mismatch | Administration tool; version skill | Published skills differ from the local tree. Push or roll back. |
Memory health | Audit skill | Broken links, missing required pages, stale mirrors, unsourced facts, unlogged writes. |
Platform-level logs, audit trail and versioning apply to everything Remy writes, because everything it writes is a knowledge-base file.
Recovery
Situation | Action |
|---|---|
A night was missed | Nothing is lost. The next run reads everything since the last mining-log entry. The user can press Regenerate today for an interim dashboard. |
A connector changed credentials | Re-authorise on the space; runs resume. Sources are checked every run, never cached. |
A user's schedule is duplicated or broken | Re-run the scheduler install from chat - idempotent, one task per skill. |
A memory looks corrupted | Audit it; then update (curate) or redo (re-mine from scratch). Advisor-entered facts survive both; every prior version is in the knowledge base history. |
A page failed to publish | Build-time checks refuse invalid pages before publication; fix the reported check and re-run the dashboard skill. |
Roll back a skill release | Push the previous tree with the administration tool; versions are per service and recorded in a lock file. |
Upgrading
Compare published versions against the new tree with the administration tool (or ask "which version of Remy is running").
Push the new skill tree to the space's skills folder - or take the new platform image where Remy is mounted from it. Configuration (description file, policy files, brand pack) is not overwritten; it lives in the knowledge base, not in the tree.
Run the check skill; run the demo skill against a fixture tree if you want a full walk-through before users see it.
Users pick up the new version on their next run. No reinstall; the dashboard footer shows the new build stamp.
Later releases are additive. Every service and skill is versioned independently, so a capability can be added, retuned or retired without touching the rest.
Backup, retention and offboarding a user
Client memories, registers, letters and dashboards are knowledge-base files: backed up, versioned and retained under the bank's existing policies. Remy adds no store of its own to back up.
When a relationship manager / financial advisor leaves, their home tree is handled by the knowledge base's retention rules. Client memories at team and organisation scope, and the client document folders, are unaffected; a successor's first run rebuilds their second brain from them.
Retention classes and the legal basis for public-source research are confirmed by the bank's records and compliance owners in the design phase.
Remy inherits the platform's residency, retention and backup; it cannot offer what the deployment does not. On-premises or air-gapped deployments constrain model choice and disable web-dependent skills.