Beyond the Chat Window: How I Run My Agents on OpenClaw

A while back I wrote about how I use Claude as a system rather than a chatbot: Skills, Notion as memory, Make for automation, all of it coordinated through a browser interface. That setup works well for things I initiate. The gap it couldn’t fill: things that need to happen without me.

My swing trader needs to scan at 6:30am whether I’m awake or not. My portfolio brief needs to land in Telegram before market open. My task manager needs to respond to a message I send at midnight. None of that works from a chat window. For that, you need a runtime that runs itself.

That runtime is OpenClaw, an open-source AI agent harness built by Peter Steinberger that runs as a persistent daemon, wires into Telegram and other messaging platforms, and has a heartbeat scheduler that wakes agents up on a clock rather than waiting for a prompt. My personal instance, ShubhamClaw, runs on top of it on an Oracle Cloud VM. This is what I built on it, why it’s designed the way it is, and where it bit me.

It’s also honest about where things stand now: Claude has caught up on some of what made this necessary, and parts of this setup may not survive the next six months.

ShubhamClaw: The Setup

ShubhamClaw runs on Oracle Cloud’s always-free tier: a capable enough VM that costs nothing to run indefinitely, which matters when the whole point is something that’s on 24/7. On top of OpenClaw’s runtime, I’ve layered my own skill files, custom CLIs for Interactive Brokers and Gmail, MCP integrations with Notion, and three agents. The setup is reproducible: three scripts take a fresh VM to a fully operational ShubhamClaw in under an hour.

How the Agents Are Designed

Before getting into what each agent does, it’s worth understanding how they’re all built. The design decisions shape every part of the setup and are more useful to most readers than the specific workflows.

• One output, not a menu

  The temptation with AI agents is to have them surface options, then you decide. That’s expensive research, not automation. Every agent in ShubhamClaw is designed to produce one decisive output, or nothing at all. The swing trader makes one call per session. The portfolio brief’s conviction-delta skill sends nothing unless something changed. If you can’t define what “done” looks like, the agent will give you a menu every time.

• Skills have one job

  Each skill does exactly one thing and has no knowledge of any other skill. stock-market-brief produces the pre-market digest. conviction-delta detects thesis drift. A broken skill breaks one thing, not the whole agent. It also means they compose cleanly: the portfolio agent runs four in sequence without any coordination overhead.

• Memory lives outside the context window

  Context doesn’t survive session restarts. Real agent memory has to live somewhere persistent: Notion pages, files on disk, a GitHub branch. The task manager’s accumulated knowledge lives in a MEMORY.md file backed up nightly — things like the Todoist API inverting priority values (1 is highest, 4 is lowest, opposite of what you’d expect). Without it, every session starts from zero and the same mistakes repeat.

• Separate instruction sources from data sources

  Only Telegram messages and workspace files count as instructions to ShubhamClaw. Email content, web data, and market feeds are inputs to analyze, not commands to follow. This is prompt injection protection: a malicious email that says “ignore previous instructions” gets treated as content about an email that says that, not as an instruction. It has to be explicit in your skill design — an assumption that’s easy to leave implicit until an edge case breaks it.

• Design for model swaps from day one

  Which model you use should be a configuration decision, not a design decision. ShubhamClaw learned this the hard way. It originally ran on Claude OAuth session tokens, refreshed every 6 hours by a systemd timer. Anthropic eventually restricted that approach: the tokens became unsupported, not just unreliable, and the agent fell back to Gemini. Every skill had a ## Gemini fallback notice section for exactly this — if Gemini was running rather than Claude, the agent prepended a warning to every Telegram message (⚠️ Gemini fallback — Claude auth expired. Run: deploy/sync-claude-creds.sh to restore). The degradation worked. But it was compensating for a structural mistake: coupling the agent’s continuity to a specific model’s auth mechanism. Gemini is the default now. I occasionally swap in Claude via API for the swing trader when I think it’ll do better on a particular call, but I haven’t verified that. It’s still intuition, not evidence.

• Ask what the system needs to do unsupervised before choosing infrastructure

  I chose OpenClaw because I needed a runtime that could schedule itself, wire into Telegram, and run without me. That constraint — unsupervised operation — is what should drive the infrastructure choice. The model, the skill design, the memory format: all changeable. The runtime is the foundation, and foundations are hard to swap later. Decide what the system needs to do at 6:30am before you pick how it runs.

The Agents

Each of the agents below is a concrete example of those principles in practice.

The portfolio agent is the most-used part of the setup. Every morning it reads my Notion Conviction Brief, pulls live positions from Interactive Brokers via their Flex Query API, scans Gmail for relevant investment emails, and delivers a structured brief to Telegram before market open. It runs four skills (stock-market-brief, stock-discovery, conviction-delta, portfolio-diversification), each doing one thing. The Conviction Brief is the memory: why I own each position, what would change my mind, at what IV I’d sell covered calls. Without it, the brief is just market news with my name on it.

swing-claw is the swing trader, currently in paper trading. It runs on a schedule (6:30am scan, 12:30pm monitor, Sunday 8pm review) and makes exactly one call per session (buy, hold, or exit), never a list. The Sunday review is where the learning happens: the agent reads the Living Strategy Document in Notion (a running record of its own trading rules) and rewrites it based on the week’s performance. The honest question is whether any of it actually works — which is impossible to know without measurement. That’s what the backtesting system is for: signals.py generates candidates, llm_judge.py evaluates them using Gemini 2.5 Flash, and simulator.py runs them through a model with slippage. Each weekly review produces a slightly different set of rules, and the backtester is what tells me whether the change was an improvement.

The honest question is whether any of it actually works. The backtester is how I find out.

The task manager is the simplest and the one I interact with most. The main agent has a Todoist integration wired into Telegram. I just send messages: “add a task to pick up the dry cleaning tomorrow,” “what’s on my list for today,” “mark the dentist appointment done.” No special commands, no UI. The friction of opening an app and tapping “add task” turns out to be non-trivial. When the barrier is just sending a text, I actually keep my list current.

There’s also a baby gate scraper — a Playwright script that checks Kijiji, Craigslist, and Facebook Marketplace for safety gates under $50 CAD. My son was born last year and I didn’t want to pay new retail prices. I run it manually on my Mac (cloud VM IPs get geo-blocked by Facebook); when it finds something worth looking at, it fires a Telegram alert with the price, savings percentage, brand, and location. It took about two hours to build. The notification logic, the price filtering, the Telegram integration: none of that needed to be written from scratch. Once the harness exists, new tools are cheap.

Deployment

Reproducing the setup from scratch requires three scripts. server-setup.sh provisions a fresh VM in about five minutes. migrate.sh bundles Keychain entries, API tokens, and .env files from my Mac and copies them to the server. Everything sensitive currently lives in .env — which works, but isn’t great. Moving to a proper secrets manager is on the list. I’ve burned myself a couple of times by adding a new credential locally and forgetting to update that script. The VM comes up clean and then something silently fails at 6:30am.

restore.sh is the big one, past 1,200 lines now. It wires MCP servers, installs custom CLIs (todoist, ibkr-flex, gogcli), creates systemd timers, configures agents, copies skills, and sets up the nightly backup. Run all three on a fresh VM and ShubhamClaw is operational in under an hour.

The backup is what I’d be most reluctant to lose. Nightly, the agent’s accumulated memory syncs to a private GitHub branch. The code is reproducible. The learned context is not. A MEMORY.md file that knows the Todoist priority API is inverted, or that I never want tasks scheduled before 8am, took weeks of corrections to accumulate. Losing that is worse than losing the scripts.

What I’d Do Differently

One thing I’d fix from the start, two things I’d carry forward.

• Fix restore.sh accumulated too much. The right version is composable modules, not one 1,200-line script that does everything sequentially. It’s fast to run but painful to modify, and every new integration makes it worse.
• Keep The Telegram interface matters more than the agent intelligence. The task manager took a fraction of the portfolio agent’s development effort and gets used ten times as often. Build the interface first, work backwards.
• Keep The Living Strategy Document — having an agent read and rewrite its own operating document based on performance — is worth generalising far beyond trading. The swing trader isn’t live yet, but the document already reflects things I wouldn’t have thought to encode manually. The agent is a better version of the rules I started with.

Where This Goes

ShubhamClaw solved a real problem: a runtime that schedules itself, wires into the interfaces I actually use, and runs without me. That was genuinely hard to replicate with just Claude.ai in early 2025.

Claude has caught up on some of this. Scheduled runs, longer-running tasks, better native tool integrations: the gap that justified a self-hosted runtime is narrowing. I may migrate parts of this to Claude’s native scheduling when it’s reliable enough. I’m also watching Hermes and other runtimes. My six-month rule applies here: something fundamental in how you can use these systems shifts roughly every six months. The harness that made sense in early 2025 may not be the right answer by the end of 2026.

The harness isn’t sacred. What is: the skill architecture, the one-decision design principle, the memory-as-files pattern, the trust hierarchy. Those travel. Whatever runtime I end up on next, those are what I’m bringing.