BAARA Next: A Durable Agentic Task Execution Engine

Problem

Agent tasks are long-running, expensive, and fragile. A single LLM-driven job can run for many turns, consume real budget, and then lose everything when the host process crashes or restarts. Most agent frameworks treat execution as ephemeral: if the process dies mid-run, the conversation and its accumulated work disappear, and there is no principled way to resume.

Durable workflow engines like Temporal solve the durability problem, but they bring heavyweight infrastructure and a programming model that doesn’t map cleanly onto conversational agent loops. I wanted durability — checkpointing, automatic retries, a dead-letter queue — without standing up a separate orchestration cluster, and without leaving TypeScript.

The motivation was to make agent execution survivable and operable: tasks that resume after failure, a clear lifecycle you can reason about, and a single tool surface I could drive from a chat UI, a CLI, an API, or directly inside Claude Code.

Approach

I structured BAARA Next as a 10-package monorepo on Bun, deliberately process-agnostic. In dev mode every package wires together in one process via an in-process transport; in production the same packages bridge over HTTP. The core package defines shared interfaces — IStore, ISandbox, IMessageBus — and a state machine that every status transition must pass through.

For durability I chose a hybrid persistence model rather than pure event sourcing. An append-only execution_events table provides an audit log, while a mutable executions table holds authoritative current state. Recovery does not replay events: the executor loads the last checkpoint from task_messages, injects it as conversation history, and continues from the next turn. This keeps recovery O(1) regardless of event volume.

I designed a single ISandbox interface with three implementations — Native, Wasm (Extism), and Docker — so isolation can be swapped per task without touching business logic. The same Claude Code SDK call sits inside each one.

Key Design Elements

• Conversation-level checkpointing every 5 turns for crash-safe resume
• 11-state lifecycle with exponential-backoff retries and a dead-letter queue
• 27-tool MCP server running in-process, over stdio, and as an HTTP endpoint
• Hono HTTP server with rate limiting, optional API-key auth, and SSE chat streaming
• React/Vite/Tailwind UI rendering inline execution cards from tool results

Outcomes

• Agent tasks resume exactly where they left off after a crash, restart, or transient failure, with exhausted tasks captured in a dead-letter queue instead of vanishing.
• The entire system — orchestrator, agent, and HTTP server — runs from one bun start, with no Go, Rust, or native addons required to get started.
• A single 27-tool surface is reachable from the chat UI, REST API, CLI, and Claude Code, so the same capabilities are available wherever I work.

Key Contributions

• Designed and built a process-agnostic 10-package TypeScript monorepo unified by shared core interfaces and a centrally enforced state machine.
• Implemented conversation-level checkpointing and a checkpoint-based recovery path that resumes from turn N+1 in constant time.
• Built the 11-state execution lifecycle with exponential-backoff retries and a dead-letter queue for permanent failures.
• Created a 27-tool MCP server with three transports (in-process, stdio, HTTP) for chat, Claude Code, and API consumers.
• Engineered the ISandbox abstraction with Native, Wasm, and Docker backends swappable per task.
• Developed the SSE chat protocol and React frontend that renders streaming text and inline execution cards.