I Tried to Automate Gmail Outreach with Open Claw. It Kept Going in Circles Until I Changed the Rule.

I thought automating Gmail outreach would mostly be a prompting problem.

It wasn’t.

It took me 3 days just to get the setup working properly. And that was before the actual workflow even started.

For a while, everything that followed kept going in circles.

What finally changed things wasn’t better prompts.

It was changing the rule.

---

1. I wanted a clean, local setup (no tokens, no SaaS)

I didn’t want to pay for tokens.

I didn’t want to depend on APIs.

I didn’t want to build something that could become expensive or fragile later.

So I decided to run everything locally.

A dedicated macOS user. Docker isolation. Network control with LuLu. Local models via Ollama.

On paper, that sounds clean.

In reality, it was friction everywhere.

OpenClaw is still quite cloud-oriented in practice. Getting it to run cleanly in a local-first setup took much more work than I expected.

What I thought would take 3 hours took 3 full days.

Most of that time went into switching users, debugging environments, fixing configs, and getting the right Ollama model to actually run.

The hard part started before the workflow even began.

---

2. After that, I brought Codex in on purpose

Once the setup finally worked, I changed strategy.

After spending 3 days just getting the environment stable, I decided to use Codex for everything else.

There was too much debugging to do manually. Without it, I would probably still be stuck.

But the goal wasn’t to depend on Codex forever.

The goal was to use AI to build a system that would stop depending on AI for every step.

I wanted repeatable workflows, local scripts, a tracker, and simple rules.

Not an agent clicking things forever.

---

3. The actual task was simple

I already had Gmail drafts ready.

The workflow should have been simple.

Pick a draft. Send it. Record it. Move on later.

That’s it.

But the system kept trying to solve something much more complicated.

---

4. Where everything started to go wrong

The system kept converging on the same idea.

Read all drafts. Understand them. Match them. Come back later. Send the right one.

Every iteration sounded reasonable.

It should work now.

We just need one more refinement.

The logic is almost there.

But it wasn’t.

We were refining something that sounded right but never actually worked in practice.

It was looping.

The AI struggled with consistency, with ambiguity, and with re-identifying the same draft later in a dynamic interface.

So we kept improving something that fundamentally didn’t hold.

---

5. The moment I stopped the loop

At some point I stopped trusting the approach entirely.

The breakthrough came from me working with the AI, not from the AI alone.

Instead of trying to read everything and reconcile state later, I changed the rule.

For existing drafts, the system now does this.

Take the latest draft. Send it. Log it after the send.

No matching. No reconstruction. No fragile logic.

That single change did more than all the previous iterations combined.

We hit the same pattern elsewhere.

The system tried to read too much, infer too much, generalize too early.

I simplified again.

Just read the last visible line.

That worked.

Because it was smarter and simpler.

And in this kind of workflow, smarter means simpler.

---

6. What finally worked

The system only became reliable once I split it into two modes.

Backlog mode.

Send the latest draft. Log it after the send.

Future mode.

Create the row in the tracker first. Define status and schedule there. Attach the content there. Use Gmail only as the execution layer.

That led to a rule that should have been obvious earlier.

The tracker is the source of truth.

Gmail is the execution layer.

Once that became explicit, everything got easier.

---

7. What I’m taking from other tools

I’m also looking at tools like PinchTap or CloseSec.

Not to copy them, but to understand what they do well.

Clear tracking. Simple flows. Visible logs. Predictable behavior.

But my constraint is different.

Everything runs locally. Minimal dependency on tokens. Full control.

So the goal is to extract good patterns and adapt them to a local-first system.

---

8. What this taught me about AI automation

The AI was part of the bottleneck.

Not because it’s bad.

Because the problem is messy.

The interface is ambiguous. The state is unstable. And iteration alone doesn’t guarantee convergence.

What actually made the difference was not better prompting.

It was stopping the loop, simplifying aggressively, and making the right decisions as a human working with the AI.

AI helps.

But it doesn’t automatically converge in real-world workflows.

---

9. Where I am now

This is still in progress.

I’m extending the system, improving reliability, and adding new channels like LinkedIn.

This is not a demo.

It’s something that is starting to actually run.

---

10. Discussion

If you’re working on similar systems, I’d be curious.

Where did your workflow go in circles?

What simplification unlocked things?

How do you handle messy interfaces?

Happy to compare notes.