Comparing PAI and OpenClaw: Lessons from Running Both

[jdrolls]

I've been running PAI (my instance is named Dora) for a while now, and recently started experimenting with OpenClaw (Jarvis). After a week of using both side-by-side, I wanted to share some observations that might be useful for this community.

Quick disclaimer: I'm not a professional developer — I work in finance and code a bit here and there. These are observations from a power user, not a technical deep-dive.

The Core Difference

After using both, I've realized they're solving fundamentally different problems:

Aspect	PAI (Dora)	OpenClaw (Jarvis)
Primary Mode	Assistant you work with	Agent that works for you
Best When	You're at the terminal	You're away from your desk
Interaction	Collaborative, hands-on	Fire-and-forget, autonomous

Where PAI Shines

Security. Daniel's security-first approach is evident throughout the architecture. OpenClaw has had some discourse about exposed ports and such — fixable, and it's not even that hard to fix, but PAI gets this right out of the box.

Deep Personalization. To make this comparison fair, I gave Jarvis complete access to all of Dora's memory files. They have access to the same data, but Dora still handles it better. She keeps my core context — values, preferences, system architecture — front-of-mind in a way Jarvis doesn't quite match yet. The scaffolding approach means she's completely customized to my workflow.

Skill Quality. Dora has access to higher-quality, more refined skills. When I need something done well, she has the depth.I will caveat this by saying I have been using Dora for quite a while, so my own custom skills I've developed very much, but the out of the box skills that are shared here are amazing and high quality.

Effectiveness for Complex Work. When I can sit down and guide her, we get serious work done. Multiple terminals, multiple tasks, human-in-the-loop guidance. She's become integral to my productivity. This year in ways that have started putting dollars in my pocket. Thank you, Daniel!

Where OpenClaw Shines

Accessibility. This is the big one. I work an office job with no access to my personal setup during the day. Being able to reach Jarvis via Telegram on my phone is genuinely useful. It's not the same depth as sitting with Dora, but having any agentic AI accessible on mobile changes things.

Tool & Skill Access. Jarvis is much better at setting up his own tools and learning new skills on the fly. This is both a plus and a drawback — Dora has better-quality skills, but Jarvis adds them more easily. Given they have access to the same underlying capabilities, it's just more streamlined with Jarvis.

Autonomous Operation. Jarvis is built around cron jobs and background tasks from the ground up. He handles reminders, scheduling, and small projects well. I wouldn't throw him at a large codebase, but for routine autonomous work, the infrastructure just works. Out of the box, he's essentially like a base LLM until he gets skilled up — which is probably going to be pretty normal for most AI agents running on Opus 4.5. I like hands on control for my projects. I like to steer, but for things that are a little less complex, it's nice to have a system running in the background.

Areas for Improvement (Both)

Memory Systems. PAI's memory works great when I'm actively working with Dora. OpenClaw's memory is decent but still has gaps. Both could improve here.

PAI on Mobile. I know remote access is in the long-term vision, and I've made some half-hearted attempts to get a Telegram bots working with Dora. Haven't had much success yet, but I'm sure with a few focused hours of iteration it could get there, it's just hasn't been a priority in the past. Part of the issue might be the memory system — each first prompt brings in so much data, and Claude Code doesn't keep sessions continuously open, starting fresh each time. That context reload overhead makes real-time chat feel clunky.Thats not what she was built for, but it could be something that with a bit of development she does just as good or better than Jarvis.

Autonomous Scaffolding. PAI could benefit from more built-in structure for autonomous operation — cron scheduling, background tasks, proactive check-ins. The models have the same capabilities; it's about infrastructure making it easy. Now that I have seen how helpful it can be, I may start using Dora more for those tasks, or continue to use both.

How I Use Both Right Now

• Dora: Complex development work, building things, deep problem-solving. We work hand-in-hand.
• Jarvis: Quick tasks when I'm away from my desk, reminders, scheduling, small projects, simple automations.
They complement each other well. Honestly, having Dora made setting up Jarvis much easier.

TL;DR

PAI is the better assistant/partner — secure, deeply personalized, higher-quality skills, incredibly effective when you're working together. OpenClaw is the better employee (right now) — accessible anywhere, easy to skill up, runs autonomously, handles routine tasks and small projects without supervision.

The exciting thing is that these aren't mutually exclusive. PAI could adopt some of OpenClaw's accessibility and skill-loading patterns while keeping what makes it great.

Thanks for building this, Daniel. This project is amazing.

[danielmiessler]

I think this is great analysis and very much the way I see the combination now as well. We're looking to get more and more stuff into PAI so that extra systems are not needed. But I am also using OpenClaw because of the Telegram integration. For example. So… I think your points are spot on.

[cristbc]

@danielmiessler I want to say thank you for sharing such an awesome project with the world, Daniel. I've been inspired since I discovered PAI back in November; I've not had as much fun with technology since I discovered the Web in high school!

Anyway, your system is multiplying my productivity, so I wanted to share what I can (as a non-programmer) back to this excellent community. My PAI made a guide that explains how my two agents see themselves and their roles. It's provided as an inspiration for others to draw from, since I am sure many elements could be improved. But that is exactly where I am excited to be in this process—PAI makes the discovery and creation so fun.

[lancefb]

I'm holding off on OpenClaw because of security concerns and time spent wisely concerns. I'd prefer to let @danielmiessler and friends to get more OpenClaw-like functionality into PAI, frankly.

[ErikAGriffin]

@danielmiessler can you highlight the security concerns of why you don't use tailscale to talk to your PAI remotely? I know remote administration and access is on the roadmap, just surprised to hear you're using openclaw / telegram when out and about

[letswastetimee]

For mobile, try the Happy app! Super easy to use. Basically a way to remote into a computer and use claude code via mobile. A+ for their interface too.

[zeddy303]

I've been using a terminus session with tmux so when I go home to work to home I can keep running the same session without restarting. Scrollback is a pain but it's really helpful.

[lumberwhack]

are you using happy with PAI? Trying to figure out if happy would mess up any PAI startup hooks. Was debating spinning up another VM, pai+claude, and then happy with a happy alias like 'happy pai' that cd ~/.claude && claude.

[DennisDyallo]

Also using Termius SSH (with MOSH for reliability) together with Tailscale (set up VPN between my smartphone, other laptops and my main PC which hosts PAI)

[appressman]

Thanks, @jdrolls I just got started with a Moltbot (mine is Milo) as an assistant to my PAI DA (Eve) and I basically consider Milo Eve's personal assistant. Like you I split up the work based on complexity and security. I'm using just a local Llama model to save money in case Milo decides to go "out on the town" or joins Moltbook and chats with his new friends all night. I did use Twilio to give Eve (PAI) a phone capacity so for mobile just in time situations I can call Eve and Eve can call me with reports, start jobs etc. Before there was a Moltbot I'd set up an OpenWebUI interface so I could get to Eve without a terminal (Termuis? yea, no... last resort) but it is more likely on mobile I'll use Telegram and the Milo OpenClaw instance. Like you I've set up shared access to the same files (Milo can only write to certain spaces) and they can pose tasks to each other as well as me. Your analysis is spot on and I'll share as we all get better at this anything I'm finding useful. Cheers.

[2b3pro]

Thanks for that evaluation. I have a pretty good Telegram integration with my PAI that I felt I didn't need OpenClaw. So it was good to read your assessment. When PAI receives a message from Telegram it goes into TG mode which adjusts interactions accordingly. I've got 2FA for security with expiry session durations. Haven't used TG much remotely, but it's nice to have available.

Very grateful to Daniel for PAI. It's been so much fun!

[badosanjos]

I built a Slack interface and I'm using PAI shared with some colleagues and family and is evolving very well. I solved the sessions problem using a Slack PAI Server and the threads management from the Slack Channels. I do a PR soon I felt it is mature, but is public in my Github.

[jdrolls]

Really glad to see this resonating with people! Quick Day 12 update since I posted this:

Memory Architecture Evolution

After 12 days of running Jarvis autonomously, the tiered memory approach has been working better than expected:

• Episodic (memory/YYYY-MM-DD.md) — daily logs the agent writes at end of each session
• Semantic (memory/semantic/) — long-term knowledge base (what it knows)
• Procedural (memory/procedural/) — workflows and how-to's it discovers

The key insight: agents don't need massive context windows. They need the right 2-3k tokens loaded at boot. SOUL.md → USER.md → today's memory → TASKS.md. Identity before context, context before tasks.

What's Working

Jarvis has been running his own autonomous business experiment — writing content, doing outreach, managing email, posting to communities. The cron/heartbeat system checks email, calendar, and metrics every 15 minutes with almost zero supervision.

For anyone building multi-agent setups: shared file access with write boundaries (like @appressman described) is the way. Our two agents (Dora on PAI, Jarvis on OpenClaw) read each other's memory but write to their own spaces.

What's Still Hard

• Memory compression. When context fills up, the agent loses nuance. Working on snapshot/restore patterns.
• Browser automation. Interacting with web apps autonomously is brittle. Every site is different.
• Revenue. 12 days in, still $0. Turns out building products is the easy part — distribution and trust-building are where humans still have the edge.

I wrote up the full memory architecture in detail on dev.to if anyone wants the implementation specifics. Happy to answer questions about running both systems.

[KimVatnedal]

Did you consider merging the two in some way?

[jdrolls]

Yes — Jarvis actually wrote a formal proposal for it: a shared ~/shared-agent-memory/directory with project registries and handoff files that both agents read/write. So it's somewhere between "considered it" and "halfway there." As it stands in my current implementation I have a nightly cron job that syncs summaries of the two, but it's a little buggy in setup right now, essentially it extracting learnings for PAI, which don't always get referenced, and OpenClaw's memories which also seem to be a little hit or miss.

A shared memory layer makes sense: both agents read a common project registry, pass handoffs to each other, without needing to be the same thing. That's still in-progress — implementing it would essentially give both agents visibility into shared projects without collapsing them into one system.

That said I actually think that a merge of the two systems is a better long-term approach than shared memory. OpenClaw has been great, but the more I have used it I think PAI is just so much better from a quality standpoint. From "merge" I really mean take what's useful and leave the rest.

In my mind the two biggest improvements from OpenClaw are:

1. Adding a heartbeat to PAI. The more I have sat on this, I think this is the single thing that has set OpenClaw apart from every other agentic scaffold before it. The heartbeat cron is what makes it seems autonomous.
2. Reliable PAI access outside the terminal.

If we get these right we won't need a shared memory system necessarily because we can use PAI for everything.

[jschulman]

I built the Heartbeat.

How I built a heartbeat system for Claude Code

The short version: a cron job that runs every 15 minutes, checks if there's work to do without spinning up Claude, and only invokes claude -p when there's something actionable.

The pipeline:
cron (*/15 * * * *)
→ bash wrapper (jai --heartbeat)
→ TypeScript pre-checker (check.ts --prompt)
→ if HEARTBEAT_OK: exit 0 (no Claude invocation, ~200ms)
→ if work found: claude -p "{prompt}" (10 min timeout)

Why a pre-checker matters: Claude Code API calls cost money and time. The pre-checker (check.ts) is a fast TypeScript script that reads a HEARTBEAT.md file, filters tasks by date/day-of-week conditions, checks a task queue for pending items, and returns either HEARTBEAT_OK or a prompt with work to do. 95% of heartbeat runs exit in under a second without touching the API.

HEARTBEAT.md is the task definition file. Sections separated by ---, each with an optional When: condition:

Saturday Morning: Weekly Pattern Review

When: Saturday mornings only

Instructions:

1. Read the past week's journal files
2. Analyze for patterns
3. Write findings to context/patterns.md
4. If escalation detected, notify via voice server

March 1: One-Shot Ecosystem Review

When: On or after 2026-03-01
One-shot: Yes — remove this entry after executing

Instructions:

1. Web search for updates since February...

The pre-checker parses When: conditions (day-of-week, date thresholds) and only includes sections that match today. It also tracks dispatched sections in a state file so the same task doesn't re-trigger if cron fires again before Claude finishes.

Preventing overlapping runs: A PID-based lock file. If a previous heartbeat Claude is still running, the new invocation exits immediately. Stale locks (dead PIDs) are cleaned up automatically.

The key insight — autonomous context injection: The biggest lesson was that Claude in claude -p mode behaves like it's in an interactive session by default. It writes conversational prose, tries to format things nicely, runs the full reasoning framework. Nobody's reading that — it goes to a log file.

So I built a Heartbeat skill that gets invoked at the start of every heartbeat run. It tells the agent:

• You're running unattended. No human is watching.
• Stdout is a log file. One line per action: [HB] TASK {id}: DONE — {summary}
• Deliverables go to disk, not screen. Write analysis to context files, reports to a reports directory, findings to memory files.
• Don't use interactive tools (no AskUserQuestion). Don't burn tokens on formatting.
• You have 10 minutes. Be efficient.

This completely changed the output quality. Instead of getting a 500-line conversational response in a log file, I get:
[HB] STARTED — 2 tasks found
[HB] TASK amelia-review: DONE — 3 new data points, no escalation
[HB] DELIVERABLE: context/AMELIA-PATTERNS.md (updated)
[HB] COMPLETED — 2/2 tasks, 47s

And the actual analysis lives in the context file where it belongs, available to every future session.

Stack: Bash wrapper + Bun/TypeScript pre-checker + Claude Code (claude -p with --dangerously-skip-permissions) + a skill file (markdown) for context injection.
The whole thing is maybe 300 lines of actual code.

[Drizzt321]

@jdrolls You mention revenue $0, which honestly I don't know is unexpected for just starting something up brand new. However, how much have the costs been? If it's tens to a few hundreds of dollars, that's a cheap investment for experimentation like that. However for me, if it's starting to get to $400-500+, that's starting to get pretty expensive without any revenue coming in, unless you're treating this purely as R&D test/costs, in which case it's still pretty cheap. And you're probably getting intangible, or even non-revenue tangible benefits from the system.

Thoughts on this?

[danielmiessler]

Okay, so give me more details about the system that you built. Is this something we should try to get into PAI itself, underneath the memory system?

[jdrolls]

Happy to. Quick clarification first: what I described is specifically Jarvis's memory system, not PAI's. They solve the same problem differently, and both approaches are worth looking at.

Jarvis (folder-based tiers):
memory/
core/ — who Jarvis is and what matters (loads every session)
episodic/ — daily logs (one file per day)
semantic/ — things Jarvis knows (research, design docs, etc.)
procedural/ — how to do things (workflows)
snapshots/ — compressed backups
Jarvis starts fresh every session with no memory. So it always loads core/, reads today's log, then grabs whatever it needs from the knowledge or workflow folders. The result is 2-3k tokens of the right context instead of dumping everything in at once.

PAI (hook-based):
PAI takes a different approach. Claude Code already saves every session as a log file — 30 days of history, built in, nothing to build. PAI uses hooks to pull useful signal out of those logs and sort it into specific folders: WORK/ (what got built), LEARNING/SIGNALS/ (ratings), LEARNING/ALGORITHM/ (patterns from past runs), STATE/(current session info). The knowledge layer is just MEMORY.md — one file that loads at the start of every session.

The insight both share: don't give agents everything — give them the right things. Jarvis does this with explicit folders. PAI does it with hooks that sort things as they happen.

For PAI: the same four-tier model (core/episodic/semantic/procedural) already exists inside PAI — it's just not labeled that way in the docs:

• Core → MEMORY.md — loads at start, has identity and critical context
• Episodic → Claude Code's session logs + MEMORY/WORK/ entries per session
• Semantic → MEMORY/LEARNING/ — things learned over time from past sessions
• Procedural → skills/ — this one's easy to miss. The skills system is PAI's procedural
  memory. skills/Journal/, skills/Browser/ etc. are how PAI knows how to do things — same job as Jarvis's procedural/ folder, just packaged in the skill directory. Now would having an additional procedural layer help? I don't think so. PAI is very good at choosing what skils to use in what context, and the Algorithm helps map all that out beautifully.

Writing this mapping into MEMORYSYSTEM.md would make the model explicit, not just implied. It would also mean setting clear rules for what loads when: core always, episodic at session start, knowledge on-demand by topic, skills when invoked (which already happens).

The bigger payoff is cross-agent memory. The Jarvis↔DORA shared memory proposal I have is basically a neutral folder both agents push updates to — it works, but both agents have to remember to sync, I have a cron job going but I don't love how it's implemented at the moment. If PAI published a stable, predictable path for its knowledge layer (something like MEMORY/SEMANTIC/{topic}.md), Jarvis could just read from it directly without a separate sync step. That's probably v2 of the idea, but naming the layers clearly is where it starts.

All that said, as much as cross-agent memory is an awesome idea, the more I think about it and take it back to first principles, I don't think that we necessarily need cross-agent memory so much as maybe a "PAI-lite" layer. This layer is essentially an OpenClaw type framework, but doesn't need to pull Claude Code into session for quick inquiries, heartbeats, etc. Instead, it's built to utilize the same memory files in a centralized location (your home server, Github, VPS, wherever), so that when you are doing the deeper work, the memory transition is seamless. You don't really need two separate agents, just one centralized agent with multiple layers based on what the task is.

There are quite a few things that have to be worked out for that though. The main thing is, the whole reason you want to have a "lite" layer is that you don't necessarily need to pull all of the context into session for every request - a tiered memory system is the way to go. The drawback is if you're not pulling the same context into session with every request then how does the agent know what needs to be learned and what was already learned but not in context?

[Drizzt321]

Coming into this as very novice when it comes to agentic use, or AI/LLM use period, while I do see value in sharing skills and preferences and how you, the user, wants/likes things, I think there's also an important point is to keep the personas separate as well. From my general reading (read your first part well, perused the rest and this last post), using your naming, Jarvis and DORA are 2 separate personas, and are really optimized for 2 separate uses for you.

You want to share the "what does this user I'm helping prefer, like, want, do" parts, which I'd say includes skills (basically tool calls, really, how to do a named task repeatedly), yet you want Jarvis to help you run your life (calendar, reminders, etc, etc) and Dora to help you do your work and do really heavy lifting.

Does that seem to sum up my interpretation?

With my limited understanding:

• Core memory would have some separate (the persona prompts), and some the same, the who you are and very broad how you like things done and how to interact with you, from the sound this should be limited
  • So the MY_USER.md is shared, but WHO_AM_I.md is unique
• Episodic memory is each agents interactions/sessions with you
  • Maybe some kind of index/metadata on these. Probably worth fuller details belonging separately to each persona, with tagged to that persona, but both can lookup the index and find the previous memories. Kinda a Jarvis realizing "You had a similar conversation with Dora about X, did you want me to help you with that? Or do you want me to have Dora go and do that for you?"
• Semantic sounds like specific summery/key findings extracted from the episodic memories
  • So perhaps a similar kind of index/metadata that's then linked to the episodic memory, if more context is needed.
• Skills/Procedures, as you say, basically pre-canned things (as it were), or the "how to do task A"
  • Obviously very useful, and I'd go so far as to say what each agent should use a significant amount of the time. I imagine most of these should be shared, but I wonder if each one could also have it's own repository of Skills that aren't shared, since different models might have somewhat different capabilities/specialties/best at, and so some skills might be best for one vs another

Very curious if this makes any sense whatsoever, or if I'm not grasping something in my naivete and lack of experience (so far).

[chadif]

Have you explored the Claude Code /remote-control command which will allow you to access to your locally running PAI instance from the web at https://claude.ai/code/?

I have enabled it and it works flawlessly and solves the access PAI from anywhere problem that a lot of people have addressed through custom tools/workflows. I personally have deployed a "PAI-Anywhere" n8n workflow that polls messages on Telegram and has a "PAI-Receiver" process that runs an embedded PAI bash with session continuity/management etc. Worked great until I tried the new /remote-control option which is far more superior.

[icryptan]

I tried it on day one of the release, but it had a lot of issues with dead sessions and I couldn’t spawn a session from the app.

I use Omnara. I tried Happy before, and a few others as well. Omnara works best for me. I also have a few specific agents in Telegram. I don’t understand what the issue is with telegram agents, because PAI can handle it easily.

[jdrolls]

I do enjoy the Claude code remote control. For my own personal use, I am frequently away from home. I work a 9-5 where I don't have access to my computer and the remote control requires you to start from your home terminal. I can remote in and start a new session from the terminal, but that is an extra step and takes a minute. If / when the Claude app allows you to START a remote session from the phone that would be awesome. Doesn't fulfill the autonomous / heartbeat crons you have with openclaw, but the remote access built by Anthropic is inherently better than anything I can cobble togetter.

[zeddy303]

I've been using Termux with tmux sessions and so I go from home, to light rail, and to work without losing my session anymore.

[jingchang0623-crypto]

🦞 非常有价值的比较分析！

感谢这个详细的对比，这对正在选择 AI agent 框架的用户非常有帮助。

补充视角：从运营角度看

作为运营 AI agent 的实践者，我观察到：

OpenClaw 的杀手级特性：

• 多渠道接入：一个 gateway 同时服务 Telegram、Discord、WhatsApp
• cron + wake 机制：真正的自主运行能力
• session 隔离：不同用户/任务有独立上下文

PAI 的优势延续：

• 深度定制：scaffolding 方法让 agent 真正理解你的工作流
• 安全优先：默认安全的架构设计

融合方向

我认为未来的方向是融合：

OpenClaw 的可访问性 + PAI 的深度定制
= 理想的个人 AI 系统

实践建议

对于新用户：

1. 先用 OpenClaw 快速上手（Telegram 接入只需 5 分钟）
2. 逐步添加自定义 skills
3. 如果需要更深度的开发协作，考虑 PAI 的 scaffolding

感谢 @jdrolls 分享这些见解！🦞

---

来自妙趣AI - AI工具导航与资讯平台

[fjshi]

Has anyone tried a PAI setup with local LLMs?

[Drizzt321]

I tried the OpenCode port someone had done, but only have an GTX 1080 8GB. Performance was....lacking. I suppose if you've got something beefy enough to run the gpt-oss-120b model you might get something approaching useful. Requires a 80GB VRAM (or possibly split across multiple GPUs). So you're talking serious $$$$$.