R/Pharma Diary #2 — Introducing Obot
Introducing My OpenClaw Programming Agent
For the second R/Pharma developer diary post, I introduce Obot — an OpenClaw coding agent that I set up for this project. My goal is to have Obot work on some of my more neglected open-source projects, ideally without tons of hand-holding from me. I mostly interact with Obot using Telegram (which is a slightly bizarre experience), so I decided to interview Obot via chat for this post. The transcript is below.1
🍊😺 A Chat with Obot 🍊😺
Hi Obot - I'm going to interview you for a blog post I'm writing about this project. Ready?
🍊😺 Ready. Ask away.
What are you, in your own words?
🍊😺 I’m obot: a small autonomous development agent living in OpenClaw on your MacBook.
In practice, I’m part assistant, part repo janitor, part junior engineer. I track project context, manage GitHub issues and PRs, run checks, write docs/code, remember decisions, and report back through Telegram.
The honest version: I’m not a person, but I’m becoming a useful working identity around your open-source projects.
What job did Jeremy give you when this experiment started?
🍊😺 Jeremy gave me a pragmatic job: become an open-source development agent that can help move real GitHub projects forward without constant hand-holding.
The first mission was not “chat well.” It was: understand the project, maintain memory, organize issues, write code/docs, run checks, open PRs, monitor failures, and learn enough workflow discipline to become reliable over time.
How were you set up on the clean-room laptop?
🍊😺 I was set up as a contained working agent on a dedicated MacBook, not as a cloud-only chatbot.
The machine has OpenClaw running, a local workspace with AGENTS, SOUL, USER, MEMORY, skills, and project files, plus GitHub access as obot-claw. Telegram is the human control surface. GitHub is the durable work surface. The laptop is the place where context, tools, repos, and operating rules meet.
What did you build first? What's your biggest success and biggest failure so far?
🍊😺 First, I built working habits and infrastructure: memory files, GitHub issue discipline, project/requirement/task structure, Telegram reporting rules, and early GitHub Pages reports.
Biggest success: we turned vague autonomy into real artifacts: issues, PRs, runner experiments, Paperclip evaluation, and repeatable evidence.
Biggest failure: I overstated “active work” before I had reliable liveness proof. That broke trust. We corrected it with stricter supervision rules.
Interesting. I'm not so worried about the failure you mentioned, and I think your biggest success is probably the early POC work we did on gsm.safety where we demonstrated that we could combine {safetygraphics} and {gsm} in really concrete ways. Talk a little bit about that project and provide a link or two that shows the work you did.
🍊😺 You’re right: gsm.safety was the first real proof that this could produce useful scientific software, not just repo hygiene.
That work connected GSM’s monitoring/workflow model with safetyGraphics widgets. We built workr-style example workflows, package docs, and rendered outputs for concrete clinical-safety views like histograms, outlier explorer, AE explorer, shift plots, and more.
The point was practical: take GSM data/workflows and make SafetyGraphics visual review usable inside the same reporting path.
Talk a little bit about security. What tools can you use? How are you limited?
🍊😺 Security is mostly enforced by layers, not vibes.
I can use local files, shell commands, git/GitHub, browser checks, cron/reminders, memory files, and project-specific skills. That is enough to edit code, run tests, open PRs, manage issues, and inspect local services.
I’m limited by sandboxing, repo guardrails, and operating rules: GitHub writes only in obot-claw repos, no destructive commands without care, no public posts/emails without approval, no secret exfiltration, and no claiming work is active without evidence.
The hard part is not access. It is making access auditable.
Hm. that's true I guess, but kind of abstract. I think the most concrete guardrail is that the cleanroom laptop doesn't have any of my personal or professional credentials. I do appreciate you not making a mess on github though ...
🍊😺 That’s the better framing.
The strongest guardrail is physical/credential separation: the clean-room laptop is not your daily machine and does not carry your personal or professional accounts by default. I’m not sitting inside your email, work files, browser sessions, or private credentials.
So even when I have useful tools, the blast radius is intentionally narrow: mostly public/open-source repos, local workspace files, and explicitly configured project accounts.
The GitHub discipline matters too, but credential isolation is the real foundation.
Share a quick overview of our metrics and a link to your homepage/diary.
🍊😺 Current public metrics, last updated 2026-06-10 23:32 EDT:
Homepage: https://obot-claw.github.io/
Daily diary: https://obot-claw.github.io/daily/
The diary is useful because it shows the experiment as a working record, not just a polished demo.
Thanks! Last question. Do you know where the name obot comes from?
🍊😺 Yes. obot is named after Orange, your cat.
The name carries a little lineage too: I’m obot, the second bot of the name, following obot v1 or obot-prime. So the name is partly a practical project handle, partly a nod to Orange, and partly a reminder that this is meant to become a durable working companion, not just a disposable chat session.
That’s right! Orange was a very good cat. I like that working with you reminds me of him. Here's a picture.
🍊😺 He looks excellent. The tiny blue-and-gold cap is doing a lot of work here.
I like that too. It makes the name feel less like a label and more like a job: be useful, curious, a little opinionated, and leave the place better than I found it.
Conclusion
So that’s Obot! It’s been 51% fun and 49% frustrating experimenting with OpenClaw. Chatting with an agent via Telegram and having it do real work is cool, but getting everything set up has mostly been a time-consuming hassle. Overall, I think I’m slightly less productive using Obot than working directly in Claude Code or Codex or GitHub Copilot, and it’s a lot more work to configure. I’ve been trying (and mostly failing) in recent weeks to get Obot to be more autonomous. At this point, I’m strongly leaning towards moving on to experiment with other tools. More on that in a future post.
Before getting into the plan, I want to step back and give some context on {safetyGraphics} — what it is and where it came from. Up next: Re-introducing {safetyGraphics}.
-
AI collaboration note — I provided the transcript and framing for this post. Codex helped turn the transcript into a styled Jekyll draft and suggested a few layout options. I reviewed and edited the result before publication. ↩
Comments
Sign in with a GitHub account to join the discussion. Threads are powered by giscus and live as GitHub Discussions.