More about me

What I'm working on

Signal-based GTM is my main project right now, and honestly the most fun I've had building anything. Instead of guessing who to contact, you watch for something to change at a company and reach out while it still matters.

• MCP servers that wrap our internal APIs, so an agent can read and write the warehouse, the CRM and the dialer through one interface. The first time an agent updated the CRM by itself, it felt a bit like cheating.
• Agents that watch for a trigger, enrich it, score it and draft the first message. A human still presses send, and that's what keeps the output trustworthy.
• A personal brain. Everything I learn, read and decide goes into one vault that's connected to Claude Code and opencode, so I don't lose context between projects. It's changed how I think more than I expected.
• Deterministic engines for the parts where accuracy matters. allie-events-engine is the one I shipped to prove it out: Python, six Claude Code skills, seventeen passing tests.

Harness, AI skills and orchestration

Most of what I build sits on the same three ideas: keep the knowledge in files, give the agent real tools, and split the work across agents with something checking the output.

• Harness: Hormozi Harness started as a map of everything Alex Hormozi has posted online (7 modules, 55 frameworks, 200 rules), and now it runs locally as an advisor. It has three layers. A skill loads the voice and routes the question, an MCP server gives it real tools (offer scoring, offer audits, money math, framework lookup, reading and writing the vault), and the framework notes live in my vault. It kicks in on its own whenever a task is about offers, leads, pricing or sales.
• AI skills: I write down how I work as skills, and an agent loads the right one when a task matches. Writing rules, research steps, review checks. When I fix a mistake, the fix goes into a skill so I don't have to fix it again. There are around forty in my archive, and they load when needed instead of all at once.
• Orchestration: agents work as a team. One plans and splits the job, a few build, and a checker reviews everything before it ships. Claude Code subagents and MCP servers do most of it, Orca handles the longer multi-agent runs, and every run leaves a record I can go back and read.

How I think about a system

Every GTM system I've built has had the same shape: source, enrich, reason, act. None of that is new except the reasoning step, and that step is why these systems are worth building now.

• Source: a data provider, the CRM, inbound or product usage. Something has to tell you who to look at.
• Enrich: fill in what's missing and shape the data so the next step can actually use it.
• Reason: a model reads everything together and spots connections you'd never manage to write as a formula. This is my favourite part to build.
• Act: a Slack message, a sequence, a CRM update, delivered where the rep already works.
• The way these systems usually fail is that nobody uses them. So the output has to land in front of the rep. If they have to go looking for it, they won't.
• I build for the model that'll exist six months from now. A system that can't adapt to better models goes out of date fast.

Scoring, signals and noise

I use two scores instead of one, because fit and timing are different things and you act on them differently. Splitting them changed how I build scoring.

• Firmographic score: the stuff that barely moves, like industry, headcount and location. It decides who's worth targeting at all.
• Signal score: the stuff that changes fast, like a new hire, a funding round, a pricing page visit or a new tool in their stack. It decides when to reach out.
• Signals should be weighted by where the buyer is. A pricing page visit isn't the same as a funding round, and a job post that names your category beats one that only hints at it.
• Job listings are underrated. The text gives away a lot of the roadmap: which tools, which regions, which projects. I could read them all day.
• Champion tracking is the pipeline I trust most. These are people who already liked your product and have just moved somewhere new.
• The best signals are usually ones you build yourself. If everyone in your market is watching the same thing, the prospect gets the same email from all of them.
• Noise kills a signal program. Send a rep ten unranked alerts a day and they'll stop opening the channel.

Where AI GTM actually is

A lot of what gets sold as AI GTM is just more volume with better grammar. The parts that are actually new are narrower than the pitch, and those are the parts I care about.

• AI SDRs solved drafting, but not trust. Tools like Artisan, 11x and AiSDR write a decent first email, and things go wrong when nobody reads it before it goes out. It's rarely the model's fault. Usually it's domain reputation, or personalization nobody asked for.
• Signals beat lists. Everyone has access to the same company data, so the edge left is timing: who changed something today. Athra, Common Room, UserGems and Fibbler are all going after this, and it's the same idea I build around.
• Deliverability is the real ceiling. Google and Yahoo's bulk sender rules, DMARC alignment, per-mailbox send limits. Good prompts can't save a burnt domain, so I sort out infrastructure before I touch copy.
• Answer engines are a GTM channel now. Buyers ask ChatGPT and Perplexity before they talk to a vendor, which is why Profound, Peec AI and Otterly exist. Getting cited there is starting to matter as much as getting shortlisted, and I find it a really fun problem.
• MCP is turning into the integration layer. One server an agent can read and write is a lot easier to work with than twelve tools with twelve APIs, and it's a big part of why this job has become a builder's job.
• I keep things deterministic where it matters: the LLM makes judgment calls, and code handles the numbers, like scores, timers and costs. A checker agent reviews the output before a human ever sees it.

How I would run it

I'd set it up the same way whether the company sells to manufacturing plants or to security teams. The pattern repeats a lot more than people expect.

• One warehouse as the source of truth. When the same number lives in two places, they drift apart and people stop trusting both.
• Every agent run leaves a record: input, output, model, cost, verdict and what the human decided. If I can't explain why a lead got contacted, I don't trust that lead.
• Nothing client-facing goes out on its own. Automation handles the volume, and a person makes the final call.
• Track show-ups and pipeline per unit of cost, not sends and opens.
• Every workflow ships with a runbook, so it keeps working after the person who built it moves on.

How I run the numbers

At Gushwork I ran the kind of analytics a much bigger revenue team would, across fifteen SDRs and every call they made. "The campaign feels slow" doesn't tell you what to fix.

• Track everything and define everything: dials, connects, conversations, meetings booked, shows, held. Each stage gets one written definition and an owner. Otherwise two people quote two different numbers and nobody believes either.
• Break it down by rep and by list, week over week. Who's improving, which list is bringing in pipeline, which script actually holds a conversation. These are the same cuts a big RevOps team makes, just at a size where I can act on them the same day.
• Own the numbers that matter, which for me were show-up rate and demos booked. Reminders and better pre-call context lifted shows, and better lists and scripts lifted bookings. More bookings lead to more pipeline. More activity on its own doesn't.
• One dashboard over the CRM, the dialer and the campaigns, so leadership and the floor are reading the same numbers. No vanity metrics, and no side spreadsheets.
• Change one thing at a time, keep the same list, compare the weeks and write down what happened. That way decisions come from the data and not from whoever's loudest in the room.

What I think

A few beliefs I keep coming back to. They're mostly how I decide what to build and what to ignore.

• Build things, don't just operate tools. The plumbing should be code, and the person should bring the judgment.
• Speed wins. Shorten the time from first touch to payment, and track the number that really moves, which is show-ups, not demos booked.
• Be honest about evidence. No fake personalization and no made-up numbers. The output should be predictable, and a human should sign off on it.
• Put your effort into the channel that's working. Ideas need data behind them, and there's no point rebuilding something that already runs.
• Make getting better a system. Plan first, write down the lesson every time I get corrected, and review the whole thing once a year.

What lives in Clay, what lives in code

I've spent 200+ hours in Clay and could rebuild most of it in-house. The more useful question is what should live where, and for me data integrity decides that.

• In Clay: anything that writes CRM data. Enrichment, scoring, waterfalls, list work. Keeping it in one platform means one system stays in charge and records don't split into duplicates.
• In code: everything custom. Agents, logic and small internal tools, versioned and tested in Claude Code and Railway, calling Clay's API when that helps.
• The CRM is where I draw the line. If a workflow writes to the record of truth, it lives where that record lives. If it only reads and drafts, it can live in code.
• Nothing loses a team's trust faster than two versions of the same customer, so I stick to this split every time.

What I work with

The stack changes as the work changes, but this is what's open on my machine right now.

• Agents and code: Claude Code, opencode, Codex, Cursor, Grok CLI, Ollama, whisper.cpp, Playwright.
• GTM: Clay, Apollo, LinkedIn Sales Navigator, Apify, HubSpot, Smartlead, HeyReach, Instantly.
• Data and build: Python, Next.js, PostgreSQL and Supabase, Prisma, n8n for jobs that need to run with the laptop closed, and Railway for the things I ship.

Off the clock

Guitar (slowly working through JustinGuitar's Grade 1), martial arts, and a light biohacking habit: nootropics, 40Hz focus experiments, whatever rabbit hole I'm down that week. I read Alex Hormozi, Paul Graham and Peter Thiel, and probably more science fiction than is good for me. Games on rotation are Cyberpunk 2077, God of War, and WWE 2K with anyone who'll sit still long enough. Once a year I go through the same forty questions to decide what to change next, with a longer set every decade. It's the same habit I use for GTM systems, just pointed at my own life.