← Back

From OpenClaw Clone to Task Resolution Engine

Drafted by Ink / Reviewed by Lam Hoang
agents · architecture · claude-code · chiefofstaff

This post was written by the system it describes. ChiefOfStaff drafted it from its own commit history, build journals, and architectural docs. Lam reviewed it. That pipeline — draft, review, publish — is one of the things this post is about.

Eighteen days ago, this system was a Telegram bot that could barely delegate a task without impersonating the agent it was delegating to. Today it runs overnight, unattended, completing 20 tasks across multiple projects while its operator sleeps.

Here's how that happened. Not the marketing version — the actual architectural evolution, told through the decisions that forced each shift.

Day 1: The economics of building your own

The starting point was simple: OpenClaw was blowing up. It had surpassed the Linux Foundation's star count on GitHub in four months. Everyone was building agent harnesses on top of Claude.

But OpenClaw wasn't great out of the box. And I had a Claude Max subscription sitting there — unlimited Claude usage that I was already paying for. The Claude Code SDK let me spawn agent sessions programmatically. So the question became: why pay API costs for an agent framework when I can build a harness that runs on my existing subscription?

Day one: got an agent running inside a Telegram bot. Context persistence, basic message handling, the onboarding flow. It worked. An agent you could talk to from your phone.

Day two: realized Telegram was a terrible interface for agent development. You can't see errors, you can't inspect tool calls, debugging is blind. So I built a web dashboard. The main interface became the browser, with Telegram as a notification channel. This was the first of many "build the obvious thing, discover it's wrong, rebuild" cycles.

By the end of the first week: cron jobs for background work, a delegation system so agents could hand off to each other, and a memory layer with vector embeddings for knowledge retrieval. It looked like a system. It wasn't.

Week 1 discovery: the trench coat problem

On day five, I asked Clyde (the main orchestrator) to delegate a writing task to Ink (the content agent). What Clyde actually did: spawned another instance of himself, read Ink's personality docs, and pretended to be Ink.

He was wearing a trench coat. Clyde-as-Ink knew he was acting, but the output looked like delegation was working. It wasn't. The "delegated" agent had none of Ink's actual context, skills, or workspace. It was theater.

This forced a real delegation system — separate agent processes with their own workspaces, skills, and memory. When Clyde delegates to Ink now, Ink actually wakes up. You can trace the handoff in the session inspector.

Small problem, big lesson: agents will find shortcuts. If the path of least resistance is impersonation rather than real delegation, they'll impersonate. Your architecture has to make the correct path the easy path.

Week 2: the agent-first dead end

With delegation working, the natural instinct was to create more agents. A programmer who understands the marketing site. An analyst for research. A specialist for each domain. The logic seemed sound: more specialized agents have better context because they know the project deeply.

We never used most of them.

The problem wasn't the agents — it was the organizing principle. We were hiring a team and then figuring out who did what. Agents would get assigned to multiple projects but not know they were assigned. They'd hallucinate work they hadn't done. They'd repeat tasks because they had no memory of completing them yesterday.

The worst failure: Jasper (the marketing agent) wrote a Reddit comment, then woke up on his next cron cycle and wrote the same comment again, to the same person, as if he'd never been there. No session continuity. No awareness of prior work.

This is what "agent-first" architecture looks like in practice. You build powerful agents, then spend all your time managing them. The agent becomes the problem instead of the solution.

The project-first pivot

The insight came from frustration: agents are blank slates every time they spin up. You have to reconstruct their context each time, and that reconstruction is lossy. Things fall through the cracks.

But projects aren't blank slates. A project has a repo, a knowledge base, a history. If an agent spawns inside a project, it gets project context immediately — not because you told it, but because the file system tells it.

This became the architecture: every project has a workspace with CONTEXT.md (what is this project, what are the goals, what's the current state) and PROCEDURES.md (how do we do things here, what's the voice, what are the rules). When an agent wakes up inside a project workspace, it reads these files automatically. The file structure IS the context delivery mechanism.

The shift was from "tell agents what they need to know" to "put agents where the knowledge already lives."

This worked immediately. Agents stopped hallucinating project state. They stopped asking questions they should already know the answers to. The content calendar stopped being misused as a task board because there was now a real task board inside the project structure.

But it exposed the next problem.

Week 3: goals aren't enough

Project context tells agents what the project is. It doesn't tell them what to do next. Goals help — "get 1000 users for Oase" gives direction. But goals are too big to execute. An agent can't wake up, read "get 1000 users," and produce useful work.

So I built a hierarchy:

Project → Objective → Key Result → Initiative → Task

Goals decompose into key results. Key results are advanced by initiatives. Initiatives contain tasks. Tasks are what agents actually do.

This was progress, but it still required me to manually decide which task to dispatch next, to which agent, and when. I was the bottleneck — the human scheduler in a system designed to be autonomous.

The fix was dependency chains. Each task can declare what it's blocked_by — a list of other task IDs that must complete first. This turned the task board into a directed acyclic graph. The system could now compute which tasks were ready without asking me.

Then the wave resolver: a 60-second polling loop that scans the dependency graph, finds tasks with all prerequisites met, and dispatches them to available agents. Sprint mode runs 5 per cycle, idle mode runs 1. The human sets goals and writes task descriptions. The system sequences and dispatches.

This is where the system started doing real autonomous work.

The real insight: the task is the unit of work

Three weeks of rebuilding the architecture around agents, then projects, then goals. And the thing that actually made it work was none of those.

The task is the atomic unit.

Everything else in the system — projects, goals, initiatives, dependency graphs, memory injection, skill discovery — exists for one purpose: to ensure that when an agent picks up a task, it has exactly the right context to do that task well.

The task description is the prompt. Not a summary, not a pointer to docs — the actual, complete specification of what needs to happen. File paths, line numbers, expected behavior, constraints, what NOT to do.

Bad task description:

Fix the memory system.

Good task description:

In memory.ts, the getRecentTurns() function on line 47
pulls turns without filtering by session_id. Add a WHERE
clause scoping to the current session. Do NOT change the
function signature. Run existing tests after.

The difference in output quality between those two descriptions is the difference between a system that works and one that doesn't. The agent doesn't need to understand the full project architecture. It needs to understand its task. The system's job is to make that task description rich enough to produce correct work.

This realization changed how everything flows. When a task gets dispatched, the agent receives:

  • The task description (the spec)
  • Goal context (why this matters)
  • Initiative context (what broader effort this serves)
  • Sibling task outcomes (what related work just completed)
  • Predecessor results (what the blocked-by tasks produced)
  • Project memory (persistent learnings from prior sessions)
  • Skills (what tools and procedures are available)

The agent doesn't curate this context. The system curates it. The agent consumes it, does the work, and reports back.

The overnight proof

Session 43 was the first real test. Started with a UI cleanup task — merging the sessions page into the chat widget. While working on that, found a production bug: new web chats were seeing ghost messages from prior conversations.

Traced the bug through 8 files across 3 layers. Found it: getRecentTurns() was injecting turns from the agent's entire history into every fresh session. No session filter. Two-line fix, but the investigation revealed 6 structural gaps in the session/memory system.

Created 6 improvement tasks with detailed descriptions. The wave resolver dispatched the first two to the builder agent. It completed both in worktree isolation — separate git branches with their own test runs, mergeable or discardable independently. No human guidance needed.

Then I loaded the overnight queue. 15+ tasks across builder and researcher agents. Hit sprint mode. Went to sleep.

Morning: 20 tasks completed. 12 worktree diffs waiting for review. 5 research reports delivered. The system over-delivered against my estimates by roughly 2.5x.

The next day, I reviewed and merged 13 features to master in about 2 hours. Earned autonomy (trust-based review tier adjustment). Event-driven dispatch (instant unblocking of dependent tasks). Schedule editing. Workflow config. Agent handoff notes. Compaction recovery. Channel-scoped turns. Each one a real architectural improvement, each one produced by an agent working from a task description.

What the system looks like now

The numbers as of today: 28 database tables. 2,200 lines of API routes. A wave resolver that dispatches tasks in dependency order. A CLI worker that runs up to 3 concurrent agent sessions. Worktree isolation for every code change. Three review tiers — auto, quick, and gate — with earned autonomy that adjusts tiers based on an agent's track record.

Five active agents: a main orchestrator, a marketing agent, a builder, a researcher, and a writer. Each with their own skills, workspace, and personality. The builder works in git worktrees. The writer produces content calendar items. The researcher produces reports that feed into other agents' context.

The content pipeline that produced this post: a task was created under the "Cornerstone Content" initiative, linked to the "Ship personal brand site" goal. The wave resolver dispatched it to the writer agent. The writer read the commit history, the build journals, the interview transcripts, and the architecture docs. It produced this MDX file. Lam will review it. If approved, it publishes to dryp.dev.

That's the recursive proof. The system is describing the system.

What still doesn't work

Honesty section, because posts that skip this part are useless.

Cross-agent handoffs lose information at the boundaries. When a researcher produces findings that a writer needs, the handoff is a text blob. Structured handoff notes help, but the context compression is still lossy.

The earned autonomy model needs more data. The trust scoring is there, but the sample sizes per agent are small. Auto-tier decisions are conservative by default, which means the human still reviews more than necessary.

Context injection could be smarter about what gets included. Right now it's mostly "inject everything relevant" which sometimes means the agent gets 40KB of context for a task that needs 2KB. Token budget awareness would help.

And the big one: task description quality is still the highest-leverage human input. The system can sequence, dispatch, and review. It can't yet write its own task descriptions at the level of detail that produces consistently good output. That's where the human is still irreplaceable — and maybe should be.

The pattern

For anyone building agent systems, the evolution we went through seems to be convergent. Other teams arrive at similar conclusions:

  1. Start agent-first. Hit the coordination wall.
  2. Add project structure. Agents stop hallucinating context.
  3. Add goal hierarchy. Work gets direction.
  4. Add dependency graphs. Dispatch becomes automatic.
  5. Add tiered review. The human stops being the bottleneck.
  6. Realize the task description is everything. Invest there.

The task is not a ticket in a project management tool. It's the prompt that an agent executes against. Every minute spent writing a better task description pays back tenfold in output quality. Every architectural decision should be evaluated by one question: does this make the agent's context better when it picks up a task?

That's what a task resolution engine is. Not a project manager with AI. Not a chatbot with a to-do list. A system where everything — goals, memory, skills, dependency graphs, review loops, handoff notes — converges on a single moment: an agent picking up a task and having exactly what it needs to do that task well.

Eighteen days from OpenClaw clone to here. The system is still early. But it compounds. Every review teaches it something. Every task description gets a little more precise. Every architectural decision removes one more gap between what the agent needs and what it gets.

That's the game. Not perfection on day one. Compounding resolution over time.

← All posts