We automated our outbound using the Obsidian + Claude Code + Hermes Agent trio
A detection workflow watches the market, three tools turn each signal into a researched first touch, and the whole thing runs on a server while the strategy stays human. Here’s the build.
A target account closes a Series A on a Tuesday morning. By that afternoon, three of your competitors are already in their inbox. Not because those competitors are sharper than you, but because something on their side caught the round and acted on it before a person had to.
That is the problem I care about here. Whether your go-to-market is actually running, and not just busy, has little to do with how much work you put in. It comes down to whether anything reacts at the speed of the signal, or only at the speed of your attention.
Most teams run on attention. Someone notices the news eventually. Someone finds an hour to research the account eventually.
Someone writes the email eventually. By the time all three line up, the moment has cooled and the account has heard from everyone else.
This is about the one slice of go-to-market we put on full autopilot for clients. Not the whole thing. Positioning, the offer, pricing calls, the actual relationship, those stay with a human, and I’ll get to why that line is deliberate.
But the slice that turns a buying signal into a researched, written, sent first touch can run on its own, overnight, on a server, and get better at its own job every week. The core is three tools wired together, with a watcher bolted to the front that feeds them.
You can build it yourself, and I’ll show you enough to do that. Some clients would rather we run it for them, which I’ll come back to at the end.
Why running this on attention fails
Buying signals show up all day. A funding round. A new VP of Sales who owns the exact problem you solve. A job post that only exists because the thing you sell is broken inside that company. A competitor they rely on quietly falling apart.
Each one is a narrow window where a relevant message lands very differently than it would have a week earlier or a week later.
A person cannot watch all those windows.
And even when they catch one, the work that turns a signal into a good first touch is slow and easy to drop when the day gets full.
You have to pull what you know about that buyer, recall what has actually pulled replies from that kind of account before, write something that sounds like the client and not a template, then send it and chase the follow up.
Under load, that whole sequence collapses into a generic blast or gets skipped. So the highest intent moments get the least consistent response. That is backwards, and almost everyone does it.
The usual answer is to buy more software. A signal tracker, a data enrichment tool, a sequencer on top.
Now there are three more dashboards and a fourth job: checking them. None of those tools act on their own. They surface the signal and wait for you to do the work, which lands you right back where you started, just with a nicer view of everything you don’t have time to act on.
The setup below inverts that. One connected line where a signal comes in one end and a sent message comes out the other, with you in the loop only where your judgment changes the outcome.
The setup, end to end
Strip the names off and it is watch, then store, then think, then act.
Something happens in the market. A watcher catches it and writes it down. A tool that holds everything you know about the client reads that signal in context. A second tool runs the response.
The whole line sits on a server so it keeps working when your laptop is shut. Each piece feeds the next, which is what makes it a system and not four subscriptions sitting next to each other.
Here is each part, with one example carried straight through so it stays concrete: a target account in fintech closing a Series A.
The watcher: n8n on the VPS
The front door is its own pipeline, and it is the part people skip when they say “the trigger fires” and wave a hand.
In a setup that runs unattended, something has to find the signal, catch it, and hand it off, continuously, without you watching. That something is n8n, self hosted on the same server as the rest of the stack (more on the server below).
A trigger is any event or intent signal that says a specific account is more reachable right now than it was yesterday. They arrive two ways, and n8n handles both.
Some get pushed to you, which is the warm, high intent stuff and the least work. A website visitor de-anonymization tool fires the moment a target account hits the client’s pricing page.
A form fill or demo request comes straight off the client’s site. You catch these with a webhook node and you are done.
The rest you go and fetch on a schedule. A cron node wakes up, checks the source, and pulls what is new.
Funding rounds from a news feed or an Apify funding scraper. New hires into the role that owns your problem, and job posts that imply the pain, from the LinkedIn and job-board scrapers (the same Apify motion you’d use to build a prospect list, just pointed at events and run on a loop instead of once).
Tooling changes from something like BuiltWith or a change-detection watch on a target’s site.
For the fintech example, the cron node catches the Series A off the funding feed. n8n writes a small markdown file describing the event into the vault’s raw folder.
Since n8n and the vault live on the same machine, that handoff is just a file write. Nothing fancy moves between them.
One deliberate choice here: the watcher is dumb on purpose. n8n does not try to decide whether a signal is worth acting on. It dumps everything it catches into raw and lets the next tool make that call, because the next tool is the only one holding the full client context. Keeping the watcher simple is what keeps it reliable when a source changes shape or a new client needs a new signal type.
That leaves one real question: what stops the same Series A firing five times when three sources all report it, or stops you emailing an account twice in a week because two unrelated signals hit at once?
You do not need a database for this. The vault already holds the answer. Every account has a record listing the signals it has seen and the date it was last approached.
The processor checks that record before it writes anything new. The memory you built to make the outreach good is also the thing that keeps it from repeating itself.
The memory: Obsidian
Obsidian holds everything, and its only job is to remember. We keep it plain. Two folders. A raw folder for anything unprocessed: the signal files n8n drops in, call transcripts, screenshots, a voice memo from the client about a new angle. And a wiki folder for the cleaned up, linked, permanent version: the client’s offer for each segment, who they actually sell to, the messages that have pulled replies, the objection each segment raises, and a record for every account the system has touched.
A single instructions file at the root explains how the vault works, which I’ll show you in a second.
Raw is messy on purpose. Wiki is clean on purpose. The thing that moves a note from one to the other is not you retyping it at midnight.
For the fintech trigger, the vault already knows the things that make a cold message land: this client sells to fintech, these two openers got replies from fintech buyers last quarter, and this is the objection fintech operators almost always raise on the first call. None of that lives in someone’s head or a dead doc. It sits in one place the next tool can read.
The processor: Claude Code
This is where a notebook turns into something that does work. Point Claude Code at the vault and it has read and write access to everything you have ever captured about that client.
When the Series A file lands in raw, Claude Code reads it against the vault. It finds or creates the record for that account, and it checks that record first: have we already briefed this account on this signal, or touched it inside the cooldown window? If so, it skips and says why.
If not, it pulls the relevant context, the offer for fintech, the openers that have worked on that segment, the objection that segment raises, and writes a short brief into the account record.
Why now, tied to the round. The angle. A drafted first touch in the client’s actual voice, because it is working from messages the client really sent, not a blank page. And the one piece of proof from the vault that makes the angle credible.
The instructions file is what makes this predictable instead of random, and it is worth getting precise. Vague instructions produce vague output, and that sloppiness compounds the same way the good stuff does.
In the dumb-watcher setup, the dedup logic lives in this file too, so it has to be explicit. Here is a trimmed version of what we’d drop at the root of the vault:
# How this vault works
This vault runs outbound for [client]. You have read and write access.
Two folders:
- /raw unprocessed input: signal files from n8n, transcripts, screenshots, notes.
- /wiki the processed, linked, permanent version:
offer per segment, ICP notes, message bank, objection log, account records.
## When signals land in /raw
n8n dumps every signal it catches into /raw. There may be several at once,
including duplicates of the same event reported by different sources.
For each batch:
1. If several files in this batch point at the same account, treat them as one.
2. Identify the account and which segment it belongs to.
Check /wiki/accounts for an existing record.
3. If a record exists and we already briefed this account on this signal,
or approached it within the last [60] days, skip it and note why.
Do not write a duplicate brief.
4. Otherwise pull the relevant context from /wiki:
- the offer for this segment
- the two or three messages that pulled replies from this segment (/wiki/message-bank)
- the objection this segment usually raises (/wiki/objections)
5. Write a short brief into the account record:
- why now (tie it to the signal)
- the angle
- a drafted first touch in the client's voice
- the one proof point from the vault that makes the angle credible
6. Update the account record with this signal and today's date.
7. Do not invent results, names, or numbers. If the vault does not have
something, say so in the brief. Then mark it ready for review.
## Voice
Match the client's sent messages in /wiki/message-bank.
Short sentences. No corporate filler. No em dashes.
## When in doubt
Extend an existing note instead of creating a duplicate. One account, one record.That file is most of the difference between a system you can predict and one that surprises you. Spend your time here.
The operator: Hermes Agent
Obsidian remembers. Claude Code thinks. Hermes Agent acts, without you opening a laptop.
Hermes Agent is the open source framework behind MaxHermes. You run it as an always on agent and drive it from Telegram, so it sits on your phone instead of in a browser tab you forget to open. It takes the brief Claude Code wrote and runs the play: send the first touch, watch for a reply, run the follow up on schedule.
Two things matter here. The first is the leash. Early on, the agent sends nothing on its own. It stages the message and waits for one tap of approval from you in Telegram, the way you’d review a new hire’s first few emails.
Once it has earned trust on a given kind of play, you let it send that kind on its own and only get pulled in on replies. Overnight autonomy is something it earns, not something you hand over on day one.
This is also the honest answer for anyone who hears “fully automated” and gets nervous. It is automated end to end, but your hand stays on the switch until the track record says you can take it off.
The second thing is that it learns. After it finishes a task complex enough to be worth it, Hermes Agent writes itself a reusable skill from how it did the work and keeps it.
The skill list starts empty. A couple of weeks of real use later it has a small library of its own methods, and every repeat of a play it has seen runs faster.
For the fintech example: the first Series A takes the full path, and you approve the send.
By the fifth one, the agent already knows what an approved fintech funding play looks like for this client, the brief needs less editing, and the send is one tap or no tap at all.
Where this actually runs
Here is the part that quietly kills a lot of “automated” setups after a week.
You cannot run this on your laptop. An always on agent needs to be always on. Your laptop sleeps, drops wifi, closes when you go to lunch, restarts for an update at 2am.
The exact hours you most want this thing working, overnight and while you are heads down on real work, are the hours your personal machine is least reliable. So it lives on a VPS, a small cloud server that never sleeps.
We put n8n, Obsidian, and Hermes Agent on the same VPS, so the watcher, the memory, and the operator all sit in one place and the whole line stays up around the clock. For every client we run this for, we use Hostinger.
Their cloud VPS has been the most reliable we’ve used, the support is actually there at any hour, and the practical kicker is that Hostinger ships a one click Hermes Agent template, so standing up the operator is close to effortless instead of a server project.
If you are doing this yourself, this is the plan we put clients on: Hostinger VPS. That is our referral link, and it stacks a 20% discount on top of whatever else Hostinger is running, so you may as well use it.
The 24 month term is the one that makes the math work, since this is infrastructure you want sitting there for the long haul, not a thing you spin up and forget.
The two ways it gets better on its own
Most automation runs the same script forever and never improves. This setup compounds, and it does it in two separate places that are easy to blur together, so they are worth pulling apart.
The first is the memory. As you keep feeding the vault, the briefs get better, because Claude Code is writing against a richer map of what you know. Early on the connections are obvious.
Months in, it starts making ones you would have missed. A new objection a fintech prospect raised this week links back to a deal you lost in the spring, both pointing at the same soft spot in the offer that nobody had named out loud, and the next brief names it. That is the vault paying you back for the captures.
The second is the method. Hermes Agent is not getting smarter about your market. It is getting faster at the plays it has already run, because it keeps the skills it builds. Same “improves over time” shape, different engine. One is a memory that keeps growing. The other is a set of hands that keeps getting quicker.
Both take a few weeks to show up, and this is the part worth bracing for. In week one the vault is thin and the agent has no skills, so it feels like a lot of setup for not much payoff.
That stretch is the system before it has anything to compound on, not proof that it doesn’t work.
Around month two or three the gap between this and doing it by hand stops being subtle. The delay is the price of the compounding, and there is no version where you get one without paying the other.
What we don’t automate
This setup clears the repeatable work off the plate. It does not touch the judgment, and that line is on purpose.
It does not pick the offer or the positioning. It does not decide which segments are worth chasing this quarter.
It does not handle the call where a real deal is on the line, or the awkward pricing conversation, or the moment a prospect says something that should change the whole approach. Those need a person, and they always will.
That is exactly why this is a slice of go-to-market on autopilot and not the whole thing. Anyone selling you “fully automated GTM” as a complete replacement for a human is selling you a blast machine that will burn your list.
The point of taking the repeatable slice off your hands is so the judgment becomes the thing you spend your attention on, instead of the thing you are too fried to do well by the time you reach it at the end of a long day.
Where it breaks if you build it wrong
It fails in a few predictable ways, and almost all of them trace back to skipping the boring upkeep.
The most common one is treating the vault as a dump with no processing habit. Signals and notes pile into raw, nothing ever moves to wiki, and the memory goes stale.
Six months in, the system is firing messages against an out of date picture of the client and the output gets generic. The fix is not a cleverer folder layout. It is a standing habit, even once a week, of running the ingestion and keeping the wiki current.
Watch for this one, because it creeps in slowly and you won’t notice until the briefs start sounding off.
The second is a vague instructions file. “Organize the notes well” gets you inconsistent filing and unpredictable briefs.
The version that works names the folders, says exactly how to handle a batch of signals, and is clear about when to extend a record versus create a new one. Precision there is what makes the whole thing repeatable.
In the dumb-watcher setup it is also what keeps duplicates from slipping through, since that check lives in the file.
The third is mistaking overnight autonomy for unattended trust. The learning loop makes the agent better at plays it has run before, which is a reason to start it on low stakes, reversible, approve-before-send tasks, not a reason to skip checking its work for the first few weeks. Build the trust the way you would with a new hire. Review closely at first. Loosen the leash as the record earns it.
How to build it, in order
The order is a dependency chain, not a preference. Each piece makes the next one useful, so building them out of order just means watching the later ones sit idle.
Start with Obsidian. Set up the raw and wiki folders. Pour in what you know about the client: the offer, the buyers, the messages that have worked, the objections that come up. Spend a few days just capturing, roughly is fine, until dropping things into raw is automatic.
Add Claude Code once there is something in the vault worth reading. Write the instructions file. Hand-drop one real signal into raw and watch what it does with the brief before you wire up the watcher.
Stand up n8n next, on the VPS, and point it at one source first, the one that catches the trigger type you most want to act on. Let it run and confirm clean signal files are landing in raw.
Bring in Hermes Agent last, once you know which plays are repeatable enough to hand off. Automate the one play you already run the same way every time. Prove the loop on that single play. Then widen it.
If you want to feel the thinking step today without building any of it, drop this into Claude or ChatGPT with one real signal and see what comes back:
You're running outbound for [my client], who sells [offer] to [ICP].
Here's a buying signal I just caught:
[paste it, e.g. "Acme, a US fintech, just announced a $12M Series A."]
Here's what has worked before with this kind of buyer:
[paste 2 short past messages that got replies, or describe what tends to land]
Here's the objection this buyer usually raises:
[paste it]
Write me a short brief:
- why now (tie it to the signal)
- the angle to take
- a drafted first touch in this voice: [paste 2-3 lines of the client's real writing]
- the one proof point from what I gave you that makes the angle credible
Rules: don't invent results or numbers. If something's missing, tell me what to add
instead of guessing. Keep the message short and human. No em dashes.Run by hand against your own pipeline, that one prompt will already beat most of the cold outreach landing in those inboxes.
It is also the smallest taste of what the full setup does on its own, all day, getting sharper each time.
Building and tuning the whole line, keeping the vault fed, writing the instruction sets per client, finding the sources that actually predict intent for a given offer, and babysitting the agent until it earns its leash, that is real work, and it is the work we do for the clients who would rather have the system running than build it.
If that is you, that is the thing we run. Either way, the prompt above is yours to start with tonight.




