-
-
Notifications
You must be signed in to change notification settings - Fork 69
Labels
featureRequested feature or new featureRequested feature or new featuregood first issueGood for newcomersGood for newcomers
Description
Summary
Add a planning layer and multi-step agent capability so agents can decompose tasks into ordered subtasks, maintain context across steps, and reliably execute multi-action workflows.
Motivation
Current single-turn agents are limited for complex tasks that require planning, intermediate decisions, or external actions (APIs, I/O). Enabling multi-step agents will:
- Allow complex workflows (e.g., research → draft → verify → publish).
- Improve reliability by making execution explicit and recoverable.
- Make automation and orchestration use-cases practical.
Goals
- Provide a planner that decomposes high-level goals into discrete steps/actions.
- Provide a step executor that runs actions sequentially, maintains context, and handles failures/retries.
- Expose a clear API for building multi-step agents and plugging in tool actions (APIs, shell commands, database ops).
- Persist context and execution history so agents can resume and audit runs.
Non-goals
- Building domain-specific planners (we provide general primitives).
- Replacing orchestration systems (this complements them for agent-level planning).
Proposed design (high-level)
-
Planner component
- Input: goal + optional constraints
- Output: ordered list of steps (each step: description, required tools, expected output)
- Options: depth/iterations limits, cost/latency tradeoffs
-
Executor component
- Runs steps in order, invoking tool adapters
- Maintains and updates context/memory between steps
- Handles step failures (retry/backoff/skip/rollback) based on policy
- Emits structured logs and events
-
Tool Adapter layer
- Standard interface for external integrations (HTTP, DB, file, shell, LLM calls)
- Includes sandboxing/timeouts/rate-limit handling
-
Persistence & Resume
- Store plan, step states, intermediate outputs, and metadata
- Support resuming from the last successful step
-
Observability & Debugging
- Structured execution logs, step-level metrics, and traceability
- Optionally export to existing telemetry backends
Example flow
- User: “Create a short blog post about X, include links and references.”
- Planner: [Research → Outline → Draft → Fact-check → Finalize]
- Executor:
- Step 1: Research — call search API, store references.
- Step 2: Outline — call LLM with references.
- Step 3: Draft — generate content from outline.
- Step 4: Fact-check — validate claims via APIs.
- Step 5: Finalize — produce final post and metadata.
API / UX suggestions (pseudo)
- plan = planner.create_plan(goal="Write blog post about X", constraints={length:300-500})
- run_id = executor.execute(plan, resume=false, on_step=callback)
- executor.resume(run_id)
Acceptance criteria (testable)
- An agent can accept a high-level goal and produce a multi-step plan.
- Steps are executed in order and intermediate outputs are accessible.
- Failures are detected and a configurable retry strategy is applied.
- Execution can be paused and resumed with preserved context.
- Tool adapters can be added with a documented interface.
- Logs show step-level inputs/outputs for auditing.
Implementation notes / priorities
- Phase 1: Minimal planner + sequential executor + in-memory persistence + 2-3 core tool adapters (HTTP, file, LLM).
- Phase 2: Durable storage, advanced retry/rollback policies, UI for monitoring, plugin system.
- Keep planner as a replaceable strategy so teams can swap simple heuristics for advanced planners..
Gerome-Elassaad
Metadata
Metadata
Assignees
Labels
featureRequested feature or new featureRequested feature or new featuregood first issueGood for newcomersGood for newcomers