System Registry¶
In autonomous systems, uncontrolled creation leads to chaos. The System Registry validates every component before creation — skills, workflows, automations, cron jobs — ensuring nothing is duplicated and everything has an owner.
Registry Checks¶
Before creating any new component, the registry validates:
- Does it already exist? — Search by name, function, and capability overlap
- Who owns it? — Each component has an assigned maintainer
- Is it active? — Components marked deprecated if unused for 30+ days
- Dependencies? — What other components rely on it
Registry Contents¶
| Component Type | Count | Example |
|---|---|---|
| Skills | 73+ | growth, content, research |
| Cron Jobs | 24 | email-monitor, social-posting |
| MCP Connectors | 30+ | ga4, stripe, shopify |
| Agents | 5+ | growth, content, governance |
Prevention Patterns¶
The registry prevents creation of duplicate skills (e.g., two "email monitor" implementations), overlapping cron schedules, conflicting automation rules, and orphaned components.
Self-Audit¶
Weekly registry audits identify stale components, missing owners, and dependency loops. Results reported to governance agent for cleanup.¶
title: Email Operations description: Autonomous email monitoring, routing, and response for production agent operations
Email Operations¶
The platform autonomously monitors two inboxes (team@ and info@) handling lead qualification, internal routing, research, draft generation, and escalation.
Inbox Architecture¶
| Inbox | Purpose | Agent |
|---|---|---|
| team@example.com | Business operations, growth, partnerships | Growth Agent |
| info@example.com | Inquiries, support routing | General Agent |
Monitoring Pipeline¶
Inbound → Classification → Routing → Draft/Respond → Escalate (if needed)
Classification¶
Emails classified by: lead quality (business domain scoring), urgency, required expertise, and response SLA.
Routing¶
- Sales/partnership → Growth Agent with research context
- Technical/support → Dev team
- Job applications → personal inbox (forwarded)
- Unknown → Manual review queue
Email Standards¶
All outbound emails pass through validation: no AI buzzwords, no emdashes, professional HTML format, verified phone numbers, and signature consistency.
Monitoring Reliability¶
Email crons run every 15 minutes with delivery verification. Failed checks trigger immediate re-runs. A separate forward-handler ensures job application replies reach the correct inbox.
title: Autonomous Scheduling description: 24 scheduled processes for 24/7 autonomous operations — monitoring, publishing, and maintenance
Autonomous Scheduling¶
The platform operates 24 scheduled processes executing on a 24/7 basis: email monitoring, social publishing, video generation, knowledge consolidation, reporting, and self-improvement cycles.
Schedule Categories¶
| Category | Count | Examples |
|---|---|---|
| Email Operations | 3 | Monitor, forward, respond |
| Social Publishing | 5 | Posts, comments, video |
| Knowledge | 3 | GBrain dream, GitHub monitors |
| Monitoring | 4 | Health, MCP directory, release |
| Growth | 3 | Tech research, help-first, HN |
| Self-Improvement | 2 | Daily cycle, system audit |
Cron Architecture¶
All crons run on DGX Spark. Mac Mini handles browser-dependent tasks via remote SSH. Each cron is verified — status checks catch failures and escalate.
Scheduling Principles¶
- Staggered execution — jobs spaced to avoid resource contention
- Retry logic — failed jobs retry with exponential backoff
- Silent success — jobs report only on breakpoints, not routine success
- Manual override — critical jobs have pause/resume controls
Verification¶
Crons are never trusted at face value. The corpusiq-cron-delivery-audit process runs all crons once to verify they actually deliver, checking actual output against expected output.
title: Operational Monitoring description: System health checks, process verification, and anomaly detection for autonomous agent operations
Operational Monitoring¶
A 10 PM daily system health check runs across all 24 crons, verifying execution status, output quality, and system resources.
Health Check Coverage¶
- Cron health — All 24 jobs verified for last successful run
- Disk space — DGX and Mac Mini storage alerts at 80%
- Token validity — All OAuth tokens verified non-expired
- Model availability — Ollama, DeepSeek, Claude endpoints tested
- Email delivery — Outbound relay verified
- GitHub access — Token and push capability tested
Anomaly Detection¶
The system monitors for unusual patterns: cron failure rate spikes, model latency degradation, email delivery failures, and token expiry approaches.
Escalation¶
Issues classified by severity. P1 (authentication failure, database corruption) triggers immediate alert. P2 (cron failure, slow model) triggers next-cycle remediation. P3 (cosmetic, non-blocking) logged for weekly review.
Self-Healing¶
The self-improvement cron at 11 PM analyzes the day's issues and patches skills, updates documentation, and adjusts cron timing to prevent recurrence.