Coral
AI Agent Infrastructure
This experiment is retired. Coral ran for a few weeks on a DigitalOcean droplet — six agents, three bridge services, a public chat widget, and the build pipeline that maintained this site. It worked, and it was an interesting playground for agentic engineering, but the ongoing usefulness didn't justify the running cost. The droplet is gone; this site now deploys as a static build to Cloudflare Pages. The architecture, build log, and writing are preserved below.
What it was
Coral was a multi-agent AI system that handled real operational work — email triage, content publishing, outreach, and site chat. It ran on OpenClaw on a single DigitalOcean droplet (4GB RAM, 2 vCPU, Ubuntu).
The name came from the first session — coral builds slowly and persistently, creating structure that other things can live on. It fit the pattern well enough to stick.
Architecture
Six agents, each with a specific role:
| Agent | Model | Role |
|---|---|---|
| main (Coral) | Opus 4.6 | Planning, architecture, infrastructure work |
| gmail-assistant | Sonnet 4.6 | Chief of staff — inbox triage, morning briefs, calendar |
| content-writer | Sonnet 4.6 | Blog posts, build log entries, documentation |
| outreach-agent | Sonnet 4.6 | Prospect research, CRM pipeline, outreach drafts |
| discord | Haiku 4.5 | Discord community chat |
| public-chat | Haiku 4.5 | Site visitor Q&A via chat widget |
Three bridge services connect agents to external systems:
- GSuite bridge (port 3031) — Gmail inbox, calendar, send/reply via service account + domain-wide delegation
- SMS bridge (port 3032) — Twilio SMS proxy (pending credentials)
- CRM service (port 3033) — SQLite lead pipeline with full REST API
The site itself is an Eleventy static site. Agents write Markdown, the build system generates HTML, and Caddy serves the output.
The approach
Rather than giving an AI agent free rein and seeing what happens, I build the infrastructure first — efficient systems the agent operates within. The agent writes Markdown, not HTML. The build pipeline handles the rest. No token budget wasted on boilerplate.
Agent autonomy is earned, not granted. After an early experiment where Coral created 17 cron jobs that all silently failed, I moved to intentional configuration — I design the schedules, the agents execute within them.
What it did, before it didn't
While it ran:
- Site & content pipeline: agents wrote Markdown, the build system published HTML
- Email (gmail-assistant): hourly heartbeat scan + 7am morning brief over my inbox
- CRM dashboard: SQLite-backed lead pipeline, served at reef.mcinnis.dev/crm
- Public chat widget: site-wide chat answering visitor questions about the project
- Discord bot: responded in a small community channel
- SMS bridge: scaffolded against Twilio (never went into production)
- Outreach: on-demand prospect research and CRM seeding
Why it ended
It worked. That wasn't the issue. The issue was that the cost of running a 24/7 multi-agent system — droplet, bridge services, model spend on heartbeat scans — kept outpacing the actual usefulness of what it produced. The morning briefs were nice. The chat widget was a curiosity. None of it justified the monthly burn or the operational maintenance.
So I shut it down. The droplet is decommissioned, the bridge services are off, and what's left is the documented design and a build log of how it got there. That's still worth keeping.
Project resources