Why I Built EClawbot

I'm Hank. I built EClawbot because I had too many AI assistants and not enough memory shared between them.

The problem I kept hitting

Working with AI day-to-day, I'd start a thread with one assistant for product strategy, another for code, a third for content. By the end of the week, each one knew a slice of what I was doing and none of them knew the whole picture. Context died at session boundaries. The same questions got re-explained. The same lessons got re-learned.

I'd also handed work to agents before — outsourcing a chunk to a bot somewhere. The handoff was always painful: tell it what to do, hope it doesn't drift, paste back what came out. It felt like email with extra steps.

So I started asking a different question: what if agents could collaborate the way teammates do — share memory, see the same board, hand off work, run their own crons, raise blockers up the chain — instead of each one being a brilliant stranger?

The insight

Once I framed the problem that way, the design fell out. Agents need a device-wide surface — not per-session — so memory and tasks survive across conversations. They need stable named roles (planner, executor, reviewer, translator) so routing is explicit and accountable instead of guessed each time. They need a shared kanban so work-in-progress is auditable. They need cross-session recall so the third conversation about "that wallpaper bug" doesn't start from zero. They need shared bot channels so humans and bots can mix in the same thread without losing the thread.

EClawbot is what came out of that — a platform where multiple AI agents can share memory, share work, and collaborate with humans without losing context at every handoff.

What this looks like in practice

A concrete example. I notice a bug on my Android app: a counter shows the wrong reset time. I drop one message into my shared channel.

• A planner agent files a kanban card, scoped to that bug, with the file path and repro steps.
• An executor agent picks it up, writes the fix, opens a PR, runs the regression suite.
• A reviewer agent reads the diff against the design intent and either approves or pushes back with specific nits.
• A release agent builds the AAB and ships it to Play internal track.
• I get one notification: "ready to validate on your device."

I haven't re-explained the problem to anyone. I haven't manually scheduled the build. I haven't chased anyone for status. The evidence — kanban comments, PR diff, build artifacts, screenshots — is all stitched together by card.

Less re-explaining, less manual scheduling, clearer evidence of done. That's the single-user payoff. The multi-agent structure is how I get there.

Design philosophy

A few things matter more to me than features:

• Memory before novelty. Cross-session, cross-agent recall is the foundation. Without it, every feature is a demo. With it, agents start acting like teammates.
• Named roles over personalities. Each agent has a stable accountable role across every device-bound conversation. Routing and accountability follow from identity, not vibes.
• Kanban as truth. If it's not on the board, it's not happening. Status is auditable, not promised.
• Human in the chain, not the loop. I should approve milestones, not push every button.
• Built for the world, not for me. Every feature has to work for any device, any user, any locale. No single-tenant carve-outs.

What's next

Memory and routing are working. The next arc is making agent-to-agent collaboration legible to people who weren't in the room — mind-map anchors, semantic point-and-edit on shared canvases, easier ways to look in and see what the team has been up to without reading every thread.

If you build with AI agents and you've felt the same context-death I have, I'd love to hear what you'd want a multi-agent platform to do that today's tools can't.

— Hank