💭 Why I Built This (Real Problem, Not a Demo Idea)
A few weeks ago, I tried using OpenClaw to automate my email.
The idea was simple:
Let AI read emails, reply to them, and save me hours every week.
And technically… it worked.
Too well.
It drafted replies, categorized messages, even prepared follow-ups.
But then I realized something uncomfortable:
If this sends one wrong email, it’s not a bug it’s a real-world mistake.
That’s when I stopped trying to build a “fully autonomous agent.”
And started building something better.
🎯 What I Actually Built
I built:
GuardianClaw — a safe, human-in-the-loop email agent powered by OpenClaw
It:
- reads my inbox
- summarizes emails
- drafts replies
- organizes priorities
But most importantly:
👉 it never sends anything without my approval
🧪 What It Looks Like in Real Use
Here’s what actually happens when I run it.
I send:
“check my inbox”
It responds:
You have 5 new emails:
Urgent:
- Client payment failed
- Interview confirmation
Normal:
- Newsletter
- Product update
Suggested reply for payment issue:
"Hi, I noticed the payment didn’t go through..."
Approve sending this reply? (yes/no)
If I say yes → it sends
If I say no → nothing happens
No surprises. No silent actions.
🏗️ How I Built It (Actual Architecture)
I kept the architecture simple but intentional:
Telegram / CLI
↓
OpenClaw Gateway
↓
LLM (Ollama / API)
↓
Custom Skill Logic
↓
Execution Layer
↓
Email + Notifications
The key idea:
👉 Execution is gated, not automatic
🔧 The Core Skill I Wrote
This is the actual logic that drives everything:
# GuardianClaw Email Agent
## Objective
Manage inbox safely with human approval
## Rules
- NEVER send emails automatically
- ALWAYS ask for confirmation
- CLASSIFY emails (urgent / normal / spam)
## Workflow
1. Fetch unread emails
2. Analyze and summarize
3. Generate reply drafts
4. WAIT for approval
5. Execute only if approved
⚙️ What’s Happening Behind the Scenes
1. Email Fetching
I used a simple IMAP-based script:
import imap from "imap-simple";
export async function fetchEmails() {
// Connect to inbox
// Pull unread messages
return emails;
}
2. AI Processing
OpenClaw sends email content to the model, which:
- classifies importance
- summarizes content
- drafts replies
3. The Safety Gate (Most Important Part)
This is where everything changes:
if (userApproval === true) {
sendEmail(draft);
} else {
discardDraft();
}
No approval = no action.
🔐 Security Decisions I Made (After Breaking Things Once 😅)
I didn’t get this right the first time.
At one point, I accidentally left my gateway exposed — and realized how risky this setup can be.
So I rebuilt it with security-first thinking.
🛡️ 1. Local-Only Gateway
openclaw config set gateway.bind "127.0.0.1"
Now:
👉 nothing is exposed to the internet
🔑 2. Strong Authentication Token
openclaw config set gateway.token "very-long-random-token"
🌐 3. Private Remote Access (No Port Forwarding)
Instead of exposing ports:
tailscale serve localhost:18789
Now I can access it from my phone securely.
🧨 4. Docker Sandboxing
This was non-negotiable.
{
"sandbox": {
"mode": "all",
"workspaceAccess": "ro"
}
}
Even if something goes wrong:
👉 it happens in a container, not my system
🧬 5. Local AI for Privacy
I didn’t want my emails going to external APIs.
So I used:
ollama run llama3.3
Now everything runs locally.
🧪 Real Results After Using It
After a few days of using this:
What improved:
- I spend less time checking email
- I don’t miss important messages
- Replies are faster and more consistent
What didn’t break:
- No accidental sends
- No weird AI behavior
- No security scares
That last part matters the most.
🤯 What This Project Taught Me
1. Full automation is not the goal
The goal is:
safe automation
2. AI agents amplify consequences
A small mistake becomes:
👉 a real action
3. Guardrails are more important than features
The best feature I added wasn’t AI.
It was:
👉 the ability to say “wait.”
🚀 What I’d Improve Next
- Calendar integration
- Slack notifications
- Priority scoring system
- Multi-account support
🏁 Final Thoughts (What I Actually Believe Now)
OpenClaw is one of the most powerful tools I’ve used.
But it’s also one of the easiest to misuse.
You can build:
- a productivity machine or
- a self-inflicted security problem
The difference is not the tool.
It’s how you design control.
🧭 Final Conclusion
After building and using this system, one thing became very clear:
The future of AI agents is not autonomy — it’s controlled autonomy.
Anyone can build an agent that acts.
Very few build one that knows when not to act.
And that’s the real shift.
We’re moving from:
- “AI that can do everything”
to:
- “AI that does the right things, at the right time, with the right boundaries”
That’s what I tried to build with GuardianClaw.
Not an agent that replaces me.
But one that works with me, safely.
And honestly?
That’s the only kind of AI I trust running on my machine.
Top comments (1)
Building this actually changed how I think about AI agents.
At first, I was trying to make it fully autonomous — read emails, reply automatically, handle everything. It worked technically, but it didn’t feel safe. One wrong reply and it’s a real-world problem, not just a bug.
So I shifted the design toward “controlled autonomy,” where the agent does the heavy lifting but pauses before taking action. That single change made the system feel much more usable and trustworthy.
Also learned the hard way that default setups are not safe enough 😅 — things like local binding and sandboxing are not optional if you're letting an agent touch your system.
If anyone else is building with OpenClaw, I’d love to know:
Are you going fully autonomous, or keeping a human-in-the-loop?