Context

Define and implement the ExecutionLoop protocol per DESIGN_SPEC §6.5. The agent execution loop defines how an agent processes a task from start to finish. The framework provides multiple configurable loop architectures behind an ExecutionLoop protocol, making the system extensible.

The agent engine (#11) delegates task processing to the configured ExecutionLoop implementation. This issue defines the protocol and implements the ReAct loop (MVP default). Plan-and-Execute and Hybrid loops are defined here for completeness but can be implemented incrementally.

Loop Architectures (§6.5)

Loop 1: ReAct (Default for Simple Tasks) — MVP

Single interleaved loop: think → act → observe → repeat until done or max_turns reached.

• Simple, proven, flexible. Works well for short tasks
• Token-heavy on long tasks (re-reads full context every turn)

Loop 2: Plan-and-Execute (Future)

Two-phase: agent generates a step-by-step plan, then executes each step. On failure, replan. Supports different models for planning vs execution (cost optimization).

• Token-efficient for long tasks. Auditable plan artifact
• Rigid — replanning is expensive

Loop 3: Hybrid Plan + ReAct Steps (Future)

High-level plan (3-7 steps), each step executed as mini-ReAct loop. Checkpoints between steps for progress summary and optional replanning.

• Strategic planning + tactical flexibility. Natural checkpoints for suspension/inspection
• Most complex to implement

Auto-selection (Optional, Future)

When execution_loop: "auto", framework selects loop based on estimated_complexity via auto_loop_rules.

Acceptance Criteria

Protocol Interface

• ExecutionLoop protocol defined with standard operations (execute_task, get_loop_type)
• Protocol accepts agent context, task, and tools — returns execution result
• execution_loop config key selects implementation ("react", "plan_execute", "hybrid", "auto")
• New loop architectures addable without modifying existing ones

ReAct Implementation (MVP)

• Think → Act → Observe loop with configurable max_turns
• Tool call handling within the loop (invoke tool, feed results back)
• Termination conditions: task complete, max turns, budget exhausted, or blocked
• Loop metadata: turn count, tool calls made, tokens per turn

Future (Not M3, But Protocol Must Support)

• Protocol designed to accommodate Plan-and-Execute (plan artifact, step execution, replanning)
• Protocol designed to accommodate Hybrid (checkpoint support, mini-loop context)
• Protocol designed to accommodate auto-selection

Testing

• Unit tests for ReAct loop with mock LLM (>80% coverage)
• Test: max turns terminates correctly
• Test: tool calls processed and results fed back
• Test: budget exhaustion terminates loop

Dependencies

• Provider layer (M2, done)
• Tool system (ToolInvoker, ToolRegistry — M2/M2.5)
• Agent engine (Implement agent engine core with ExecutionLoop protocol integration (DESIGN_SPEC §3.1, §6.1, §6.5) #11) — consumes this protocol

Design Spec Reference

• §6.5 — Agent Execution Loop (ExecutionLoop protocol, 3 architectures, auto-selection)