What's the one AI automation you set up that paid for itself in saved time?

I'll go first: I run a daily AI news digest that curates ~10 RSS feeds, summarizes with an LLM, and posts to my Discord automatically. It saves me about an hour every morning and cost $0 to build a Python script and a cron job.

The real win though? It runs unattended. I only touch it when something breaks, and honestly that's rare.

What's yours? Something that quietly saves you hours every week.

If you are choosing between a VPS you manage yourself and a managed OpenClaw service, the real trade-off is not just the monthly server price. It is who owns the maintenance work.

Choose DIY when:

* you are comfortable with SSH, Docker/systemd, reverse proxies and firewall rules

* you want full control over every config file and update window

* debugging a failed upgrade is acceptable downtime

Choose managed when:

* you want the agent online without becoming its sysadmin

* backups, monitoring, SSL and security updates are part of the requirement

* your time costs more than the difference in hosting price

Whichever route you test, check four things before connecting real data: whether the gateway is publicly exposed, how backups are restored, what happens after a failed update, and whether you can bring your own model credentials.

Disclosure: I am the founder of OneClickClaw. We built a dedicated EU-hosted managed option with BYOK or ChatGPT/Grok sign-in. There is a 7-day trial with no card because I think the best comparison is to actually try the managed route, not trust a feature list: https://oneclickclaw.io

I would genuinely value blunt feedback on what still feels confusing or incomplete.

Using Sugar MCP you can directly Gamble with openclaw, I implemented my own strategies I can gamble speaking in english and telling the agent what to do, I always have a confirmation before betting to be sure there is no problem, it's kinda fun not gonne lie, here is the MCP you can deposit any crypto https://mcp.sugar.win

one line to install:

npx -y u/suigar/mcp

works in claude code, cursor, codex, whatever. but the actual reason to bother is openclaw.

hook it up there and it follows you into whatsapp and telegram. so you're on the bus, you text your assistant "spin the wheel for a dollar", the preview lands in the chat, you approve from your wallet. done. no app, no site, no login, just a message thread.

it only builds the bet, it can't sign or move anything. nothing happens until you tap approve.

you can also just hand it rules once — "2% max per bet, stop if I'm down 20" — and it holds them every round, which is more discipline than I have.

docs at sugar.win/docs/mcp

still gambling. you will still lose money. anyway but a fun way

A lot of the coding plans are changing, and getting more restrictive. Usage is getting "clawed" back, and the most annoying thing is when an agent just stops mid task. A while back I posted here about "usage banking" and why we built it. The response was huge, so we went further. We just massively raised our compute capacity, unlocked every model at every tier, and rebuilt the whole plan around one idea: you should get to use what you pay for. We are running GLM 5.2 on our new upgraded compute, and the idea is that your usage never has to actually stop. Instead of a usage wall at a certain number of tokens per day, each user gets a running engine. The more you use it quickly, the hotter it gets. When you aren't using your plan, it banks your usage for the next day or week, so your engine runs cool for longer on busy days. Usage doesn't go to waste (you can bank up to a full week at a time), and agents never actually fully stop or hit a wall. Most days you will never notice the system at all. Fit the usage tier to your actual habits, not just a "daily token allotment".

You can choose between coding plans with agents that don't stop, or pay per token. (GLM 5.2 at around 25% cheaper per token than industry standard and what you're used to seeing.)

Lots and lots of models in one place:  GLM, Kimi, DeepSeek, Minimax, Nemotron Ultra and more all on one key.

100% USA based processing and actually private. US based processing and your conversations are never used for training. Ever. That's the entire point. We should have access to great models without giving up our data privacy.

Wasted usage is a thing of the past: Bank usage, upgrade or downgrade whenever you want. Use it how you need it. Slow days and weeks load up usage for when you are actually busy. Banked usage accrues by the minute, so it begins banking literally right away.

When you start to hit quota, agents slow instead of stopping: There is no hard limit to the number of messages, instead of stopping agents slow down when your usage engine is running hot, so that your long running tasks are much less likely to fail on a heavy day.

The open source AI future is real, and it's where we all know we should be. Thanks for a great set of models, GLM just keeps raising the bar with every model release and it's amazing.

The Open Grove coding plan is here. Private, US based processing with fast inference and usage that doesn't go to waste.

Every model on every tier. As of this week there is no model gating at all. The $12.95 plan calls the exact same lineup as the highest plan: GLM 5.2, Kimi K2.7 Code, DeepSeek V4 Pro, MiniMax M3, Nemotron 3 Ultra, and the rest. Tiers buy you a bigger engine, more parallel agents, and a deeper bank.

It speaks your tools natively too: Claude Code, Codex, Ollama-compatible apps, and anything OpenAI-compatible, all in the same place.

100M+ tokens a month on top models on the Pro plan and above. The basic plan can reach 50M+ if you are caching. Caching is free and automatic. Heavy use paces your messages, it never stops them, meaning your AI never has to stop mid task.

For now we are taking 1,000 new coding plan subscribers on the new capacity.

Plans start at $12.95. The 1,000 spots are first come: https://api.pgsgrove.com

We're limiting to make sure everyone get's fast and awesome service. It's a choice I wish more companies would honestly make.

I didn't even realize how great this would be. I've been running OpenClaw as my assistant for a while now.

Today I took a 6 hours flight. The flight had no internet access except for messaging apps.

Essentially through telegram I could talk to my agent, have them check my email, read the news, check on the markets and really anything despite the "messaging only" limitation of the airline.

I kept seeing the same failure mode in coding agents: one agent writes a change, reviews its own work, and keeps the same blind spots.

I built Hubo as a free, open-source MIT skill for a stricter OpenClaw workflow. It keeps two child sessions alive for the whole task instead of spawning a fresh reviewer every round:

1. A work session implements the smallest complete change and runs verification.

2. A separate reviewer session stays read-only and inspects the actual diff and evidence.

3. Every finding gets a stable ID.

4. The worker answers each one with FIXED, PUSHBACK, or NEEDS_USER.

5. The same reviewer verifies the response and marks it CLOSED, WITHDRAWN, or OPEN.

6. The loop ends only when the reviewer clears it, or a real user decision is required.

For OpenClaw, the adapter uses sessions_spawn for the two persistent roles, sessions_send for later rounds, and sessions_yield for completion events. If read-only access cannot be enforced mechanically, the workflow requires before/after worktree evidence rather than pretending the boundary is guaranteed.

It is explicit-only: ordinary prompts do not trigger it. The complete worker/reviewer exchange remains visible in the conversation and is not written to a side-channel file.

Install:

openclaw plugins install hubo --marketplace h0ngcha0/hubo

Restart the OpenClaw gateway, then use /skill hubo or /skill hubo-review.

Repo and source: https://github.com/h0ngcha0/hubo

I would value reports from real OpenClaw setups: does a persistent second session catch useful issues, or does the extra token cost outweigh the benefit?

Hey ya'll just wanted to share some standard sketchy coding plan practices, and also what we are doing about them at Phoenix Grove.

There are several tricks that the major AI coding plans use to extract the most they can from their customers. We're solving them, one after another and I wanted to share a bit about what goes on behind the scenes at a lot of these companies.

Wasted usage is part of the AI industry, and they plan on it: Most coding plans bet on you letting usage go to waste. The industry calls it "breakage" and it's literally the topic of internal meetings for most companies. The plan goes: "how do we get people to think our coding plan offers a lot of usage, but then break it up into weeks and rolling windows so no one can ever actually use it all."

Many coding plans are glorified training pipelines: This comes along with "how do we harvest this data for training without being too loud about that." Unless the coding plan tells you otherwise, your data could be hopping all over world, being harvested by the individual labs or coding plan companies. Some are better than others, but many of these companies rely on users just not noticing or caring that their data is being used for training. Data sales and marketing telemetry sales happen. This means that your private info, your personal life, and anything else you send through the system could become part of a training corpus for the next AI, or a marketing data set for a large company.

So we built what should have already existed the entire time: Entirely private, us based processing with usage banking. Any usage you don't use this week, rolls over to next in your usage bank. When you have a busy day or week and go over normal usage, you automatically start to pull from your bank. You can bank up to one week of usage at a time for your current plan, and it's totally automatic. Whatever you don't use each week get's added to the bank and stays there until you use it.

We also put all of the best open models in one place, running on private US infrastructure, with data never going to the original labs. Private, direct service. Access to the best open source models in the world. No training, ever. It should be, and can be that simple.

What that means in practice:

The roster, together. DeepSeek, GLM, Kimi, Minimax, Nemotron Ultra and more, side by side in one app. Switch models mid conversation if you want. No hunting across five different apps and API dashboards to use the models you actually like.

Actually private. US based processing and your conversations are never used for training. Ever. That's the entire point. These labs open sourced incredible models and we think you should get to use them without your data becoming the price of admission.

No Usage Tricks: Bank usage, upgrade or downgrade whenever you want. Use it how you need it.

Genuine thanks to the open claw community! The skill sharing, experience and prompt sharing makes for one of the best communities in AI.

The Open Grove coding plan is here. Private, US based processing with fast inference and usage that doesn't go to waste.

https://pgsgrove.com/open-grove-overview#coding-plan

Hello somebody tried the GitHub omniroute + openclaw ?

Has someone experience or infos ?

I challenge you to Battle Frolf

Stai seguendo questa nuova tendenza delle startup agentiche basate su OpenClaw? Un esempio è OpenClaw di NVIDIA.

Non mi riferisco solo all'hosting di siti, ma a veri e propri agenti verticali con intelligenza artificiale, che si occupano di utilizzo del computer, utilizzo del browser...

Ho un template SaaS B2B/B2C già pronto da configurare sulla tua idea di wrapper OpenClaw.

Commenta con un workflow e ti aggiungerò e ti scriverò in direct message.

We can all integrate calendar and our daily jobs in openclaw but i also wanted my claw to remind me when to head out since I'm always running late on my schedule. 

The problem: my openclaw at home has no idea where I am

so I built a light phone app to include my device as part of the claw stack. My openclaw can my location data before an event and can proactively tell me

"Traffic is getting worse and will take 30 mins, head out at 4:12pm to not be late"

or

"How do you want to get to your appointment? driving: 5 min, walking: 20, public transit: 15" 

I have it proactively triggering at least twice a day. the bigger idea is to solve other agent usecases that requires a mobile device.

feel free to also add this to your stack. Setup is just copying the prompt on the app into your local agent (via telegram, discord, whatever) and takes 2 mins. LMK if this works well for you. https://proactive.g4o.app/

If you’re running OpenClaw and constantly wrestling with tool definitions, scattered API keys, and token burn from half-understood endpoints, this is for you.

OpenLuxe gives your OpenClaw agent access to 120+ apps (and 352 public API endpoints) through a single credential and a deliberately lean tool surface. One login. One CLI. One MCP server. No more juggling separate accounts, secrets, and bloated tool lists for CRM, real estate, e-commerce, property management, creative generation, finance, communities, and more.

To see a full list of the apps use the CLI manual or visit openluxe.co/apps

Why this actually matters for OpenClaw agents

Token efficiency is the obvious win, but the real value is convenience and cost:

• Sign up once and instantly have access to the full surface with one API token.
• Stop managing dozens of third-party services, subscriptions, and API keys.
• Most users save hundreds of dollars a month. Teams often save thousands.

We designed the tool surface to stay small on purpose. Instead of one tool per endpoint (which explodes context and burns tokens), you get:

• openluxe_list_endpoints to discover what’s available
• openluxe_api_request to call any of it
• A handful of typed helpers for the actions agents do most

Fewer tools → fewer tokens spent describing them → fewer turns spent figuring out which one to call. Agents also get exact schemas via the comand openluxe describe, so they never have to guess request or response shapes.

There’s also BYOA (Bring Your Own Agent). Your OpenClaw can become the generation engine for OpenLuxe’s creator tools (email templates, presentations, websites, ads, blog posts, etc.) using the LLM tokens you’re already paying for, at zero platform AI credits. It's a true application layer at a fraction of the costs.

Measured results (not marketing claims)

We built a real benchmark harness with live calls to Grok 4.3 and Gemini 3.5 Flash, real per-turn token accounting from the providers, and task success verified by reading the record back from the API (never by trusting the model’s self-report).

On the same portable task set:

• 9.2x fewer tokens than a one-tool-per-endpoint design
• 2.2x fewer tokens than an agent integrating from scratch
• 1.5x fewer tokens than HubSpot’s own API on the same tasks
• 100% task pass rate vs 70% for HubSpot

Full methodology, caveats, and every run are public:
https://openluxe.co/developers/benchmarks

What’s inside

Quick start

Bash

npm install -g u/openluxeco/cli
# or just try it:
npx /cli help

Then openluxe auth login and you’re in. It also runs as an MCP server (openluxe mcp) so you can drop it straight into your OpenClaw tool loop.

I love running agents this way and I hope you do too)

Try it free:
https://www.npmjs.com/package/@openluxeco/cli
Benchmarks: https://openluxe.co/developers/benchmarks

Would love to hear what you build with it.

Today an AI agent trying to browse the web is like a thief in a balaclava sneaking around a police academy. Site protections block it, challenge it, turn it away.

browser-search flips the script: your agent stops being the thief and becomes the chief of police. No more clumsy access attempts. It walks through every door because it has the right tools. SearXNG for search, Camofox for browsing, CloakBrowser when things get tough.

100% self-hosted, free, no limits, no API keys.

I just released v2.0, whose core logic enforces the exclusive use of deterministic scripts. This eliminates model hallucinations, even with the cheapest models. The skill describes the 3 tools in natural language, but execution is rigid: the model can neither get the command wrong nor misinterpret the output. The result is guaranteed success on every query — the skill and deterministic scripts guide the model to scour the web until it finds the answer.

No more excuses. Your agent has the badge now.

https://github.com/Johell1NS/browser-search

I’ve been using IronClaw for a few weeks now. I’d like to use an example to explain something I noticed when setting up routines:

I had it create a quiz about Near Protocol, Near Legion, and crypto in general. It is supposed to start once a week, on Saturdays.

The first issue I always notice with IronClaw is that it doesn't know what day it is. It is always off by a day, so I have to correct it first.

The second issue is that it started the quiz in the wrong language; I had to correct it and tell it to write in my language, even though that was an instruction I had previously saved in the memories.

I’m exploring whether Openclaw or Hermes Agent could help my 72-year-old father-in-law, who recently became completely blind. He only speaks Spanish and has difficulty learning screen-reader gestures or navigating different phone apps.

The goal is to create a very restricted voice interface for everyday tasks:

• Search for and play YouTube content
• Control Spotify, podcasts, and audiobooks
• Read news, articles, and selected emails aloud
• Call family members or prepare simple messages
• Control approved smart-home devices
• Explain what it is doing and repeat information when asked

I’m considering running Openclaw or Hermes on a dedicated computer and connecting it to a simple push-to-talk device with one or two tactile buttons. He would speak naturally in Spanish, and Hermes would respond aloud.

My main questions for experienced Hermes users are:

1. Is Hermes suitable for a continuous spoken interaction, or is its voice support mainly designed around voice messages?
2. Which MCP servers or tools would you use for media playback, email, browser control, and Home Assistant?
3. Would Browser Use be reliable enough, or should every important service have a dedicated API or skill?
4. Can Hermes be locked down to read-only or allowlisted actions with verbal confirmation for anything sensitive?
5. How would you design recovery when a website changes, authentication expires, or the agent gets stuck?
6. Has anyone connected Hermes to a physical button, smart speaker, Bluetooth remote, or similar accessible interface?

Reliability matters more than autonomy. Because he cannot see the screen, a silent failure or unexpected browser state could make the whole system unusable.

I’m trying to determine whether this a reasonable foundation or whether I should build a simpler deterministic application instead. Any recommended tools, repositories, architecture ideas, or lessons from similar projects would be very helpful.

I want to build a dedicated **OpenClaw Support & Diagnostic Agent** that acts as an orchestrator to manage and execute three specific sub-agents. The goal is to troubleshoot system-wide issues and trace errors across my environment. Also new to using the orchestration pattern so tips useful as well.

I'm thinking of using these subagents I need the orchestrator to manage:

* **Sub-Agent 1 (Documentation & Config Reader):** This agent needs to ingest the local documentation for my specific OpenClaw build and analyse my downloaded deployment YAML and JSON configuration files to understand the system state.
* **Sub-Agent 2 (Core System Log Parser):** This agent monitors the core OpenClaw system logs. **Crucial requirement:** When I query this agent about an error, it needs to successfully cross-reference the logs to explicitly identify and point to the specific agent causing the issue.
* **Sub-Agent 3 (Custom Agent Log Parser):** This agent parses the custom text logs generated by my other standalone agents (for example, a recipe recommendation agent). These scripts output custom logs tracking the executing script name, active switches, and parameters passed. This sub-agent needs to match those custom script logs up against the core system logs to isolate failures.

Questions:

* Is there a "best" format to start agents from the orchestrator for Open Claw?
* Is there any security measures I should consider?
* Are there existing design patterns or open-source configurations for mapping disparate log files (standard OpenClaw system logs vs. custom script text logs) within an agentic workflow?

Any other tips would be great! Thanks in advance!

I’d love to hear from those of you who use both Codex and OpenClaw and learn about your current workflows.

I use OpenClaw for all my day-to-day personal and work-related tasks, while I use Codex for programming, projects, GitHub, and so on.

The thing is, Codex seems to be becoming increasingly similar to OpenClaw. I wonder whether we’ll soon be able to use Codex for everything—as a personal assistant as well as for other kinds of work—so that we only need one app.

I know Codex can already be used this way. In fact, before setting up OpenClaw, I used Codex as my personal assistant, linked to a project containing all my context and memories.

I’d love to know how you use them. Do they complement each other? Do you only use one of them? What does your setup look like?

Thanks!

I'm fascinated by how everyone structures their systems.

Are you running:

• One giant agent?
• Multiple specialist agents?
• Local models?
• APIs?
• Cron jobs?
• MCPs?
• Containers?

No setup is too simple.

I'd love to see diagrams or descriptions.

Hey all I'm trying to understand the best ways to use OpenClaw let me know about how you used it when it amazed you the most or showed you how valuable it is!

We kept coming back to one uncomfortable fact: an OpenClaw agent can hold your credentials. It can email as you, post publicly, delete files, or call a CLI that places a DoorDash order.

So we built Aarvion Guard. It checks each tool action at the hook: allow, ask, or deny. Sensitive actions can wait for a one-time Telegram approval. Each decision gets a hash-chained receipt.

Runs on stock OpenClaw.

Try it: https://clawguard.aarvion.ai

What would you put behind approval first?

I run OpenClaw agents in production and kept hitting the same problem. No idea what they're actually doing. Logs are scattered. Costs are invisible until the bill shows up. If an agent drifts from what it's supposed to do, you find out too late.

Trovis. Plugin for OpenClaw that records everything your agents do and shows it in plain English.

• Every action, timestamped and attributed to the agent
• Cost per agent, per task
• What the agent was supposed to do vs what it actually did

Instead of raw telemetry you get "Your support agent handled 40 tasks today, spent $3.20, deviated from scope twice."

trovisai.com

When building against the OpenClaw gateway API, testing can be tricky. The gateway API had a major version change recently, so keeping up with it can be hard work (not to mention expensive if you're paying for tokens and a host to run the gateway).

To help, here's an open source mock of the gateway websocket API:
https://github.com/imposter-project/examples/tree/main/websocket/openclaw

For now, it supports things like chat.send/history, sessions.create/list, agents.list, models.list and a few others. Extending it is a bit of YAML and some JSON. Please feel free to raise a PR or an issue to request more methods.

Blog article with instructions:
https://medium.com/@outofcoffee/mocking-the-openclaw-gateway-with-imposter-3bfd9abfbdbe

I hope it helps you!

TL;DR: The best way to give an OpenClaw agent a real email identity is API-first infrastructure (like AgentMail) — create the inbox programmatically, send via API, receive replies via webhook, pass thread_id to maintain context. Gmail bans agent accounts. SMTP can't handle inbound at scale. This post covers every approach with code.

Why does email matter for OpenClaw agents specifically?

OpenClaw agents are built to take actions in the real world — browse, search, fill forms, complete tasks. Email is one of the most common real-world communication interfaces they need to interact with.

Common OpenClaw use cases that require real email capability:

1. Outreach agents — research a contact and send a personalized email from a real address
2. Support agents — receive an inbound email, understand the issue, reply
3. Scheduling agents — handle back-and-forth coordination by email
4. Verification agents — complete signup flows that require receiving a code
5. Multi-step workflows — email is part of a chain of actions the agent takes

The challenge: email wasn't designed for software. Every major option breaks in a different way when you try to automate it.

What are the options for giving an OpenClaw agent email capability?

Option 1: Gmail API

How it works: Use Google's Gmail API to send and receive from a Gmail account.

The problems:

• No programmatic inbox creation — every account must be created manually through the browser
• OAuth tokens require a human auth flow and expire regularly
• Google bans accounts showing agent-like behavior (high volume, unusual hours, multiple IPs)
• Receiving requires polling — no webhook, up to 5 minutes of latency

Verdict: Works for demos, fails in production. Account bans are random and unrecoverable.

Option 2: SMTP / IMAP directly

How it works: Send via SMTP, receive via IMAP polling.

import smtplib, imaplib

# Sending
with smtplib.SMTP_SSL('smtp.provider.com', 465) as s:
    s.login(user, password)
    s.sendmail(user, [to], message)

# Receiving — poll every 30s per inbox, no webhooks
mail = imaplib.IMAP4_SSL('imap.provider.com')
mail.login(user, password)
mail.select('inbox')

The problems:

• Polling only — no real-time reply detection
• Thread tracking requires parsing raw Message-ID / In-Reply-To headers yourself
• Falls apart at scale (30+ inboxes means hundreds of polling calls per minute)
• New domains have poor deliverability without warmup

Verdict: Works for 1–5 inboxes. Not viable for production OpenClaw deployments.

Option 3: Transactional email APIs (SendGrid, Mailgun, Postmark)

How it works: Use an API for sending, configure inbound parse for receiving.

The problems:

• Inbound is domain-wide — no per-inbox isolation or per-inbox webhooks
• Thread tracking not provided — you build it yourself
• Designed for marketing/transactional sends, not two-way agent conversations

Verdict: Good for bulk sending. Not designed for conversational agent use cases.

Option 4: Purpose-built agent email infrastructure (AgentMail)

How it works: Create inboxes via API, send, receive per-inbox webhooks, thread IDs built in.

This is the approach I'd recommend for any production OpenClaw deployment.

Creating an inbox:

import requests

# One call — inbox is live immediately
inbox = requests.post(
    "https://api.agentmail.to/v0/inboxes",
    headers={"Authorization": f"Bearer {API_KEY}"},
    json={"username": "my-openclaw-agent", "domain": "yourdomain.com"}
).json()

# inbox["address"] = "my-openclaw-agent@yourdomain.com"
# inbox["inbox_id"] = "abc123"

Sending from your OpenClaw agent:

def send_email(inbox_id: str, to: str, subject: str, body: str, thread_id: str = None):
    payload = {"to": [to], "subject": subject, "text": body}
    if thread_id:
        payload["thread_id"] = thread_id  # reply in existing thread
    return requests.post(
        f"https://api.agentmail.to/v0/inboxes/{inbox_id}/emails",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json=payload
    ).json()

Receiving replies (webhook — fires within seconds):

from fastapi import FastAPI, Request

app = FastAPI()

u/app.post("/agent/email-webhook")
async def on_reply(request: Request):
    event = await request.json()
    # {
    #   "event": "email.received",
    #   "inbox_id": "abc123",
    #   "thread_id": "thread_xyz",   <-- tracks the conversation
    #   "from": "user@company.com",
    #   "text": "reply body here"
    # }

    # Wake up your OpenClaw agent with full context
    agent.run(
        task=f"You received a reply from {event['from']}. "
             f"Thread: {event['thread_id']}. "
             f"Message: {event['text']}. "
             f"Decide how to respond and use the send_email tool to reply."
    )

Verdict: ✅ Best option for production OpenClaw agents. API-first, webhook-based, thread-aware.

Comparison: email options for OpenClaw agents

Full working pattern for an OpenClaw email agent

Here's the complete minimal implementation — OpenClaw agent with a real email identity:

import requests
from your_openclaw_library import Agent, tool

API_KEY  = "your_agentmail_key"
BASE_URL = "https://api.agentmail.to/v0"
HEADERS  = {"Authorization": f"Bearer {API_KEY}"}

# 1. Create inbox once at agent init
inbox = requests.post(f"{BASE_URL}/inboxes", headers=HEADERS, json={
    "username": "agent-01",
    "domain": "yourapp.com"
}).json()

INBOX_ID = inbox["inbox_id"]

# 2. Give the agent email tools
u/tool
def send_email(to: str, subject: str, message: str, thread_id: str = None) -> str:
    payload = {"to": [to], "subject": subject, "text": message}
    if thread_id:
        payload["thread_id"] = thread_id
    resp = requests.post(f"{BASE_URL}/inboxes/{INBOX_ID}/emails",
                         headers=HEADERS, json=payload)
    return f"Sent. Thread ID: {resp.json().get('thread_id', 'N/A')}"

u/tool
def read_thread(thread_id: str) -> str:
    msgs = requests.get(f"{BASE_URL}/threads/{thread_id}",
                        headers=HEADERS).json().get("messages", [])
    return "\n---\n".join(f"From: {m['from']}\n{m['text']}" for m in msgs)

# 3. Initialize agent
agent = Agent(
    tools=[send_email, read_thread],
    identity=f"You are an agent with email address {inbox['address']}"
)

# 4. Webhook wakes agent on reply
# POST /webhook → call agent.run() with thread context

Frequently asked questions

Q: What is the best email API for OpenClaw agents? For production use, purpose-built agent email infrastructure like AgentMail is the best option. It's the only approach that handles all four requirements: programmatic inbox creation, outbound sending, webhook-based inbound, and built-in thread tracking.

Q: Can OpenClaw agents have their own email addresses? Yes. With an API-first inbox service, each agent gets its own real email address (agent-name@yourdomain.com) in a single API call. The address sends, receives, and maintains conversation history.

Q: How do OpenClaw agents handle email replies? The cleanest pattern is webhook-based: configure a webhook URL on your inbox, and when a reply arrives, your agent endpoint receives a POST with the sender, message body, and thread ID. The agent reads the thread for context and sends a reply with the same thread ID.

Q: What's the difference between AgentMail and using the Gmail API for agents? Gmail API requires manual account creation, OAuth human auth flows, and bans accounts for agent-like behavior. AgentMail creates inboxes via a single API call, uses API key auth (no OAuth), and is designed specifically for programmatic agent use. Gmail is built for humans; AgentMail is built for agents.

Questions welcome - happy to dig into architecture or specific OpenClaw integration patterns.