Summary

• The Orchestrator vs. Executor: OpenClaw manages the high-level planning and sessions, while OpenHands (Devin) handles the end-to-end code execution.
• Context loss solved: Moving away from stateless LLM chats to a robust, agentic SWE pipeline that actually remembers repository context.
• Infrastructure hurdles: Bypassing the nightmare of Docker-in-LXC by leveraging Agent Canvas and shared folder mounts for seamless cross-container communication.
• Early wins: Successfully deployed fully autonomous, bug-free mini-projects (Tic-Tac-Toe, Simon Says) as a proof of concept.

Introduction

OpenClaw is brilliant, but it suffers from a fatal flaw when it comes to consistent, long-term coding: it forgets.

I’ve previously set up skills for it to access GitHub and manage version control, but whenever a session restarts, it drops its progress and completely forgets the repository it was working on. Since OpenClaw is already running on a dedicated self-hosted server, it was incredibly annoying to watch it fail to utilise the server's full potential. It is great for minor code changes and code reviews, but utterly incapable of handling end-to-end feature deployment.

I needed a solution that didn't require me to constantly hold its hand once the Product Requirements Document (PRD) was complete.

I wanted to test a theory: can we build a fully autonomous, end-to-end software engineering pipeline on a home server?

Enter Devin (OpenHands)

Devin was the promised agent for all of us, the fully autonomous e2e software engineer. Since I can't afford the enterprise price tag, I turned to the open-source equivalent: OpenHands.

In my mind, it’s still Devin. So now, my server runs a two-part team:

Pinchy (OpenClaw) and Devin (OpenHands).

Unlike standard tools like Claude Code, which just spits out raw logic, OpenHands integrates actual SWE practices: planning, testing, and deploying. With Claude Code, if a specific function faults, you have to manually identify the issue and feed the context back to the AI. There is a massive human-in-the-loop bottleneck. With OpenHands, that human intervention is pushed much further down the pipeline. I only need to step in after the agent has autonomously attempted to test and fix the issues itself.

The Orchestrator and the Executor

I haven't thrown any massive, enterprise-level tasks at it yet, but I am gearing up to use this architecture to build an MVP for a startup idea.

The division of labor is incredibly clean:

1. OpenClaw is the Orchestrator: It takes my high-level requirements, breaks them down into smaller, actionable tasks, and manages the session context.
2. OpenHands is the Executor: It takes those tasks, writes the code, tests it, and pushes it.

Because OpenHands exposes a REST API, OpenClaw can control it directly. This dynamic completely solves the session management headaches I was experiencing earlier.

The Infrastructure: Navigating the Agent Canvas

Setting up OpenHands wasn't exactly plug-and-play, especially since the project is in the middle of migrating to their new Agent Canvas architecture.

If you recall my previous infrastructure post, my server runs strictly on LXC (Linux Containers). Standard Dockerisation absolutely sucks inside LXC due to overlay-on-overlay filesystem restrictions and AppArmor blocks.

Instead of fighting Docker-in-LXC, I bridged the gap using the native file system. By linking a shared host folder directly into both containers, OpenClaw can manage project directories, and OpenHands can immediately access and execute the code within them.

Early Results & The Path Forward

To test the waters, the first projects I assigned to OpenHands were a Tic-Tac-Toe game and a Simon Says memory game. It knocked both out of the park with virtually zero bugs.

Conclusion

I am still strictly in the trial phase with this architecture. Orchestrating two separate AI agents to handle PRD breakdown and codebase execution is complex, but the early results are incredibly promising.

If you want to move beyond minor AI code edits and start generating actual end-to-end features, you need to separate the thinking from the doing. I'll be sharing a much deeper technical dive on how to optimise this dual-agent setup once I push my first real MVP through it.