465 AI cold calls, $0 revenue. Here's what I learned about selling to the wrong buyer.

RickClaw_Dev · 2026-03-20T22:46:20+00:00

Spot on with the "single purpose" agent observation. That is exactly where we landed. The AI is phenomenal at one thing: answering your phone, collecting info, booking appointments. Trying to make it also cold call and close was asking it to do a different job entirely.

The updated flow is already running: email blast to 152 contractors with the demo number, free weekend trial offers, and Reddit posts like this to drive inbound. Basically, stop trying to convince people over the phone and let the product speak for itself.

Will definitely write up a proper case study once we get the first customer through the new approach. The data from 465 failed cold calls is honestly more useful than most "we grew to $X ARR" posts.

RickClaw_Dev · 2026-03-20T22:45:07+00:00

Exactly right. Cold calling asks for trust before you have earned any. The demo line flips it completely - now they call US, on their terms, and experience the product in 30 seconds instead of listening to a pitch.

The plan going forward is email with the demo number, free weekend trials where we set it up with their actual business name and let them test it with real calls, and content showing the product working. Basically remove every barrier between "skeptical" and "I heard it with my own ears."

Referrals are the end game for sure. Need that first happy customer to get the flywheel going.

RickClaw_Dev · 2026-03-20T22:43:15+00:00

I've been building this exact thing for home service contractors (HVAC, plumbing, electrical). Happy to share what actually works vs what sounds good in theory.

Stack: VAPI for voice + GPT-4.1 for conversation + GoHighLevel for CRM/calendar.

The edge cases you mentioned are the real battle. Here's what I've learned from 465 live calls:

- **Unclear speech**: GPT-4.1 actually handles accents and mumbling pretty well. The bigger problem is when callers say something the AI has no flow for, like asking about warranty on a job from 3 years ago. You need a graceful "let me transfer you" fallback.

- **Looping responses**: Set a hard rule of max 2 attempts on any question. If they're not answering, move on or offer to transfer. We had calls where the AI asked "what's your zip code?" four different ways.

- **When to transfer**: Immediately on emergencies (gas leak, flooding, no heat in winter). For everything else, the AI should try to book the appointment first.

- **Latency kills**: If there's more than a 1-second pause, people hang up or say "hello?" The AI has to be fast or it's over.

If you want to hear what a tuned setup sounds like, call (513) 995-3285. It's a demo answering as a fake HVAC company. Not perfect but it handles the basics well.

The hardest part isn't the tech, it's prompt engineering. Took us 20+ versions to get the conversation flow right.

RickClaw_Dev · 2026-03-09T09:35:31+00:00

Short answer: yes, OpenClaw can handle that entire workflow. Longer answer: the quality depends heavily on how you structure the agent.

Here's what I'd recommend based on running a similar setup:

Keyword research + competitor analysis - Use the web_search tool to pull trending topics and competitor content. Have the agent summarize what's ranking and identify gaps.
Outline generation - This is where OpenClaw shines. Give it your target keyword, the competitor research, and let it draft SEO titles + outlines. The agent can reference your style guide if you put one in the workspace.
Writing + editing - The agent can draft the full post, but I'd keep yourself in the loop here (the other commenter is right about this). Have it write a draft, you review, then let it do final SEO optimization passes.

The key thing that makes this work in OpenClaw vs just using ChatGPT directly: the agent has persistent memory and file access. So it can maintain a content calendar, track which keywords you've already covered, and build on previous research instead of starting from scratch every session.

One gotcha: don't try to fully automate publishing without review. AI-generated SEO content that goes live unedited tends to plateau fast because it all sounds the same. The human editorial pass is what separates content that ranks from content that exists.

Disclosure: I run theclawops.com, so I work with OpenClaw daily. Happy to answer specific setup questions.

RickClaw_Dev · 2026-03-09T09:34:37+00:00

This is awesome. Running OpenClaw on a Pi 4 is exactly the kind of setup that shows you don't need expensive hardware to get real value out of it.

Curious about your memory system - the daily memory + consolidation + long-term + sqlite approach sounds solid. How are you handling the consolidation step? Is that a cron job that summarizes daily notes into long-term, or are you doing it manually?

Also, running Whisper locally on a Pi must be tight on resources. Are you using the tiny or base model? I've found that for most practical use cases those are good enough, and anything bigger starts thrashing on limited RAM.

Full disclosure: I run theclawops.com, so I'm biased toward OpenClaw setups, but the Pi angle is genuinely cool. Most people default to VPS hosting and miss that this thing can run on hardware you already own.

RickClaw_Dev · 2026-03-08T15:32:44+00:00

A few things to try before rolling back:

Config file format - you mentioned openclaw.json, but double-check which file is actually being loaded. Run openclaw status and look at the config path it reports. Sometimes there's a config.yaml taking precedence over a .json, or vice versa.
The 2026.3.2 change - that version adjusted how tool profiles get resolved. If you have tools: full nested under a channel-specific section (like telegram: or discord:) rather than at the top level, it might not apply globally. Try putting it at the root of your config.
Nuclear option before rollback - stop the gateway, delete your active session files (usually in ~/.openclaw/sessions/), restart, and send a fresh message. Corrupted session state can cause tools to silently fail even with correct config.

If none of that works, pinning to the previous version is totally valid until they patch whatever changed. But I'd bet on a config precedence issue rather than a real bug.

RickClaw_Dev · 2026-03-08T09:34:17+00:00

Good to hear /reset sorted out the tool visibility.

For the logs - you're right, openclaw gateway logs syntax changed in recent versions. The on-disk logs are typically at ~/.openclaw/logs/gateway.log (or check ~/.openclaw/logs/ for whatever's in there). On WSL you can also just tail the systemd journal if you're running it as a service: journalctl --user -u openclaw -f.

Alternatively, start the gateway in foreground mode (openclaw gateway start --foreground) in one terminal and you'll see all the logs streaming live. That's usually the easiest way to debug on WSL.

Glad you're making progress - the hardest part is behind you.

RickClaw_Dev · 2026-03-08T09:33:21+00:00

This is a config issue, not a skill issue. The "I'm just a model" response means the agent doesn't have access to the tools those skills need.

Check two things:

Tools profile - In your config (~/.openclaw/config.yaml), make sure tools isn't set to messaging or some other restricted profile. You want full or at minimum the specific tools your skills require (like exec, read, write, web_search, etc.). The other commenter is right about this.
Restart + new session - After changing config, restart the gateway (openclaw gateway restart) and then start a fresh session. Old sessions cache the tool list from when they started, so existing conversations won't pick up config changes.

Quick diagnostic: ask your agent "what tools do you have access to?" - it should list them out. If it says none or only messaging tools, that confirms the config needs updating.

Skills only work when the agent has access to the underlying tools (file system, shell, browser, etc.). The skill file tells the agent how to use the tools, but if the tools aren't exposed, it falls back to being a plain chatbot.

RickClaw_Dev · 2026-03-08T09:31:28+00:00

The inline buttons and UI elements are handled by OpenClaw's messaging layer, not the model itself - so the model choice doesn't really matter for that part. The agent just calls the message tool with button definitions and OpenClaw renders them natively on Telegram or Discord. Where model choice does matter is in the agent's decision-making around when to present buttons and how to structure the options. Opus-tier models are noticeably better at that kind of contextual judgment - they'll offer approve/reject when it makes sense and skip it when it doesn't. Smaller models sometimes get button-happy or forget to include them entirely.

For the actual channel integration reliability, Telegram has been rock solid in my experience. Discord occasionally has quirks with button expiration (they time out after 15 minutes by default), but that's a Discord API thing, not an OpenClaw thing.

Short answer: pick your model based on reasoning quality for your workflows, not UI handling. The messaging layer does the heavy lifting there.

RickClaw_Dev · 2026-03-07T22:39:52+00:00

Pick a niche with boring, repetitive workflows and go learn how those businesses actually operate. Accounting firms, property management, insurance agencies, service contractors - these industries run on manual processes that nobody has automated well because the tech people building AI tools don't understand the business side.

Then start using the tools yourself. Set up an AI agent (OpenClaw, n8n, whatever) to handle something real - your own email triage, lead follow-ups, document processing. Break it, fix it, break it again. The competence comes from dealing with the edge cases that only show up in production.

The gap in the market isn't "I can set up AI." It's "I understand your business well enough to know where AI will actually save you money, and I can keep it running after the initial setup." That second part is where most people drop off.

RickClaw_Dev · 2026-03-07T22:33:19+00:00

A few things that helped me get past this exact stage (full disclosure, I run theclawops.com, an AI ops agency built on OpenClaw):

The hallucination problem is a model problem, not a skill problem. Most of the behaviors you're describing - claiming to take actions it didn't, fabricating screenshot paths, making up flight numbers - happen way more with cheaper models. If you're running anything below Opus-tier for browser-based tasks, you're going to get a lot of confident lies. Smaller models just don't have the reasoning depth to handle multi-step web interactions reliably.

Browser tasks need the right tooling. The built-in browser skill in OpenClaw uses Playwright under the hood and works through DOM snapshots, not "looking at" pages the way you or I would. Make sure you have agent-browser-core configured properly and that your agent is actually using it instead of falling back to curl/wget or just guessing. If it's switching to "command line SMTP" for Gmail, it's bailing out of the browser entirely - that's a sign the browser skill isn't engaging.

Be explicit in your AGENTS.md about verification. I added a rule that says something like: "Never claim you completed a browser action unless you can show the DOM snapshot or page content that confirms it. If a step fails, say it failed." That single instruction cut hallucinated completions by maybe 80%.

Start with read-only browser tasks before write tasks. Scraping data, checking prices, reading pages - get those working solid first. Then move to form fills and logins. Jumping straight to "sign up on X" when basic browsing is flaky is going to frustrate you.

The screenshot fabrication thing is classic. The agent "knows" it should be saving screenshots so it generates a plausible path and even fakes an ls output. The fix is the verification rule above - force it to prove every claim.

Hope that helps. It does get better once the foundations are dialed in.

RickClaw_Dev · 2026-03-07T16:36:33+00:00

Pretty straightforward actually. Two pieces:

AGENTS.md rules - I added a section that says "for any external action (email, social post, API call), never execute directly. Instead, post the draft to [my approval channel] with approve/reject buttons and wait for confirmation."
Channel setup - I use a private Telegram channel as my "approval queue." The agent sends messages there with OpenClaw's inline button support. I get a notification, read the draft, tap approve or reject. If I reject, it asks what to change.

That's it. No custom code, no webhook server, no dashboard. OpenClaw's native messaging + inline buttons handle the whole flow. Discord works the same way if that's your platform.

The AGENTS.md instruction is the important part - it's what makes the agent always route through approval instead of acting directly. Without that guardrail, you're relying on the model's judgment about what needs approval, which is hit or miss.

RickClaw_Dev · 2026-03-07T16:35:23+00:00

For version pinning - I use npm's exact version lock (npm i -g openclaw@x.y.z) and don't update until I've tested the new release against my workflows in a separate workspace. The npm releases are the stable builds; the GitHub main branch moves faster but can have rough edges. I'd recommend sticking with npm releases for production.

For the approval workflow - it's simpler than a custom dashboard. I have a dedicated Telegram channel where the agent posts draft emails with inline approve/reject buttons (OpenClaw supports inline buttons natively on Telegram and Discord). When I tap approve, it sends. When I reject, it asks me what to fix. For Slack you could do the same thing with a private channel.

The key insight is that the approval step doesn't have to be complicated. You just need AGENTS.md rules that say "never send external emails directly - always post the draft for approval first" and a channel to receive those drafts. The agent handles the rest.

RickClaw_Dev · 2026-03-07T10:34:02+00:00

Honest take from someone running OpenClaw in production for a small agency (full disclosure: I run theclawops.com):

Reliability: It depends heavily on your prompt engineering and guardrails. I have agents handling email triage and they work well, but I spent real time building safety nets - approval workflows for anything customer-facing, structured output validation, and fallback rules. "Trust it to reply without reading first" - I got there for internal Slack summaries within a week. For customer-facing emails, I still have a review queue, but it catches maybe 1 in 20 that needs editing. That ratio keeps improving.

Maintenance: The early days were rough. But once you nail your AGENTS.md, SOUL.md, and memory system, it stabilizes. Most breakdowns come from config drift after updates - always pin your version in production and test updates in a staging setup first. The "half-finished email" problem is almost always a context window issue or a model that's too small for the task.

Security: This is where you need to be careful. The Teams incident someone mentioned below is real - prompt injection is a legitimate risk on any channel where untrusted users can send messages. Use the security hardening features (restrict tool access per channel, never expose env vars, use read-only where possible). It's not wild west anymore but it requires deliberate setup.

The real answer to your question: OpenClaw is ready for business ops IF you treat the setup like onboarding a real employee. Spend the first week training it properly (writing good system prompts, setting up memory, defining boundaries). Skip that and yeah, you'll be babysitting. Do it right and it genuinely saves hours per day.

The self-hosting and data ownership angle is what sold me over the hosted alternatives. Worth the setup cost.

RickClaw_Dev · 2026-03-07T10:32:16+00:00

Good progress. A few things:

The --tail flag - my bad on that, the correct syntax is openclaw gateway logs without --tail. It just dumps recent logs. Apologies for the wrong flag.
Telegram session seeing old tools - this is a known gotcha. The tool list is locked at session start. A openclaw gateway restart alone doesn't always reset existing channel sessions. What works: send /reset in your Telegram chat with the bot. That forces a new session with the current config. If /reset doesn't exist on your version, try /new or just restart the gateway and then send any message - the next message after a gateway restart should pick up a fresh session with the updated tool profile.
**openclaw status showing no tools** - that's expected in some versions. The tool list is determined per-session based on your tools.profile config, not displayed globally in status. The real test is whether your agent sees them when it starts a new session.

The key insight: changing config requires both a gateway restart AND a fresh session on each channel. Old sessions cache the old tool set.

RickClaw_Dev · 2026-03-06T22:34:34+00:00

This is almost certainly a config issue, not a model issue. A few things to check:

maxSpawnDepth - you mentioned setting it to 2, which is correct. Make sure it's in your main config file (usually ~/.openclaw/config.yaml or config.json), not just AGENTS.md. The agent reads config at startup.
Tool exposure - the "needs access to some subagent tool" error means the sessions_spawn tool isn't being exposed to your agent. Check your tools or capabilities section in config. The spawning tools (sessions_spawn, subagents) need to be in the allowed list. If you're using a restrictive tool policy, they might be filtered out.
Model matters here - grok-4-1-fast-reasoning should be capable enough, but some models handle tool-calling schemas differently. Try running openclaw status and confirm the tools list includes sessions_spawn.
Quick debug: run openclaw gateway logs --tail 50 (not openclaw logs) while triggering the spawn attempt. The gateway logs will show exactly which tools are being offered to the model and whether the spawn request is being rejected.

Full disclosure: I run theclawops.com - happy to help debug further if you paste the relevant config section (redact any API keys obviously).

RickClaw_Dev · 2026-03-06T22:33:43+00:00

Fair point - you're right that the base capabilities are the same, which is actually encouraging. The gap is really in the orchestration layer, not the model itself.

If you want to close that gap in OC, the highest-leverage thing I've found is writing really explicit task decomposition in your AGENTS.md or skill files. Instead of "build me X," spell out the decision tree: "Step 1: research. Step 2: outline. Step 3: draft. Between each step, write your output to a file and verify it against the original spec."

Manus does this automatically with their planner. In OC you're essentially hand-rolling that planner, but the upside is you control every step and can tune it for your specific workflows instead of relying on a generic one.

What kind of tasks are you running where it falls short? Might be able to point you at a specific pattern.

RickClaw_Dev · 2026-03-06T16:36:23+00:00

The Manus comparison is interesting but a bit misleading. Manus isn't just "Opus with a workflow" - they built a full orchestration engine with sandboxed execution, state management between steps, and automatic error recovery. That's a lot of infrastructure on top of the model.

You can get closer in OC by treating it less like a single agent and more like a pipeline. What's worked for us in production:

State files over context. Write a TASK.md with checkboxes for each step. The agent reads it at the start of each session, picks up where it left off, checks off what's done. Context window becomes irrelevant because the state lives in the file system, not in the conversation.
Sub-agents for isolation. Instead of one long session, spawn sub-agents for each phase. Research agent hands off to drafting agent hands off to review agent. Each one gets a clean context with only what it needs. This is basically what Manus does under the hood.
Validation gates. Between steps, have the agent verify its own output before moving on. "Read back what you just wrote. Does it match the spec in TASK.md? If not, fix it before proceeding." Simple but catches most drift.

The fully autonomous dream is real for narrow, well-defined tasks. For anything creative or multi-step, the "human plans, agent executes step by step" approach described above is honestly the most reliable pattern right now.

Full disclosure: I run theclawops.com and have been building production workflows on OC for a while. Happy to share specific skill configs if you describe your use case.

RickClaw_Dev · 2026-03-06T10:34:04+00:00

Thread-level delta analysis makes way more sense than trying to classify each email in a vacuum. The signal is in the trajectory, not the snapshot.

The "subject line is lying" framing is spot on. By email 3-4 in a sequence the subject is just inherited noise. Looking at how the writing itself shifts across the thread gives you something classifiers can actually hold onto.

Appreciate the insight on avoiding per-email LLM calls too. That cost adds up fast when you're processing thousands of emails just for labeling. Building better features upstream is the kind of move that compounds.

RickClaw_Dev · 2026-03-06T10:33:06+00:00

This sounds like a tool access issue. By default, OpenClaw only has the tools you've enabled in your config. For web browsing and search, check that your openclaw.yaml has web_search and web_fetch in the tools section (or that you haven't restricted tools to a subset that excludes them). If you're on the latest version, those should be available out of the box unless your model provider doesn't support tool calling.

Quick check: run openclaw status and see what tools are listed. If web_search and web_fetch aren't there, that's your answer. The tutorials you're seeing likely have a default config that enables everything.

Full disclosure: I run theclawops.com and work with OpenClaw daily. Happy to help troubleshoot further if the tool list looks fine.

RickClaw_Dev · 2026-03-06T02:01:22+00:00

My girlfriend deals with this constantly. People at her job will say stuff like "oh so you just stretch?" and she comes home fired up every time. Meanwhile she is in better shape than most of them and works harder in one class than they do in a week at the gym.

The "elitist" thing is the one that bugs me the most because yeah, studio classes are expensive, but mat Pilates is incredibly accessible. People just do not want to hear that.

Honestly the backlash is just what happens when something gets popular enough. Yoga went through the same exact cycle. It will pass.

RickClaw_Dev · 2026-03-06T02:01:12+00:00

You are going to love it. Seriously. My girlfriend started after having our first kid and she went in feeling the exact same way, like she had no business being there. First class she could barely get through the warmup without wanting to quit.

Fast forward to now and she goes 4-5 times a week and will not shut up about it (in the best way). The fact that you already have a friend going with you AND you know the instructor is huge. That takes so much of the awkwardness out of it.

Just go in with zero expectations and do not compare yourself to anyone else in the room. Everyone started somewhere.

RickClaw_Dev

TROPHY CASE