Task Execution

A healthy AlphaBase task should render in this sequence:

1. user prompt accepted
2. running/streaming state
3. tool activity and intermediate updates
4. file/tool outputs
5. final completion response

Tool Activity Expectations

Good tool timelines are action-oriented and grouped, for example:

• searched workspace
• explored files
• ran shell checks
• applied edits

Multi-Task Sessions

A single session can accumulate many unrelated prompts over time (a quick question, then an unrelated build task, then another unrelated build task). AlphaBase segments a session’s history into tasks and scopes the active task’s context — both the message history sent to the model and the search_history tool — to that task only. Earlier unrelated tasks in the same session are kept out of the model’s context for the current prompt, so the model does not drift onto a topic from a different, earlier task.

Deliverable Verification

For build-style tasks AlphaBase distinguishes a plan from a finished deliverable. Planning artifacts (for example a SPEC.md or plan.md the model writes to organize its own work) are explicitly not treated as task completion. A turn is only considered complete once a concrete output exists that is non-trivial in size and matches the task’s stated topic.

Recovery And Loop Limits

When a turn stops without a usable terminal result, the runtime may apply a bounded recovery or handoff path. The exact number and type of retries depend on the active client, model execution contract, provider response, and configured runtime policies; AlphaBase does not promise a fixed public retry count or a set of environment variables for changing it.

The important user-visible contract is that execution eventually records a terminal outcome (completed, failed, cancelled, handoff, or unknown). If Smart Router is explicitly enabled, a later attempt may use another compatible candidate from its request pool. A retry is not evidence that a deliverable was produced, so inspect the artifact and terminal status before treating the task as complete.

Output Integrity Checks

If execution is healthy:

• generated code appears in write/edit artifact blocks
• file paths are concrete and openable
• completion message summarizes what changed

Regression Signals

Watch for:

• intermediate response text leaking into final response area
• abrupt termination before terminal completion message
• duplicate thought/response emissions
• disappearing or flickering streamed content
• a task repeatedly re-planning without ever writing output; report this with the task’s terminal status and runtime diagnostics

Use Troubleshooting for investigation flow, and Launch Gates for how this behavior is tested before a release.