There’s a version of this post that starts with a vision statement. This isn’t that version.
What follows is a straightforward account of what I’ve actually built over the past few months, the infrastructure, the decisions behind it, and where it currently stands. No claims about where it’s going. Just what exists.
The starting point
I work in marketing. Have done for a decade, the last six years specifically in Web3. At some point I started noticing a pattern: the repeatable parts of marketing—research, drafting, publishing, prospecting—were eating the majority of the time, while the parts that actually required judgment were getting squeezed.
The obvious response was to build systems that handle the repeatable parts. So that’s what I did.
The stack
Everything runs on a Hetzner VPS, a CPX22 running Ubuntu 24.04. Not because it’s the most impressive setup, but because it’s always on, it’s cheap, and it’s mine. I’m not renting compute from a platform that can change the rules.
The agent running on it is Hermes, a self-hosted AI agent by Nous Research. It uses Claude as its primary model and connects to Telegram as the interface, meaning I can send it instructions from my phone and it works on the server while I do something else.
The search backend is Exa, configured via the .env file on the server. When Hermes needs to research something on the web, it goes through Exa rather than a browser-based fallback, which is more reliable for the kind of structured research tasks I’m giving it.
What it currently does
Automated blog publishing pipeline
Hermes works through a Google Sheet queue of Web3 projects, one per day. The flow looks like this: it pulls the next project from the sheet, scrapes CoinDesk for current market context, drafts a blog post, and creates a scheduled WordPress draft via the REST API.
Two human touchpoints remain in the loop: I approve an angle via Telegram reply before the draft gets written, and I add a featured image before the post goes live. Everything else runs without me.
The WordPress integration uses Application Passwords for authentication. Two skill files sit behind this pipeline (web3-project-research and web3-project-blog) which are essentially instruction sets that tell Hermes how to approach each step.
Lead generation pipeline
Hermes scrapes for newly listed tokens, qualifies them against signal criteria before doing any enrichment, and outputs a CSV for cold outreach. The qualification-before-enrichment order matters: running enrichment on every token regardless of quality wastes API calls and produces noise. Filter first, enrich only what passes.
The current source is Bitget. The qualification filter looks for projects with real products, identifiable teams, and community activity, not meme coins or anonymous launches with no substance.
Markdown content negotiation
This one is less visible but worth documenting. I implemented server-side content negotiation on laurenmae.co so that when an AI agent requests a page with Accept: text/markdown in the header, it receives a proper markdown response instead of HTML. The implementation lives in the Nginx config.
The practical effect: AI systems crawling the site for training or retrieval get cleaner, more parseable content. It’s part of the AI visibility work, making the site legible to machines, not just humans.
What it doesn’t do yet
The lead gen pipeline needs a qualification layer that goes deeper than token metadata. Reddit community signal would help here, whether a project has an active, genuine community versus manufactured activity. That’s a work in progress.
The blog pipeline still requires manual image sourcing. That’s the most obvious remaining friction point.
Neither pipeline has been productised. Right now they run for my own use. Whether that changes depends on whether the infrastructure proves its value clearly enough to be worth packaging.
What this is evidence of
I’m a marketer who built this, not an engineer. The Nginx config took longer than it should have. I’ve broken things and had to reconstruct them. There’s a note in my files about the correct order of operations when migrating a WordPress site, written after learning it the wrong way.
That’s the honest picture. The systems exist, they work, and they were built by someone who figured it out rather than someone who already knew.
Whether that’s the interesting part is for someone else to judge.
Leave a Reply