Passa al contenuto principale

Overview

Automations is EC's agentic-automation layer: a set of small, single-purpose services that take recurring company toil off people's hands. It lives in the ec-automations workspace (parent repo + one gitignored child repo per automation, mirroring the ec-workspace pattern) and runs on a dedicated always-on box (ec-automations-hub) plus per-job workers.

This section documents each automation twice: what value it brings (why it exists, who it serves) and how it works (components, data flow, deploy).

The value proposition​

EC is small and moving fast. The scarcest resource is founder and operator attention. Every recurring, mechanical task a person does by hand — filing meeting notes, watching a feed, chasing a status — is attention not spent on the product. Automations convert that toil into deterministic plumbing, and reserve human judgement for the moments that actually need it.

The bet is compounding: each automation writes into the same shared knowledge base (the Obsidian vault) and Slack, so they get more useful together than apart, and the knowledge they produce keeps working after the task is done.

The four load-bearing principles​

Every automation obeys these (they are enforced in the repo's CLAUDE.md):

  1. Many small single-purpose automations, no orchestrator. One automation = one repo = one manifest, independently deployable and disableable. If two automations need to interact, they do it through their normal surfaces (Slack, the vault, files) — never a shared runtime or a central "AI COO".
  2. Deterministic plumbing, LLM only at judgement points. Transport, state, retries, and formatting are boring deterministic code. An LLM enters only where judgement is genuinely required (summarising, sectioning, disambiguation). If a step has a right answer computable by code, code computes it — no AI tokens spent on plumbing.
  3. Human-in-the-loop at ambiguity points, not approval gates. Automations publish immediately and correct on reaction/reply. They ask a human only when genuinely uncertain — never "approve to continue" for internal work.
  4. Markdown as agent memory. The vault and the repo docs are both the output and the context automations read. When a human corrects an output, the correction feeds back into that automation's context — outputs get better with use.

Shared infrastructure​

All automations share a small, deliberately boring platform:

  • The hub (ec-automations-hub) — an always-on EC2 (t3.medium) with zero inbound network exposure; all access is via AWS SSM. It runs one systemd unit per automation (each with its own unix user, virtualenv, and a read-only view of the vault), plus a single Docker container running Obsidian to keep a live replica of the vault in sync.
  • Deploy is push-based and secretless. A push to an automation repo's main branch triggers a GitHub Actions workflow that authenticates to AWS via OIDC (no stored credentials), uploads a code artifact to S3, and tells the hub to pull and restart it using the hub's own AWS identity. No GitHub credentials ever live on the box.
  • GPU work is wake-per-job. Automations that need a GPU (e.g. speech-to-text) wake a dedicated instance that is stopped by default, run the job, and stop it again — paying for compute only while a job runs.
  • The control-plane contract. Every automation exposes a local state/status.json (heartbeat + counters) and an inbox/ command drop-box (pause / resume / run-now). Today the operational surface is Slack; a future network-crm console can read/act on these without any change to the automations (designed, deferred until the fleet justifies it).

Automations​

  • auto-brain-notify — turns the Obsidian vault ("the Brain") from a passive archive into a system that notices its own changes and tells the right person what changed and why it matters.

More automations (meeting transcripts, market intelligence) are in build; this section grows as each goes live.