Task Runtime

The dialogue layer first decides whether the user input contains a task. If a task exists, the runtime receives a concrete task description and starts an execution loop.

Execution Flow

1. Detect whether the user is asking for executable work.
2. Create an initial plan.
3. Run one step at a time.
4. Call tools when external action or evidence is needed.
5. Update plan state as steps complete or change.
6. Report observations, file changes, failures, and verification state.

type TaskState = {
  id: string;
  status: "queued" | "running" | "blocked" | "completed" | "failed";
  plan: Array<{
    title: string;
    status: "pending" | "in_progress" | "completed";
  }>;
};

User Input Requests

When a task needs credentials, API keys, verification codes, or paths, it should request user input instead of guessing. The request should include enough context for the user to understand why the input is required.

Failure Handling

Runtime failures should be recoverable when possible:

• Preserve the last successful observation.
• Mark the active plan step as blocked or failed.
• Surface the concrete missing input or failing command.
• Avoid hiding tool errors inside generic assistant prose.