Hermes Agent Integration Examples — Connect Your Business Tools¶

What's Inside¶

Integration	File	Core Value
Slack + GitHub	`slack-github.md`	PR notifications, issue tracking, deployment alerts
Email + Calendar	`email-calendar.md`	Meeting scheduling, follow-ups, availability management
CRM + Analytics	`crm-analytics.md`	Lead scoring, pipeline forecasting, attribution
Database + Reporting	`database-reporting.md`	Scheduled queries, dashboards, anomaly detection

Common Architecture Patterns¶

Every integration in this collection follows a consistent architectural pattern:

The Three-Layer Model¶

┌─────────────────────────────────────────────────┐
│                 SOURCE LAYER                     │
│  (Data producers: GitHub, CRM, Email, DB)       │
└────────────────────┬────────────────────────────┘
                     │ MCP Server (read-only tools)
┌────────────────────▼────────────────────────────┐
│              AUTOMATION LAYER                    │
│  Hermes Agent + Cron Scheduler                  │
│  - Query source systems on schedule             │
│  - Compute, enrich, detect anomalies            │
│  - Format output for destinations               │
└────────────────────┬────────────────────────────┘
                     │ MCP Server / API calls
┌────────────────────▼────────────────────────────┐
│              DESTINATION LAYER                   │
│  (Action takers: Slack, Calendar, Sheets,       │
│   Notion, Email, CRM write-backs)               │
└─────────────────────────────────────────────────┘

Key Design Principles¶

1. Read-Heavy, Write-Cautious Source systems are accessed with read-only credentials. Destinations receive writes only for well-defined, low-risk operations (posting a Slack message, updating a spreadsheet cell). Autonomous destructive actions (deleting records, sending external emails, modifying production configs) require explicit human approval gating.

2. Cron as the Orchestrator Cron expressions are the heartbeat of integrations. Each automation runs on a defined schedule appropriate to its urgency:

Urgency	Cron Cadence	Use Cases
Near real-time	`/5 * * ` or `/10 * * * *`	Incident detection, deployment monitoring
Hourly	`0 * * * *`	Traffic check, error rate monitoring
Daily	`0 7 * * *`	Morning briefings, daily reports
Weekly	`0 8 * * 1`	Pipeline forecasts, weekly roundups
Monthly	`0 6 1 * *`	Financial close, monthly reviews

3. Idempotency by Default Every scheduled task should produce the same result if run twice. This means: - Queries use relative date windows (current_date - 1) rather than hardcoded dates - Destination writes use upsert patterns (update if exists, insert if not) - Notifications include a unique deduplication key

4. Failure Visibility Silent failures are worse than no automation. Every integration includes: - Success/failure logging with timestamps - Alerting on repeated failures (3 consecutive failures → escalate) - A health dashboard showing last-successful-run per automation

Getting Started¶

Step 1: Choose Your First Integration¶

Start with the lowest-risk, highest-visibility integration. For most teams, that's Slack + GitHub — it's immediately useful, non-destructive, and easy to verify.

Step 2: Set Up MCP Servers¶

Each integration guide lists the MCP servers you need. Configure them with read-only credentials wherever possible: - GitHub: personal access token with repo:status, public_repo, and read:org scopes - Gmail/Calendar: OAuth with readonly scopes - Database: dedicated read-only user on a replica - CRM: API keys with read-only access

Step 3: Run in Dry-Run Mode¶

For the first week, configure automations to log their intended actions without executing them. Review the logs daily. This catches: - Incorrect assumptions about data formats - Queries that return unexpected results - Edge cases (empty results, timezone issues, rate limits)

Step 4: Enable One Automation at a Time¶

After dry-run validation, enable automations individually with a 48-hour observation period between each. This limits the blast radius of any misconfiguration.

Step 5: Monitor and Tune¶

Track these metrics for each automation: - Execution time (is it getting slower?) - Success rate (are transient failures increasing?) - Actionable vs noise ratio (are alerts useful?) - User feedback (are people finding value or muting?)

Common Pitfalls¶

Pitfall	Prevention
Production database overload from reporting queries	Always use read replicas; set query timeouts
Rate limit exhaustion from too-frequent cron	Match cron frequency to API tier limits
Timezone mismatches in scheduled reports	Use UTC internally; convert at presentation layer
Stale credentials breaking automations silently	Health-check every automation daily; alert on auth failures
Alert fatigue from over-aggressive thresholds	Start with high thresholds; tighten based on feedback
Data drift between integrated systems	Run reconciliation queries weekly; flag discrepancies

Extending the Patterns¶

These four integrations are examples of a generalizable pattern. You can apply the same architecture to:

CI/CD + Communication: Connect CI platforms (GitHub Actions, CircleCI, Jenkins) to Slack/Teams for build and deploy notifications
Finance + Operations: Connect payment processors (Stripe) to accounting (QuickBooks) for automated reconciliation
Marketing + Sales: Connect ad platforms (Google Ads, Meta) to CRM for closed-loop attribution
Support + Engineering: Connect help desks (Zendesk, Intercom) to issue trackers for bug escalation
HR + Calendar: Connect HR systems to calendar for automated onboarding scheduling

The pattern is always: read from sources → compute/enrich/detect → write to destinations → alert on anomalies → log everything.