Charlie Credits limits
Charlie enforces the daily and weekly Credits limits included with every plan.
Two weeks ago, I wrote about rage-building an email automation system because HubSpot wanted an expensive upgrade and a professional services engagement for a workflow I could describe in a paragraph.
Charlie and I took that paragraph all the way to a production system. Agent-written code was only the start. Plenty of tools can produce code. The interesting part was getting a real system specified, reviewed, tested, deployed, and operated through the repo while keeping the risky decisions visible.
Now we are publishing the Transactional Email Engine source, with v0.1.0-beta.1 as the first public prerelease.
I want to share it because complete, working agent-built systems are more useful than polished demos. You can inspect what Charlie produced, where humans supplied judgment, which checks earned our confidence, and where the implementation still carries our specific assumptions.
Sharing the entire repo makes those claims testable. Other engineers can trace a requirement into code, checks, and operating policy instead of taking our summary on faith.
The project also shows how we used Charlie daemons as guardrails around the work. A daemon is a repo-defined operating role for Charlie, written in a DAEMON.md file. Each role has an explicit purpose and a small set of routines. It can include deny rules for shortcuts it must not take, plus operating guidance for verification, freshness, limits, and when to stop or ask for input.
For this system, PR Check Repair, PR Review Triage, and Recent Docs Drift Maintainer cover the practical loop of fixing failed checks, resolving review feedback, and keeping source-backed docs aligned after changes.
That structure matters because daemons differ from fixed-rule bots and continuously running processes. A daemon wakes on matching events or a schedule, performs a bounded activation, and completes. The instructions shape Charlie’s judgment inside a narrow job. The guardrails reduce ambiguity but still require review. They make the expected behavior legible enough to inspect, test, and tighten when reality exposes a weak boundary.
In this project, that meant roles could check current state before consequential actions, refuse work outside their scope, cap how much they changed, and require evidence before reporting success.
Email provides one compact example. A contact may qualify for a follow-up and unsubscribe before the queued send. The system checks consent again close to delivery and records why it stopped. The daemon guardrails sit around the engineering and operational process that preserves checks like that; they are not a claim that an agent can infer every policy correctly on its own.
This release is a source-only reference implementation, not hosted SaaS or a one-command deployment. It reflects our stack and our constraints: Cloudflare Workers, D1, Queues, Cloudflare Email Service, and HubSpot. We left those assumptions visible rather than wrapping them in abstractions that imply every team’s consent rules, data model, and operating policy are interchangeable.
You can inspect the workflows and render synthetic examples locally without Cloudflare or HubSpot credentials, provider clients, or outbound sends. That gives reviewers a path through the system before creating infrastructure or granting access to contact data.
If you have operated lifecycle or transactional email systems, I would like to know where this design travels well and where our provider choices show through. Open an issue with the boundary you would keep, change, or test harder.
What we are releasing is one real answer, built with an agent and kept reviewable by repo-owned guardrails. You can examine the whole thing and decide which parts deserve a place in your own system.
