u/adamb0mbNZ

https://www.nbr.co.nz/law/wealthy-family-member-jailed-for-child-sex-offences-gets-parole/
Shocking... apologies if that has already been posted. I couldn't see it anywhere.

My friend has had to pull out. I have it on the FIFA ticketing app - happy to transfer in person. DM if interested.

I've seen a lot of "Claude Code/Codex vs OpenClaw" debate on here recently and I don't think the framing is right, or at least I haven't seen an explanation that makes sense.

They aren't competitors. I've been using them together for one of the businesses I work with, and dividing labor between them has been what has made the project successful. It's very much a case of making sure that you use the right tool for each job.

I thought I would share the architecture here because I haven't seen this pattern written up.

For context to save you reading the whole thing, the TLDR is that this is for:
- Lead scraping for suppliers
- Lead scraping for customers
- Lead enrichment and categorization
- Outbound email sequences for each
- Tracking responses and monitoring replies
- Assigning leads based on responses and information about the respondees
- Using a custom CRM to manage it all

Tools used:
- Nylas (free) to connect to real email accounts
- ApiTap for scraping (free via GitHub)
- Scrapling for scraping (free via GitHub)
- BraveAPI for web search ($5/month)
- Apollo for lead enrichment (~$100/month)
- Claude Code Max sub ($100/month) for building
- OpenAI Codex Pro sub ($100/month) for OpenClaw
- Local PC where it all runs

If any of this looks interesting, then keep reading :)

-----

Use case
A wholesale / distribution business that needed an outbound sales engine. The job was to find the right customers to sell finished products to, and to find manufacturers/suppliers to either buy from or pitch services to, then run the full outreach loop end to end - find leads, enrich them, write the email, send it, read the reply, draft the response, get sign-off, repeat.

The whole thing runs for under $400/month in tokens and API costs, replaces what would have been a full SDR seat, and is generating real replies in the first three weeks.

Prep before building
We had a set of leads that we had put together, and some different cold outreach sequences that we had used in the past that had shown some promise previously.

The division of labor
Claude Code did the building. The CRM database, the scraper logic, the Nylas mailbox integration, the sequence engine, the schema for the enrichment pipeline.

Anything that was code, repo work, schema design, or a one-shot "build this module" task went to Claude Code in a terminal, and I used to build the web app that runs on the local machine. OpenClaw runs the actual business.

Three agents handle different parts of the loop:

• Scraper agent - pulls qualifying sellers and online sellers daily, dumps them into the CRM
• Enrichment agent - custom OpenClaw sub-agent that takes a raw lead and goes deep: revenue band, company size, target fit, signals worth referencing in the email
• Outreach agent - picks the right sequence from the database, tweaks the message based on the enrichment data, sends via the Nylas-connected mailbox, tracks the send, reads the reply when it comes in, drafts a response, and pushes it to Telegram for approval

The response rate gets monitored continuously. When a sequence underperforms, OpenClaw flags it and proposes message tweaks. I sign off on the changes, it re-writes the emails and we start the process again.

The best tool for each job
Claude Code on its own would have built me a beautiful CRM that did absolutely nothing. OpenClaw on its own would have spent days trying to write code it isn't built to write, and burned tokens doing it. Here's the setup:

• Build with Claude Code. Run with OpenClaw.
• Code-heavy, one-shot, structural setup and database tasks: Claude Code
• Persistent, multi-channel, "this needs to keep happening" tasks: OpenClaw

Claude Code (or Codex) will always do a better job at writing code than OpenClaw. It's fundamentally designed to do just that.

OpenClaw is designed to monitor and iterate over and over and improve as it goes. If you use something like my Engram memory system (shameless plug - look it up n GitHub) it will get better as it goes.

The key takeaway for this:
Create structure and guardrails by building the framework with Claude Code, then have OpenClaw run through the flow over-and-over within the framework guidelines.

This keeps your OpenClaw focused and prevents drift - it's job is just to keep executing the same tasks within the framework Claude Code built.

Happy to go deeper on any part - the enrichment sub-agent, the Telegram approval flow, the sequence-tweaking logic, or how the handoff between the two tools is structured. Just ask in the comments or drop me a DM.

Thanks

I see a few questions around inconsistency of execution with Cron jobs, so I thought I would layout some tips for efficiency to help consistency of execution as well as to help keep token usage down when running Cron jobs.

I run OpenClaw instances across a number of different businesses that I am involved with, and in some cases there are multiple OpenClaw instances within the same company, running across various segments of the business. This is where defining the line between Heartbeat and Cron makes a big difference.

Heartbeat vs Cron
For those who are newer to OpenClaw, a Heartbeat is a periodic agent wake-up or check-in. The agent will read context, see if anything needs doing then it either responds to a task or it sends a Heartbeak_OK message to your logs and it goes back to sleep.

A Cron job is a scheduled task trigger. It can be an isolated agent run (the default action in OpenClaw for a Cron job) OR you can schedule a plain shell command.

The mistakes most of us make: treating Heartbeat as the default and Crons as advanced. It's the opposite. Cron should be your default, and Heartbeat is the exception. The second mistake is using an agent to execute a Cron versus using a shell command. Agentic actions cost tokens, shell commands don't, and the vast majority of Cron jobs only need shell commands.

Setting up Cron jobs
You don't have to use OpenClaw to create the cron. Tell your agent: "Write me a shell script that does X, then create a system cron that runs it every Y minutes and pipes the output to me via Discord/Telegram [whichever you use] only when the output is non-empty."

This way the agent writes the script once (one LLM call), the system Cron runs forever for free, you only get pinged when there's actually something to look at.

Examples of Heartbeat vs Cron
Job: Soul Guardian integrity check
Type: Cron, shell + diff
Why: Pure file operation, no reasoning needed

Job: ClawSec advisory feed
Type: Cron, isolated agent run, weekly
Why: Needs reasoning but not chat context

Job: Weekly memory audit
Type: Cron, isolated
Why: Reads files, writes summary, exits

Job: Daily morning briefing
Type: Cron, isolated
Why: Calendar + email + weather, one shot

Job: "Watch the inbox + chime in if relevant"
Type: Heartbeat
Why: Needs conversational state

Job: Long-running task monitoring (vibe coding or scraping or similar)
Type: Heartbeat
Why: Multi-signal batched check

Don't clutter your HEARTBEAT.md
Empty HEARTBEAT.md (or just comments) = your agent wakes up, sees nothing to do, and shuts up. Use this when you're moving jobs to Cron and want to keep your ambient costs down.

Final Thought
OpenClaw's superpower isn't that the agent is always awake. It's that the agent can write its own automation requirements and then get out of the way. Use the LLM where reasoning is needed, use Cron for everything else.

I hope this helps some people out there - happy OpenClawing!

I see a few questions around inconsistency of execution with Cron jobs, so I thought I would layout some tips for efficiency to help consistency of execution as well as to help keep token usage down when running Cron jobs.

I run OpenClaw instances across a number of different businesses that I am involved with, and in some cases there are multiple OpenClaw instances within the same company, running across various segments of the business. This is where defining the line between Heartbeat and Cron makes a big difference.

Heartbeat vs Cron
For those who are newer to OpenClaw, a Heartbeat is a periodic agent wake-up or check-in. The agent will read context, see if anything needs doing then it either responds to a task or it sends a Heartbeak_OK message to your logs and it goes back to sleep.

A Cron job is a scheduled task trigger. It can be an isolated agent run (the default action in OpenClaw for a Cron job) OR you can schedule a plain shell command.

The mistakes most of us make: treating Heartbeat as the default and Crons as advanced. It's the opposite. Cron should be your default, and Heartbeat is the exception. The second mistake is using an agent to execute a Cron versus using a shell command. Agentic actions cost tokens, shell commands don't, and the vast majority of Cron jobs only need shell commands.

Setting up Cron jobs
You don't have to use OpenClaw to create the cron. Tell your agent: "Write me a shell script that does X, then create a system cron that runs it every Y minutes and pipes the output to me via Discord/Telegram [whichever you use] only when the output is non-empty."

This way the agent writes the script once (one LLM call), the system Cron runs forever for free, you only get pinged when there's actually something to look at.

Examples of Heartbeat vs Cron
Job: Soul Guardian integrity check
Type: Cron, shell + diff
Why: Pure file operation, no reasoning needed

Job: ClawSec advisory feed
Type: Cron, isolated agent run, weekly
Why: Needs reasoning but not chat context

Job: Weekly memory audit
Type: Cron, isolated
Why: Reads files, writes summary, exits

Job: Daily morning briefing
Type: Cron, isolated
Why: Calendar + email + weather, one shot

Job: "Watch the inbox + chime in if relevant"
Type: Heartbeat
Why: Needs conversational state

Job: Long-running task monitoring (vibe coding or scraping or similar)
Type: Heartbeat
Why: Multi-signal batched check

Don't clutter your HEARTBEAT.md
Empty HEARTBEAT.md (or just comments) = your agent wakes up, sees nothing to do, and shuts up. Use this when you're moving jobs to Cron and want to keep your ambient costs down.

Final Thought
OpenClaw's superpower isn't that the agent is always awake. It's that the agent can write its own automation requirements and then get out of the way. Use the LLM where reasoning is needed, use Cron for everything else.

I hope this helps some people out there - happy OpenClawing!

I haven't posted for a while, but some of you may remeber that I built a hybrid memory system for OpenClaw that combines vector and semantic search for OpenClaw, with a memory decay architecture.

In any case, one of the OpenClaw updates last month broke it, and I've had a few people reach out to me to help fix it, so I have finally done it and put it up on Github and gave it a name: Engram, which is the biometric trace that makes memory possible.

I appreciate all of the support for my first build, and I hope everyone is rocking their OpenClaw and enjoying it as much as I am. Please star this on Github if you like it:

https://github.com/nanoflow-io/engram

Thanks

=======

Engram is a memory plugin for OpenClaw agents. It gives them a brain that doesn't forget between sessions - backed by SQLite + FTS5 for exact, structured recall and LanceDB for fuzzy semantic search over embeddings.

Features

• Hybrid recall: structured key/value facts + semantic vector search, queried together
• FTS5 full-text search over fact text
• Categories: preference, fact, decision, entity, other
• Decay classes: permanent, stable, active, session, checkpoint (with confidence decay)
• Auto-capture / auto-recall hooks (configurable)
• Local-first: your memory stays on your machine
• Embeddings via OpenAI (text-embedding-3-small or -large)

I haven't posted for a while, but some of you may remeber that I built a hybrid memory system for OpenClaw that combines vector and semantic search for OpenClaw, with a memory decay architecture.

In any case, one of the OpenClaw updates last month broke it, and I've had a few people reach out to me to help fix it, so I have finally done it and put it up on Github and gave it a name: Engram, which is the biometric trace that makes memory possible.

I appreciate all of the support for my first build, and I hope everyone is rocking their OpenClaw and enjoying it as much as I am. Please star this on Github if you like it:

https://github.com/nanoflow-io/engram

Thanks

=======

Engram is a memory plugin for OpenClaw agents. It gives them a brain that doesn't forget between sessions — backed by SQLite + FTS5 for exact, structured recall and LanceDB for fuzzy semantic search over embeddings.

Features

• Hybrid recall: structured key/value facts + semantic vector search, queried together
• FTS5 full-text search over fact text
• Categories: preference, fact, decision, entity, other
• Decay classes: permanent, stable, active, session, checkpoint (with confidence decay)
• Auto-capture / auto-recall hooks (configurable)
• Local-first: your memory stays on your machine
• Embeddings via OpenAI (text-embedding-3-small or -large)

I've had this for about 12 years. With GoDaddy expires Oct. 24, 2026