agentbyte 0.4.3__tar.gz → 0.4.6__tar.gz

{agentbyte-0.4.3 → agentbyte-0.4.6}/.github/skills/agentbyte-ai-driven-orchestration/SKILL.md

@@ -6,11 +6,24 @@ license: MIT
 
 Use this skill when implementing multi-agent collaboration where an LLM intelligently selects which agent should respond next based on conversation context and agent capabilities.
 
+## Inputs to confirm
+- Which agents are available and how clearly their descriptions express specialization
+- What should stop the orchestration
+- Whether the selector should see a compact summary or a richer selector context
+- Whether worker agents should receive full history or a narrower execution history
+
 ## Pattern: Basic AI-Driven Orchestration
 
 ```python
 import asyncio
-from agentbyte import AIOrchestrator, Agent, UserMessage
+from agentbyte import (
+    AIOrchestrator,
+    Agent,
+    AgentHistoryPolicy,
+    HistoryContextPolicy,
+    SelectorContextPolicy,
+    UserMessage,
+)
 from agentbyte.llm import OpenAIChatCompletionClient
 from agentbyte.termination import MaxMessageTermination, TextMentionTermination
 
@@ -47,7 +60,15 @@ async def main():
         agents=[researcher, writer],
         termination=termination,
         model_client=client,  # Required: LLM for agent selection
-        max_iterations=6
+        max_iterations=6,
+        history_policy=HistoryContextPolicy(
+            default=AgentHistoryPolicy(window="full", format="text")
+        ),
+        selector_policy=SelectorContextPolicy(
+            window="recent",
+            message_limit=12,
+            format="summary",
+        ),
     )
 
     # 5. Run the collaboration
@@ -87,25 +108,47 @@ async for item in orchestrator.run_stream(task, verbose=True):
 3. **Reasoning Included:** Selection events include the LLM's reasoning for why it chose that agent
 4. **Fallback Safety:** If LLM selection fails or returns invalid agent name, falls back to round-robin
 
-## Configuration Options
+## Policy Surface
 
 ```python
 orchestrator = AIOrchestrator(
-    agents=[agent1, agent2, agent3],     # Required: List of agents
-    termination=termination_condition,    # Required: When to stop
-    model_client=selection_model_client,  # Required: LLM for agent selection
-    max_iterations=10,                    # Optional: Safety limit (default: 10)
-    verbose=False                         # Optional: Enable event logging
+    agents=[agent1, agent2, agent3],
+    termination=termination_condition,
+    model_client=selection_model_client,
+    max_iterations=10,
+    history_policy=HistoryContextPolicy(
+        default=AgentHistoryPolicy(window="full", format="text")
+    ),
+    selector_policy=SelectorContextPolicy(
+        window="recent",
+        message_limit=12,
+        format="summary",
+    ),
 )
 ```
 
+Use the two policies for different jobs:
+- `HistoryContextPolicy`: contains a default `AgentHistoryPolicy` plus optional per-agent `AgentHistoryPolicy` overrides for worker execution
+- `SelectorContextPolicy`: controls what the selector model sees when deciding which agent should go next
+
+`AgentHistoryPolicy` is the per-agent rule that actually defines:
+- `window`
+- `message_limit`
+- `format`
+- `include_turn_prompt`
+
+Selector formatting affects routing quality:
+- `summary` is compact and best for many coordination tasks
+- `markdown` can help readability on long transcripts
+- `json` can help when explicit role/source/content structure matters
+
 ## Pattern Metadata
 
 After completion, `result.pattern_metadata` contains:
 - `iterations_completed`: Total agent executions
 - `selector_calls`: Number of LLM selection calls made
-- `fallback_count`: How many times round-robin fallback was used
-- `final_reason`: Why orchestration stopped
+- `selector_model`: Model used for routing
+- `selector_policy`: Serialized selector-context configuration
 
 ## Usage Tracking
 
@@ -136,8 +179,9 @@ description="Agent 1"  # No capability info
 
 - **Model Client Required:** `AIOrchestrator` needs a `model_client` parameter for agent selection (unlike `RoundRobinOrchestrator`).
 - **Clear Descriptions:** Write specific agent descriptions—the LLM uses these to decide who should respond.
+- **Two Context Surfaces:** Do not confuse `history_policy` with `selector_policy`; one shapes execution, the other shapes routing.
 - **Termination Required:** Always provide termination conditions to prevent infinite loops.
-- **Safety Fallback:** If LLM selection fails, orchestrator falls back to round-robin (check `fallback_count` in metadata).
+- **Safety Fallback:** If LLM selection fails, the orchestrator falls back to round-robin selection to preserve forward progress.
 - **Usage Accounting:** Final usage includes both agent tokens AND selector tokens.
 - **Case Insensitive:** Agent name matching is case-insensitive for robustness.
 - **Event Observability:** Use `verbose=True` with `run_stream()` to see AI selection reasoning.
@@ -160,12 +204,6 @@ description="Agent 1"  # No capability info
 4. **Dynamic Collaboration:** Agents with overlapping capabilities—LLM picks best fit
 5. **Question Routing:** Route user questions to the most appropriate agent based on content
 
-## Examples
-
-- Basic: `examples/orchestration/ai_driven_basic.py`
-- Streaming: `examples/orchestration/ai_driven_stream.py`
-- With OTel: `examples/orchestration/ai_driven_with_otel.py`
-
 ## OpenTelemetry Integration
 
 For observability with Jaeger:

{agentbyte-0.4.3 → agentbyte-0.4.6}/.github/skills/agentbyte-dataset/SKILL.md

@@ -6,13 +6,16 @@ description: Guide for creating and using Agentbyte datasets with SQLite or JSON
 Use this skill when you need to:
 - **Load** an existing dataset using `load_dataset()`
 - **Create** a new dataset with config.json, schema.json, and data.json
+- **Load** the same dataset structure from local disk or S3
 - **Query** SQLite datasets with SQL or iterate JSON datasets
 - **Display** dataset schemas in pretty or raw format
 - **Work with** multiple data engines (SQLite for structured, JSON for semi-structured)
 
 ## Dataset Architecture
 
-Agentbyte datasets are file-based and engine-agnostic. Each dataset lives in `data/samples/{category}/{name}/` with three files:
+Agentbyte datasets are file-based and engine-agnostic. The dataset contract stays the same whether the files live on local disk or in S3.
+
+Local layout:
 
 ### File Structure
 ```
@@ -22,6 +25,14 @@ data/samples/{category}/{name}/
 └── data.json        # Records only ({"records": [...]})
 ```
 
+Equivalent S3 layout:
+```
+s3://<bucket>/<optional-prefix>/{category}/{name}/
+├── config.json
+├── schema.json
+└── data.json
+```
+
 ### Supported Engines
 - **sqlite** (default): Structured data with SQL queries, strict schema, constraints
 - **json**: Semi-structured data, flexible JSON format, inferred schema
@@ -92,11 +103,17 @@ with open(dataset_dir / "data.json", "w") as f:
 
 ### Load a Dataset
 ```python
-from agentbyte.dataset import load_dataset
+from agentbyte.dataset import DatasetSettings, load_dataset
 
 ds = load_dataset("category/name")  # Returns SQLiteDataset or JSONDataset
 print(ds.engine)        # "sqlite" or "json"
 print(ds.table_name)    # Table/collection name
+
+settings = DatasetSettings(
+    s3_bucket="datapsycho-datasets",
+    s3_prefix="datasets",
+)
+ds_s3 = load_dataset("category/name", source="s3", settings=settings)
 ```
 
 ### Connect & Get Data
@@ -163,13 +180,30 @@ for i, record in enumerate(data["records"], 1):
 ### Example 3: Create Dataset Programmatically
 See "Creating a Dataset" section above for step-by-step code.
 
+### Example 4: Load From S3
+```python
+from agentbyte.dataset import DatasetSettings, load_dataset
+
+settings = DatasetSettings(
+    s3_bucket="datapsycho-datasets",
+    s3_region="eu-west-1",
+    s3_prefix="datasets",
+)
+
+ds = load_dataset("contracts10/asmd", source="s3", settings=settings)
+conn = ds.connect()
+rows = conn.execute("SELECT * FROM contracts_asmd").fetchall()
+```
+
 ## Guardrails
 
 - **Do** use relative paths from project root in `load_dataset()` (e.g., `"contracts/asmd"`, not full file paths).
+- **Do** keep `dataset_id` logical (`"category/name"`) and configure S3 location through `DatasetSettings`.
 - **Do** keep schema.json separate from data.json for clarity and reusability.
 - **Do** use `dict(row)` to convert sqlite3.Row objects to dicts for JSON serialization.
 - **Do** call `ds.connect()` only once; it caches the connection and schema on first call.
 - **Don't** hard-code values in datasets (use config.json for metadata).
+- **Don't** store bucket names or S3 prefixes inside `config.json`.
 - **Don't** forget `.json` extensions for all three files.
 - **Don't** put schema definitions inside data.json (separate files for clarity).
 - **Don't** assume JSON datasets support SQL—use dict iteration instead.
@@ -178,15 +212,22 @@ See "Creating a Dataset" section above for step-by-step code.
 
 ### Factory Function
 ```python
-load_dataset(dataset_id: str) -> BaseDataset
+load_dataset(
+    dataset_id: str,
+    source: Literal["local", "s3"] = "local",
+    settings: DatasetSettings | None = None,
+) -> BaseDataset
 ```
-Loads dataset from `data/samples/{category}/{name}/`. Returns `SQLiteDataset` or `JSONDataset` based on config.engine.
+Loads dataset from `data/samples/{category}/{name}/` or from
+`s3://bucket/prefix/{category}/{name}/`. Returns `SQLiteDataset` or `JSONDataset`
+based on `config.engine`.
 
 ### Classes (Generic)
 - **Column**: name (str), type (str)
 - **Schema**: columns (list[Column])
 - **DataRecord**: id (str), data (Any), metadata (dict)
 - **DatasetConfig**: engine (str), table_name (str), in_memory (bool), description (str)
+- **DatasetSettings**: s3_bucket (str), s3_region (str), s3_prefix (str)
 - **SchemaFormat**: RAW or PRETTY enum for display formats
 
 ### Classes (SQLite-Specific)
@@ -203,6 +244,8 @@ Loads dataset from `data/samples/{category}/{name}/`. Returns `SQLiteDataset` or
 |-------|-----|
 | `FileNotFoundError: Schema file not found` | Ensure `schema.json` exists in dataset directory |
 | `FileNotFoundError: Data file not found` | Ensure `data.json` exists in dataset directory |
+| `FileNotFoundError: Dataset object not found: s3://...` | Ensure the bucket, prefix, dataset_id, and object names are correct |
+| `ValueError: Missing required dataset S3 settings` | Set `AGENTBYTE_DATASET_S3_BUCKET` or pass `DatasetSettings(...)` explicitly |
 | `KeyError: 'records'` | data.json must have `{"records": [...]}` structure |
 | `sqlite3.Row has no .dict() method` | Use `dict(row)` instead of `row.dict()` |
 | Notebook paths fail in `load_dataset()` | Use relative paths from project root; notebook working directory is handled by loader |

agentbyte-0.4.6/.github/skills/agentbyte-multi-turn-context/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: agentbyte-multi-turn-context
+description: Guide for managing Agentbyte multi-turn conversations using AgentContext and session stores. Use this when implementing stateful chats, persistent sessions, session switching, or threading history across agents, orchestrators, and workflow steps.
+---
+
+Use this skill when building conversational agents that need to remember previous turns, or when sessions must persist across process restarts.
+
+## Core Concept
+
+`AgentContext` IS the session — it carries `messages`, `session_id`, `metadata`, and
+`shared_state`. There is no separate `Session` domain model. The caller owns the context
+and passes it in; the agent or orchestrator reads and writes it in place.
+
+## Pattern: Basic Multi-Turn Agent
+
+```python
+from agentbyte.context import AgentContext
+from agentbyte.agents import Agent
+
+session_context = AgentContext(session_id="user-123")
+agent = Agent(name="chat-bot", ...)
+
+# First turn
+response1 = await agent.run("Hi, I am Alex", context=session_context)
+
+# Second turn — re-use the same context; history is already updated
+response2 = await agent.run("What is my name?", context=session_context)
+print(response2.final_content)  # "Your name is Alex"
+```
+
+## Pattern: Persistent Sessions with Session Stores
+
+Session stores persist `AgentContext` across process restarts. Three built-in options:
+
+| Store | Backend | Use when |
+|-------|---------|----------|
+| `InMemorySessionStore` | Python dict (volatile) | Tests, single-process demos |
+| `FileSessionStore` | One JSON file per session | Simple persistence, low concurrency |
+| `CachedFileSessionStore` | In-memory cache + file | Production: fast reads, durable writes |
+
+```python
+from agentbyte.context import AgentContext
+from agentbyte.session_store import CachedFileSessionStore
+
+store = CachedFileSessionStore(".sessions")
+session_id = "user-123"
+
+# Load or create
+ctx = await store.get(session_id) or AgentContext(session_id=session_id)
+
+response = await agent.run("Remember: my budget is $500", context=ctx)
+
+# Persist after each turn
+await store.save(session_id, ctx)
+```
+
+All three stores share the same `SessionStore` interface:
+```python
+await store.get(session_id)        # AgentContext | None
+await store.save(session_id, ctx)  # None
+await store.list()                 # Iterable[tuple[str, AgentContext]]
+await store.delete(session_id)     # bool
+await store.clear_all()            # int (count deleted)
+```
+
+Import from any of these paths:
+```python
+from agentbyte import CachedFileSessionStore       # package root
+from agentbyte.session_store import FileSessionStore  # module
+from agentbyte.webui import InMemorySessionStore   # webui re-export
+```
+
+## Pattern: Orchestrator Sessions
+
+`BaseOrchestrator.run()` and `run_stream()` accept an optional `context` parameter.
+The orchestrator seeds its `shared_messages` from `context.messages` at the start of
+each run, then writes the full conversation back before returning.
+
+```python
+from agentbyte.context import AgentContext
+from agentbyte.session_store import CachedFileSessionStore
+from agentbyte.presets.orchestration import get_orchestrator
+
+store = CachedFileSessionStore(".sessions")
+session_id = "orch-session-1"
+orchestrator = get_orchestrator("round_robin", agents=[agent_a, agent_b])
+
+# Turn 1
+ctx = await store.get(session_id) or AgentContext(session_id=session_id)
+response = await orchestrator.run(task="Draft an intro paragraph.", context=ctx)
+await store.save(session_id, ctx)
+
+# Turn 2 — prior conversation is loaded from the store
+ctx = await store.get(session_id)
+response = await orchestrator.run(task="Now make it more concise.", context=ctx)
+await store.save(session_id, ctx)
+```
+
+## Pattern: Workflow Step Sessions (AgentbyteAgentStep)
+
+Workflows are pipelines — they do not thread conversation history automatically.
+Pass `AgentContext` via `agent_context` on `AgentbyteAgentInput` when a step agent
+needs session continuity.
+
+```python
+from agentbyte.context import AgentContext
+from agentbyte.session_store import CachedFileSessionStore
+from agentbyte.workflow.steps import AgentbyteAgentInput
+
+store = CachedFileSessionStore(".sessions")
+ctx = await store.get("step-session") or AgentContext(session_id="step-session")
+
+execution = await runner.run(
+    workflow,
+    AgentbyteAgentInput(task="Summarise the report", agent_context=ctx),
+)
+await store.save("step-session", ctx)
+```
+
+`agent_context` is always optional — omit it for a stateless step.
+
+## Key Attributes
+
+- **`context.messages`**: Conversation history (list of `Message`).
+- **`context.session_id`**: Identifier set at creation; used as store key.
+- **`context.metadata`**: Dict of custom data carried across turns.
+- **`context.shared_state`**: Cross-agent shared state (orchestrators).
+
+## Guardrails
+
+- Never store conversation history on the `Agent` object — always on `AgentContext`.
+- The caller is responsible for persisting the context (call `store.save()` after each turn).
+- Do not pass the same `AgentContext` to two concurrent agent runs — it is not thread-safe.
+- For workflow pipelines, use `AgentbyteAgentInput.agent_context`; do not embed `AgentContext` in the workflow `Context` dict.
+- Add `.sessions/` to `.gitignore` to avoid committing session JSON files.

agentbyte-0.4.6/.github/skills/agentbyte-otel-tracing/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: agentbyte-otel-tracing
+description: Guide for enabling OpenTelemetry tracing in Agentbyte for agents, orchestrators, and workflows. Use this when adding Jaeger/OTLP observability, tracing model or tool calls, or validating runtime span hierarchies.
+license: MIT
+---
+
+Use this skill when adding OpenTelemetry-based observability to Agentbyte code.
+
+## Inputs to confirm
+- Whether tracing should cover agents only, or also orchestrators and workflows
+- Which OTLP endpoint and service name should be used
+- Whether prompt/response content may be captured safely
+- Whether metrics are needed or traces alone are sufficient
+
+## Pattern 1: Environment-First Auto-Instrumentation
+
+Set environment variables before the first `agentbyte` import.
+
+```python
+import os
+
+os.environ["AGENTBYTE_ENABLE_OTEL"] = "true"
+os.environ["OTEL_EXPORTER_OTLP_ENDPOINT"] = "http://localhost:4318"
+os.environ["OTEL_SERVICE_NAME"] = "my-agentbyte-service"
+
+# Optional debugging / privacy-sensitive flags
+os.environ["AGENTBYTE_OTEL_CAPTURE_CONTENT"] = "false"
+os.environ["OTEL_METRICS_ENABLED"] = "false"
+
+from agentbyte import Agent
+```
+
+This is the preferred path because importing package root already triggers Agentbyte's OTel auto-instrumentation when `AGENTBYTE_ENABLE_OTEL=true`.
+
+What auto-instrumentation gives you:
+- agent root spans
+- child `chat <model>` spans
+- child `tool <name>` spans
+- orchestration root spans
+- workflow root and workflow-step spans
+
+## Pattern 2: Manual Agent Middleware
+
+Use this only when you do not want global auto-instrumentation and need opt-in tracing on specific agents.
+
+```python
+from agentbyte import Agent
+from agentbyte.middleware import OTelMiddleware
+
+agent = Agent(
+    name="traced_agent",
+    ...,
+    middlewares=[OTelMiddleware()],
+)
+```
+
+## What Gets Traced
+
+### Agents
+- root span: `agent <name>`
+- child spans for model calls
+- child spans for tool calls
+
+### Orchestrators
+- root span: `orchestration <PatternName>`
+- span attributes such as:
+  - `agentbyte.orchestration.pattern`
+  - `agentbyte.orchestration.agent_count`
+  - `agentbyte.orchestration.iterations`
+  - `agentbyte.orchestration.message_count`
+  - `agentbyte.orchestration.stop_reason`
+
+### Workflows
+- root span: `workflow <workflow_name>`
+- child spans: `workflow step <step_id>`
+- embedded `AgentbyteAgentStep` executions can contain nested agent/chat/tool spans beneath the workflow step span
+
+## Jaeger / OTLP Setup
+
+For local Jaeger all-in-one, use an OTLP HTTP endpoint such as:
+
+```python
+os.environ["OTEL_EXPORTER_OTLP_ENDPOINT"] = "http://localhost:4318"
+```
+
+Agentbyte appends `/v1/traces` internally for the trace exporter, so pass the base OTLP endpoint, not the full traces path.
+
+## Useful Environment Variables
+
+| Variable | Purpose |
+|---|---|
+| `AGENTBYTE_ENABLE_OTEL` | Enable Agentbyte tracing |
+| `OTEL_EXPORTER_OTLP_ENDPOINT` | Base OTLP HTTP endpoint |
+| `OTEL_SERVICE_NAME` | Service name shown in traces |
+| `OTEL_METRICS_ENABLED` | Enable metrics export when supported |
+| `AGENTBYTE_OTEL_CAPTURE_CONTENT` | Opt in to prompt/response content capture |
+
+## Validation Approach
+- Run a simple traced agent first to verify exporter setup.
+- Then verify orchestrator/workflow traces if those surfaces are in scope.
+- Check the trace hierarchy, not just whether any span appears.
+- For local Jaeger setups, confirm the service name is visible in the UI before debugging deeper instrumentation issues.
+
+## Guardrails
+- Set OTel environment variables before the first `agentbyte` import.
+- Prefer auto-instrumentation unless you specifically need per-agent manual control.
+- Treat `AGENTBYTE_OTEL_CAPTURE_CONTENT` as opt-in only; it may expose sensitive prompts, completions, or tool arguments.
+- Do not assume Jaeger supports metrics by default; traces are the primary integration path.
+- If local proxy settings interfere with `localhost`, clear or bypass them for the OTLP endpoint.

{agentbyte-0.4.3 → agentbyte-0.4.6}/.github/skills/agentbyte-plan-based-orchestration/SKILL.md

@@ -6,11 +6,24 @@ license: MIT
 
 Use this skill when implementing multi-agent collaboration with an explicit plan up front, step-by-step execution, evaluator-driven retries, and focused context per step.
 
+## Inputs to confirm
+- Which specialist agents should be available to the planner
+- Whether review steps need explicit approval gating
+- Whether the default recent `messages` history is sufficient for step execution
+- How many retries and review-revision loops are acceptable
+
 ## Pattern: Basic Plan-Based Orchestration
 
 ```python
 import asyncio
-from agentbyte import Agent, PlanBasedOrchestrator, UserMessage
+from agentbyte import (
+    Agent,
+    AgentHistoryPolicy,
+    HistoryContextPolicy,
+    PlanBasedOrchestrator,
+    ReviewGatePolicy,
+    UserMessage,
+)
 from agentbyte.llm import OpenAIChatCompletionClient
 from agentbyte.termination import MaxMessageTermination
 
@@ -58,7 +71,21 @@ async def main():
         model_client=client,     # Required: used for planning and evaluation
         max_iterations=10,       # Safety limit for total agent turns
         max_step_retries=2,      # Retry failed steps with evaluator feedback
-        recent_messages_limit=5, # Focus context on the latest shared history
+        history_policy=HistoryContextPolicy(
+            default=AgentHistoryPolicy(
+                window="recent",
+                message_limit=5,
+                format="messages",
+            )
+        ),
+        review_gate_policy=ReviewGatePolicy(
+            enabled=True,
+            reviewer_agent_name="reviewer",
+            revision_agent_name="writer",
+            approval_signal="APPROVED",
+            max_revision_rounds=2,
+            prefer_final_result_from_agent="writer",
+        ),
     )
 
     # 4. Run the task
@@ -134,19 +161,36 @@ class StepProgressEvaluation(BaseModel):
     suggested_improvements: list[str]
 ```
 
-## Configuration Options
+## Policy Surface
 
 ```python
 orchestrator = PlanBasedOrchestrator(
-    agents=[agent1, agent2, agent3],  # Required: specialist agents
-    termination=termination_condition, # Required: stop condition
-    model_client=planner_client,       # Required: plan + evaluation model client
-    max_iterations=50,                 # Optional: total agent-turn safety limit
-    max_step_retries=3,                # Optional: retries per failed step
-    recent_messages_limit=5,           # Optional: focused context window
+    agents=[agent1, agent2, agent3],
+    termination=termination_condition,
+    model_client=planner_client,
+    max_iterations=50,
+    max_step_retries=3,
+    history_policy=HistoryContextPolicy(
+        default=AgentHistoryPolicy(
+            window="recent",
+            message_limit=5,
+            format="messages",
+        )
+    ),
+    review_gate_policy=ReviewGatePolicy(enabled=False),
 )
 ```
 
+Use the two policies for different concerns:
+- `HistoryContextPolicy`: contains a default `AgentHistoryPolicy` plus optional per-agent `AgentHistoryPolicy` overrides for step execution
+- `ReviewGatePolicy`: controls explicit approval gating, revision loops, approval signals, and preferred final-result agent
+
+`AgentHistoryPolicy` is the per-agent rule that actually defines:
+- `window`
+- `message_limit`
+- `format`
+- `include_turn_prompt`
+
 ## Pattern Metadata
 
 After completion, `result.pattern_metadata` contains plan-aware state such as:
@@ -160,6 +204,8 @@ After completion, `result.pattern_metadata` contains plan-aware state such as:
 - `planner_model`: Model name used for plan/evaluation calls
 - `planner_calls`: Number of planning calls made
 - `evaluation_calls`: Number of step evaluations made
+- `history_policy`: Serialized step-execution history policy
+- `review_gate_policy`: Serialized review-gate configuration
 
 ## Usage Tracking
 
@@ -184,10 +230,11 @@ This makes plan-based orchestration more expensive than simpler patterns, but mu
 
 - **Model Client Required:** `PlanBasedOrchestrator` requires `model_client` for both plan generation and step evaluation.
 - **Agent Names Must Match:** `PlanStep.agent_name` must match an actual agent name. Matching is case-insensitive, but the name still has to exist.
+- **Review Gate Validation:** If `ReviewGatePolicy.enabled=True`, the configured reviewer and revision agent names must exist in the orchestrator pool.
 - **Descriptions Matter:** Agent descriptions should clearly state specialization because the planner uses them to assign steps.
 - **Termination Still Required:** Even though the pattern can stop when the plan completes, still provide a real termination condition as a safety boundary.
 - **Retries Are Bounded:** Use `max_step_retries` to keep failed steps from looping forever.
-- **Focused Context:** Plan-based orchestration intentionally sends only recent shared context plus the current step task. Do not assume every step sees the full history.
+- **Focused Context:** By default plan-based orchestration sends only recent shared context plus the current step task. This is configurable via `HistoryContextPolicy`.
 - **Fallback Behavior Exists:** If structured planning or evaluation fails, the orchestrator falls back to safe default behavior instead of crashing.
 
 ## Common Use Cases