# How Maka's Resume System Creates a New Execution Instead of Reviving an Old Process

> Discover how Maka's resume system initiates new executions by replaying context from an immutable ledger, avoiding old process resurrection. Learn the technical details.

- Repository: [The Apache Software Foundation/maka](https://github.com/apache/maka)
- Tags: internals
- Published: 2026-08-26

---

**Maka's resume system treats continuation requests as brand-new execution instances that replay prior context from an immutable event ledger, avoiding any attempt to resurrect or mutate the original process.**

In the Apache Maka codebase, resuming an interrupted plan does not "wake up" a sleeping process. Instead, the system leverages event sourcing and strict validation guards to spawn a fresh agent that picks up where the previous execution left off. This architectural choice ensures immutable audit trails while providing seamless user continuity.

## Why Maka Spawns a Fresh Execution on Resume

Traditional workflow engines often attempt to restore a process from a checkpoint, risking state corruption and complicating debugging. Maka takes the opposite approach: every resume is a **new execution** that inherits context through explicit event replay rather than process revival.

This design enforces **immutable execution history**. The original record remains permanently archived with status `interrupted`, while the new run creates its own distinct execution trail. According to the source code in `apache/maka`, this separation prevents side-effects from cascading between runs and maintains a clean audit log for compliance and debugging.

## The Four Architectural Guards That Prevent Process Revival

The resume mechanism relies on four distinct code-level enforcements that collectively ensure no existing process is ever revived.

### Immutable Execution History via Event Sourcing

In [`packages/storage/src/plan-store.ts`](https://github.com/apache/maka/blob/main/packages/storage/src/plan-store.ts), the `resumeExecution` method explicitly creates a **new event** rather than mutating the existing record. Between lines 377 and 398, the method appends a `plan_execution_resumed` event to the SQLite ledger:

```typescript
async resumeExecution(sessionId: string, executionId: string, operationId?: string) {
  return this.mutate(sessionId, operationId, { sessionId, executionId }, async (state) => {
    // Validation logic omitted for brevity
    return {
      type: 'plan_execution_resumed',
      id: operationId ?? this.newId(),
      sessionId,
      ts: this.now(),
      storeVersion: state.storeVersion + 1,
      executionId, // References the old execution but creates new event
    };
  });
}

```

The original `interrupted` execution remains untouched in the database, preserving the exact state at the time of interruption.

### Validation Guards Against Active Executions

Before creating the resume event, Maka enforces two critical preconditions in [`plan-store.ts`](https://github.com/apache/maka/blob/main/plan-store.ts) (lines 381-389):

1. **No active execution exists**: The method checks `state.activeExecutionId` and throws a `PlanConflictError` if a plan is currently running.
2. **Target must be interrupted**: The code verifies `execution.status === 'interrupted'`, ensuring users cannot resume completed or failed runs.

These guards prevent the system from attempting to "attach" to a running process or revive an incompatible state.

### Fresh Agent Instantiation in the Runtime

When the runtime processes a resume request, it does not reconnect to an existing agent. In [`packages/runtime/src/tool-runtime.ts`](https://github.com/apache/maka/blob/main/packages/runtime/src/tool-runtime.ts) (lines 2212-2225), the `resumeChildAgent` callback creates an entirely new execution context:

```typescript
if (resumeChildAgent) {
  await resumeChildAgent({
    mode: 'resume',
    sourceRunId: resumeInput.sourceRunId,
    prompt: resumeInput.prompt,
    onReady: resumeInput.onReady,
    onEvent: resumeInput.onEvent,
    abortSignal: resumeInput.abortSignal,
  });
}

```

The `mode: 'resume'` parameter signals the runtime to treat this as a continuation, but the underlying mechanism still calls `childAgent.run()` with the previous transcript provided as `initialContext`.

### State Reconstruction from the Ledger

Rather than restoring from a memory dump or process snapshot, Maka reconstructs state by replaying events. The `stateThroughEvent` helper in [`plan-store.ts`](https://github.com/apache/maka/blob/main/plan-store.ts) (lines 96-105) walks the persisted event log up to the latest `plan_execution_resumed` entry, generating a fresh `PlanSessionState` object for the new execution to consume.

## Step-by-Step Flow of a Resume Operation

The complete resume lifecycle follows this strict sequence:

1. **User initiation**: A resume request is issued via CLI (`maka --resume <execution-id>`) or UI interaction.

2. **Authority validation**: `PlanAuthority` forwards the request to `PlanStore.resumeExecution`, which validates that no execution is currently active and that the target status is `interrupted`.

3. **Event creation**: A new `plan_execution_resumed` event is atomically appended to the plan ledger in SQLite.

4. **State reconstruction**: The runtime calls `stateThroughEvent` to rebuild the session state from the event log.

5. **Agent spawning**: `ToolRuntime` invokes `resumeChildAgent` with `mode: 'resume'`, launching a fresh agent process.

6. **Context injection**: The new agent receives the previous execution's transcript as `initialContext`, allowing seamless continuation without process revival.

## Code Implementation Examples

### CLI Resume Request

```bash
$ maka --resume 7f3c9a1b-d4e2-4a6f-b8e1-c9f7a5e4b2d3

```

### Authority Layer Integration

```typescript
export const planAuthority = {
  resumeExecution: (sessionId, executionId, operationId) =>
    run(() => store.resumeExecution(sessionId, executionId, operationId)),
};

```

### Runtime Resume Handling

The new agent starts with the previous transcript as its initial context:

```typescript
await childAgent.run({
  // The transcript from the interrupted execution becomes the initial context
  initialContext: previousRun.transcript,
});

```

### Key Source Files

| File | Purpose |
|------|---------|
| [`packages/storage/src/plan-store.ts`](https://github.com/apache/maka/blob/main/packages/storage/src/plan-store.ts) | Core store that validates and emits resume events |
| [`packages/storage/src/plan-authority.ts`](https://github.com/apache/maka/blob/main/packages/storage/src/plan-authority.ts) | Public API forwarding resume requests |
| [`packages/runtime/src/tool-runtime.ts`](https://github.com/apache/maka/blob/main/packages/runtime/src/tool-runtime.ts) | Runtime logic for fresh agent creation |
| [`packages/ui/src/session-context-layer.tsx`](https://github.com/apache/maka/blob/main/packages/ui/src/session-context-layer.tsx) | UI layer exposing resume functionality |

## Summary

- **New execution guarantee**: Maka creates a distinct execution instance for every resume, never reviving the original process.
- **Immutable audit trail**: The original `interrupted` execution remains unchanged in the SQLite ledger; resume operations append new events.
- **Strict validation**: The system checks for absence of active executions and verifies `interrupted` status before allowing continuation.
- **Fresh agent spawning**: `ToolRuntime` launches a new child agent with `mode: 'resume'`, passing previous context as initial state.
- **Event-sourced reconstruction**: State is rebuilt by replaying the event log rather than restoring process memory.

## Frequently Asked Questions

### Does resuming modify the original execution record?

No. The original execution remains immutable with status `interrupted`. The `resumeExecution` method in [`plan-store.ts`](https://github.com/apache/maka/blob/main/plan-store.ts) creates a new `plan_execution_resumed` event that references the old execution ID but writes to a new record, preserving the complete history of both the original interruption and the subsequent resumption.

### What prevents resuming an already running execution?

The store layer enforces two guards before processing a resume: it checks that `state.activeExecutionId` is null (no active execution exists) and that the target execution's status equals `interrupted`. If either condition fails, the system throws a `PlanConflictError`, preventing any attempt to attach to a running process.

### How does the new execution access the previous context?

The runtime passes the previous execution's transcript via the `initialContext` parameter when calling `childAgent.run()`. This occurs in `ToolRuntime` when handling the `resume` mode, allowing the fresh agent to inherit the conversation history and state without accessing the original process memory.

### Where is the resume state stored?

Resume state persists in Maka's SQLite ledger as discrete events. The `plan_execution_resumed` event type contains the session ID, execution ID, and timestamp, while the full execution state is reconstructed on-demand using the `stateThroughEvent` helper that replays relevant events from the append-only log.