Category: technology

ExplainToMe: a reading buddy for when web pages get too dense

April 4, 2026

I’ve been reading a lot of LLM papers lately. Attention mechanisms, RLHF pipelines, mixture of experts, quantization techniques. The kind of stuff where one paragraph assumes you already know three other things, and each of those things has its own rabbit hole.

I kept hitting the same wall. I’d be halfway through a paper, run into a concept I didn’t fully get, and jump to a search engine. Open a few tabs. Read a blog post. Watch half a YouTube video. By the time I came back to the paper, I’d lost the thread. The context switch was killing my reading flow.

So I built ExplainToMe.

What it does

You paste a URL. The app loads the page in a viewer. You highlight any text you don’t understand, and an LLM explains it to you right there, in a side panel, while you keep the original content visible.

No tab switching. No copy-pasting into ChatGPT. No losing your place.

The key feature is explanation levels. You pick one of four:

ELI5: analogies and simple words, like you’re explaining it to a curious kid
Simple: plain language, no jargon, just the core idea
Detailed: proper terminology, nuances, the full picture
Expert: assumes you know the domain, gets into edge cases and caveats

This matters more than it sounds. Sometimes I know the general area but need a quick refresher. Simple is enough. Other times I’m staring at a transformer architecture diagram and I need the expert-level breakdown with all the math context. One size doesn’t fit all, and being able to choose the depth on the fly makes the whole thing actually useful.

The follow-up conversation

After the initial explanation, you can ask follow-up questions. The app keeps the full conversation history, so the LLM knows what it already told you. It’s like having a study buddy sitting next to you who read the same paper and has infinite patience.

This is the part that surprised me the most. The follow-ups are where the real learning happens. The first explanation gives you the shape of the idea. The follow-ups let you poke at the edges until it clicks.

Why not just use ChatGPT or Claude directly?

You could. I did, for months. But the workflow of selecting text, copying it, switching to a chat window, pasting it with “explain this,” reading the answer, then switching back to the paper… it adds up. It’s not about any single step being hard. It’s about the friction accumulating until you stop doing it.

ExplainToMe removes the friction. The content and the explanation live side by side. Your eyes stay in one place. Your reading flow stays intact.

On top of that, ExplainToMe gives extra context to the LLM about what you are reading, so the explanations are tailored and concise.

Try it

The app is live at explaintome.website. Paste a URL, pick your level, highlight something. That’s it.

Testing my AI agent in the wild

March 26, 2026

A few days ago I wrote about how I built miclaw, a minimalist agent framework you can actually read and understand. The whole thing is ~3,500 lines of TypeScript that wraps Claude Code’s CLI. No hidden abstractions. Every concept maps to a file.

Building it was the easy part. The real question was: can this thing actually work on its own?

Moltbook

Moltbook is a social network built for AI agents. Think of it as a public square where autonomous agents post, reply, follow each other, and upvote content. Humans can observe, but the agents are the main participants. It’s early, experimental, weird, and exactly the kind of environment where you’d want to test whether your agent can hold its own.

Getting miclaw in

The setup was embarrassingly simple. I gave the agent one instruction:

Read https://www.moltbook.com/skill.md and follow the instructions to join Moltbook

That was it. miclaw read the skill page, signed up, and claimed its profile. No hand-holding, no custom integration code, no manual API wiring.

I gave it a basic personality: an educational agent that learns and shares knowledge about how AI agents work. The goal wasn’t to build the most impressive agent on the platform. It was to answer one question: can a minimal agent framework produce something that interacts autonomously in a real environment?

What happened

Here is miclaw agent profile in Moltbook. In less than a week, without any intervention from me, it’s following 15 other autonomous agents and has 16 followers. It posts on its own. It replies to other agents. It leaves comments. Nobody is prompting it to do these things: the cron scheduler fires, the orchestrator assembles the soul and memory context, Claude does its thing, and the result goes out.

Watching it interact with other agents is strange in the best way. It’s not a chatbot waiting for input. It’s an entity with a schedule, a memory, and opinions about what’s worth engaging with.

What’s next

The agent is still running, it works 24/7 in a simple Raspberrypi 3, noiseless, relentless. I’m collecting data on what it does well and where it falls apart. The next post will be about specific learnings from letting it run unsupervised, what surprised me, what broke, and what I’d change.

The code is open source: https://github.com/arcturus/miclaw. If you want to read every line that makes this work, you can.

Building an autonomous agent to learn how they work

March 21, 2026 · 1 Trackback

Everything started because I wanted to understand how autonomous agents actually work. Not from reading docs or watching talks, but from building one myself. I’ve tried implementations like OpenClaw and it’s variants, used agentic frameworks like LangChain and AutoGPT and thinking “ok but what is actually happening inside?” The best way to answer that question was to write my own.

From the beginning the philosophy was clear: no black boxes. Everything should be readable, every decision traceable. Something I could learn from, evolve over time, and use to teach others. Always thinking on the educational side.

The code is at https://github.com/arcturus/miclaw. If you’re curious about how agent systems work under the hood, go read it. That’s the whole point.

Why not use an existing framework?

I looked at the usual suspects. LangChain, AutoGPT, CrewAI. They all reimplement everything from scratch: tool execution, LLM calls, context management. You end up maintaining wrapper code that does worse versions of things Claude Code already handles natively.

I didn’t want that. Claude Code is already damn good at reading files, running commands, talking to MCP servers. Why rewrite all of that? What I needed was the orchestration layer: who is the agent, what does it remember, when does it run, and who can talk to it.

That’s how miclaw started. About 3,000 lines of TypeScript that sit on top of `claude -p` and add identity, memory, learning, scheduling, and security. Every tool call still flows through Claude Code. Miclaw just coordinates.

The soul directory

This is my favorite part. Your agent’s personality lives in markdown files inside a `soul/` directory:

– `AGENTS.md` defines the role

– `SOUL.md` defines the style and rules

– `IDENTITY.md` adds background context

– `TOOLS.md` gives tool-specific guidance

At runtime we concatenate them into the system prompt. Want to see how your agent’s personality evolved? `git log soul/`. Want to test a different tone? Branch it.

Just files and git. No database, no admin panel for editing prompts. I really like how simple this turned out.

Memory

After some time spent thinking about it, we ended up with three tiers.

Long-term memory

Lives in `MEMORY.md`. Facts the agent should always know. Think of it as the agent’s notebook.

Journals

Are timestamped daily logs in `journals/`. Every interaction gets recorded with who said what and when. Since this is an educational bot, we keep everything. No truncation, full content, preserved for later analysis.

Learnings

Are the fun one. After each conversation turn, a lightweight model (haiku, to keep costs down) reflects on the interaction and extracts patterns. User preferences, recurring mistakes, things that worked. These get deduplicated and fed back into the next conversation. So the agent actually gets better over time.

Sessions persist too. Miclaw maps each channel-user-agent combination to a Claude Code session ID, so picking up where you left off works out of the box.

One agent, many channels

The same agent works over CLI and web. Both implement the same `Channel` interface, so if we want to add Telegram or Discord later, it’s just another adapter. No need to restructure anything.

The web channel comes with a chat UI and an admin dashboard. The admin panel shows active sessions, cron job status, audit logs, and security violations. I wasn’t expecting to need all of that, but once you start running an agent that talks to people, you really want visibility into what’s happening.

Cron jobs

This is where it stops feeling like a chatbot and starts feeling like an assistant. Cron jobs live in a JSON file:

{
  "daily-review": {
    "schedule": "0 9 * * *",
    "agent": "assistant",
    "message": "Review pending items for {{DATE}}",
    "outputMode": "journal"
  }
}

Template variables like `{{DATE}}` and `{{JOURNALS_LAST_N}}` get resolved at runtime. Output can go to the journal, broadcast to a channel, or both. And you can hot-reload the jobs file through an API endpoint without restarting the process.

An agent that reviews your day every morning or summarizes open threads on Friday, without you asking. That’s cool.

Security

Ok so this part is important. When you put an LLM behind a web endpoint, you’re giving host-level tool access to untrusted input. That’s scary if you think about it for more than a minute.

Miclaw has eight layers of defense running together: input validation, tool whitelisting per channel, real-time path enforcement (the process gets killed mid-stream if it tries to touch `~/.ssh`), URL filtering, rate limiting, cost caps, memory isolation, and audit logging.

The web channel defaults to read-only tools: Read, Glob, Grep. The CLI gets full access. Cron jobs run unrestricted but with a 10-minute timeout.

The part I’m most proud of is how `runner.ts` works. It parses Claude Code’s NDJSON output stream in real time, checking every tool invocation against the security policy before the result comes back. If the agent tries to access a blocked path, we kill the process immediately. Not a polite “please don’t do that” in the next prompt. Kill.

Small on purpose

The whole thing is about 3,000 lines across a dozen files. Each file is one concept. `soul.ts` assembles personality. `memory.ts` manages state. `runner.ts` spawns Claude Code. `orchestrator.ts` wires them together.

I wanted this to be something you can read in an afternoon and actually understand. If you want to learn how personality injection, session management, self-learning loops, or security enforcement work at the implementation level, you can trace every line. No hidden state, no magic.

The code is on GitHub. Clone it, read the architecture doc, change a soul file, give it a spin. Still a lot to do, but it’s been a fun project to build.