Our work

What we've shipped

The problem

A mid-size cultural nonprofit was putting on a free community event for 5,500 people at one of NYC's premier venues. They brought us in to run the ticketing.

The catch: the ticketing platform was built for a conventional paid event, and this was anything but — free, community-first, and family-oriented. The assumptions baked into the system didn't match how people actually registered and showed up.

That mismatch turned into a flood of email. People wrote in to add family members to a registration, to pay for a bus seat, to ask where they'd be sitting — and dozens of variations besides. Every message was specific to one person's booking, so no canned reply would do, and hundreds of them landed in the inbox.

What we built

We built the Hermes Agent to work the inbox on a schedule. The design point was simple: let AI do the reading, the looking-up, and the drafting — the slow, repetitive part — while a person kept final say on every message that went out.

Because each reply was grounded in the person's actual registration rather than generated free-hand, the answers stayed accurate. Across the whole run the agent produced no hallucinations, and fewer than 2% of its drafts needed any edit before sending.

Some requests couldn't be settled by email alone — a name change, say. Rather than guess, the agent logged those to a shared Google Sheet for the team to action, so nothing fell through the cracks.

How it worked

1. On a schedule, the Hermes Agent pulled new messages from the event inbox.
2. For each one, it looked up that person's registration in the database — who they'd registered, their seats, their bus, their status.
3. It drafted a personalized reply grounded in that record, in a warm, on-brand tone.
4. A person reviewed each draft before it sent. Most went out as written; only a few needed a light edit.
5. Anything it couldn't handle by reply alone — a name change, for instance — it logged to a shared Google Sheet for the team to action.

The outcome

Over two months the Hermes Agent triaged around 1,100 emails and handled personalized conversations with 610 people, start to finish. Most heard back within a day — often within a couple of hours, even as volume topped 100 messages some weeks.

People noticed. Replies came back fast, spoke to their specific situation, and actually solved what they'd written in about — and they said so. What would have been weeks of manual triage instead saved the team 200+ hours.

The problem

For the same 5,500-person community event, the nonprofit needed to reach registrants where they'd actually see it: text.

Two things had to happen over SMS — get everyone the practical details (their registration number, the link to sign up for a bus) and then keep answering the questions that came back. At that scale, both the outbound push and the back-and-forth are a lot to do by hand. And every text costs money, so message length matters.

What we built

We set up bulk SMS through QUO.com and had the Hermes Agent drive it. On the way out, it sent each person a personalized message — their registration number, a nudge to sign up for a bus, and a personalized link that dropped them straight into the right form.

Then it held the conversation. People texted back with questions, and the agent replied in the nonprofit's own voice — warm, on brand, and written to read like a person, not an autoresponder. It kept each message tight, too, so texts didn't sprawl into extra segments and cost.

How it worked

1. A cron job checked for new replies every hour.
2. For each one, the Hermes Agent looked up the person's registration and drafted a reply in the event's tone, sized to keep SMS costs down.
3. It sent replies back through the QUO.com API.
4. When there was no clear next step — an ambiguous message, or one that needed a human call — it pinged the event organizers on a Telegram bot to approve the message or get clarification before anything went out.

The outcome

Over two months the agent texted all ~5,500 registrants and held two-way SMS conversations with 430 of them. Roughly 70% completed their bus signup straight from the personalized link, and questions got quick, specific answers — on time and on brand.

Registrants were happy — they got the right information when they needed it, and help that felt personal. The team got reach and responsiveness over text without standing up a phone bank.

The problem

A nonprofit needed a website for an event — small, quick to stand up, and easy to keep changing.

The default answer is a CMS like WordPress or Drupal. For a site this size that's heavy: slower pages, another login to maintain, and a template that fights you every time something needs to move. And this client wanted changes often.

What we built

We built the site as static HTML with Astro — fast, cheap to host, nothing to maintain. Claude Code got it stood up quickly.

The catch with a hand-built static site is the edits: normally every change is a developer task. So we built an agent on the Hermes framework to own that loop, and connected it to the client over Telegram through Hermes's gateway.

Now the client just messages what they want — add a page, swap in a PDF, update the org's details — in plain language, and the agent takes it from there.

We put guardrails around it. Only specific Telegram users can make edits, so no one outside the client's team can touch the site. And the agent is bounded to safe changes — it won't break the build, restructure what it shouldn't, or act beyond what was asked.

Because the whole site is static, the agent can read all of it at once. When a change touches several places — the org's name, a date, a contact detail — it finds every instance and updates them together, instead of missing one.

How it worked

1. The client texts a change to a Telegram bot — "add a schedule page," "upload this PDF," "update our address."
2. The Hermes Agent makes the edit in the site's code and commits it to GitHub, keeping a full history of every change.
3. It deploys to a staging site and texts back the staging URL, so the client can check the change before it's live.
4. Once the client signs off, the change is merged to the main branch and Cloudflare Pages deploys it live.

The outcome

The client edits their own site by texting, in plain English — new pages, PDFs, copy changes — and sees each one on a staging link before it goes live. No CMS, no login, no developer in the loop for routine changes.

Best of all, they're not waiting on anyone. They update the site from their phone, wherever they are — no trip home to a laptop, no ticket to a developer — and changes can go live any time, day or night, usually in under ten minutes from text to deploy.

Because the agent handles the content and the layout together, it does in one step what a CMS splits between an editor and a template — which cut the time each change used to take, and kept a clean, versioned history of the whole site. Over the event run the client shipped 80+ updates this way, on static hosting that costs next to nothing.