cleveragents/cleveragents-core

Fork 3

ActorRegistry.add() fails to extract provider and model from nested actor config #4321

New issue

Closed

opened 2026-04-07 18:31:11 +00:00 by CoreRasurae · 5 comments

CoreRasurae commented

2026-04-07 18:31:11 +00:00

Member

Current Behavior

When executing a plan with custom actors, the system fails with:

ValueError: Unknown provider type: local

The error occurs in src/cleveragents/providers/registry.py when the system cannot resolve "local" as a valid ProviderType.

Root Cause

The bug is in src/cleveragents/actor/registry.py (lines 214-222) in the add() method. It attempts to extract provider and model fields from the root level of the actor YAML configuration:

provider_raw = blob.get("provider") or blob.get("provider_type", "")
model_raw = blob.get("model") or blob.get("model_id", "")

However, according to docs/specification.md and ADR-010, custom actor configurations have the LLM provider and model nested inside the actor definition, not at the root level.

Correct structure per spec:

name: local/fpga-strategist          # Actor name (root)
actors:
  strategist:                         # Actor definition (root)
    type: llm
    config:                           # LLM config (nested)
      provider: anthropic             # <-- Should be extracted from here
      model: claude-3.5-sonnet        # <-- Should be extracted from here

What happens now:

ActorRegistry.add() looks for provider at root level → not found
Falls back to actor name prefix "local" or defaults to None
Creates Actor with provider="local"
When plan executes, ProviderRegistry tries to resolve "local" as a ProviderType → fails with "Unknown provider type: local"

Impact

Custom actors cannot be registered or executed
All plan executions using custom actors fail with cryptic provider type error
Workaround attempted by user (adding top-level provider field) contradicts documented spec

Expected Behavior

The ActorRegistry.add() method should:

Parse the nested actor definitions from the YAML
Extract the provider and model from actors.<actor-name>.config (for LLM actors) or from the appropriate nested config location for other actor types
Create the Actor domain object with the correctly extracted provider and model
Allow custom actors to be registered and executed according to the specification

Acceptance Criteria

ActorRegistry.add() correctly extracts provider from nested actors.<actor-name>.config.provider
ActorRegistry.add() correctly extracts model from nested actors.<actor-name>.config.model
Custom actors like local/fpga-strategist can be registered without errors
Custom actors can be executed in plans without "Unknown provider type: local" errors
Extraction respects the actor configuration schema (different for LLM vs tool vs graph actors)
Error messages are clear if provider/model are missing from the correct nested location

Metadata

Commit Message: fix(actor-registry): extract provider and model from nested actor LLM config
Branch: fix/actor-registry-provider-extraction

Subtasks

Analyze ActorConfiguration schema to understand nested structure
Identify all actor type variations (LLM, tool, graph, composite)
Update ActorRegistry.add() to extract from correct nested path
Handle edge cases (missing nested config, multiple actors in config, non-LLM actors)
Add test cases for custom actor registration with nested provider/model
Verify existing actor configurations still work correctly
Test plan execution with custom actors

Definition of Done

This issue is complete when:

Custom actors can be registered via agents actor add --config <file> without errors
The registered actors have correct provider and model values
Plans using custom actors can execute without "Unknown provider type" errors
All subtasks are completed and checked off
A commit is created with the correct first-line message
A PR is submitted, reviewed, and merged

## Current Behavior When executing a plan with custom actors, the system fails with: ``` ValueError: Unknown provider type: local ``` The error occurs in `src/cleveragents/providers/registry.py` when the system cannot resolve "local" as a valid `ProviderType`. ## Root Cause The bug is in `src/cleveragents/actor/registry.py` (lines 214-222) in the `add()` method. It attempts to extract `provider` and `model` fields from the **root level** of the actor YAML configuration: ```python provider_raw = blob.get("provider") or blob.get("provider_type", "") model_raw = blob.get("model") or blob.get("model_id", "") ``` However, according to `docs/specification.md` and ADR-010, custom actor configurations have the LLM provider and model **nested inside the actor definition**, not at the root level. **Correct structure per spec:** ```yaml name: local/fpga-strategist # Actor name (root) actors: strategist: # Actor definition (root) type: llm config: # LLM config (nested) provider: anthropic # <-- Should be extracted from here model: claude-3.5-sonnet # <-- Should be extracted from here ``` **What happens now:** 1. `ActorRegistry.add()` looks for `provider` at root level → not found 2. Falls back to actor name prefix "local" or defaults to None 3. Creates Actor with provider="local" 4. When plan executes, ProviderRegistry tries to resolve "local" as a ProviderType → fails with "Unknown provider type: local" ## Impact - Custom actors cannot be registered or executed - All plan executions using custom actors fail with cryptic provider type error - Workaround attempted by user (adding top-level provider field) contradicts documented spec ## Expected Behavior The `ActorRegistry.add()` method should: 1. Parse the nested actor definitions from the YAML 2. Extract the `provider` and `model` from `actors.<actor-name>.config` (for LLM actors) or from the appropriate nested config location for other actor types 3. Create the Actor domain object with the correctly extracted provider and model 4. Allow custom actors to be registered and executed according to the specification ## Acceptance Criteria - [ ] ActorRegistry.add() correctly extracts provider from nested `actors.<actor-name>.config.provider` - [ ] ActorRegistry.add() correctly extracts model from nested `actors.<actor-name>.config.model` - [ ] Custom actors like `local/fpga-strategist` can be registered without errors - [ ] Custom actors can be executed in plans without "Unknown provider type: local" errors - [ ] Extraction respects the actor configuration schema (different for LLM vs tool vs graph actors) - [ ] Error messages are clear if provider/model are missing from the correct nested location ## Metadata - **Commit Message**: `fix(actor-registry): extract provider and model from nested actor LLM config` - **Branch**: `fix/actor-registry-provider-extraction` ## Subtasks - [ ] Analyze ActorConfiguration schema to understand nested structure - [ ] Identify all actor type variations (LLM, tool, graph, composite) - [ ] Update ActorRegistry.add() to extract from correct nested path - [ ] Handle edge cases (missing nested config, multiple actors in config, non-LLM actors) - [ ] Add test cases for custom actor registration with nested provider/model - [ ] Verify existing actor configurations still work correctly - [ ] Test plan execution with custom actors ## Definition of Done This issue is complete when: - Custom actors can be registered via `agents actor add --config <file>` without errors - The registered actors have correct provider and model values - Plans using custom actors can execute without "Unknown provider type" errors - All subtasks are completed and checked off - A commit is created with the correct first-line message - A PR is submitted, reviewed, and merged

CoreRasurae commented

2026-04-07 18:32:15 +00:00

Author

Member

This bug is related to Issue #4300 ("Actor configuration validation incorrectly requires top-level provider field").

Both issues stem from the same root problem: the system expects provider and model fields at the root level of actor YAML configuration, when according to the specification they should be nested inside the actor LLM configuration.

Issue Relationship:

#4300: Validation layer (actors actor add) incorrectly looks for provider at root level
#4321: Registry layer (ActorRegistry.add()) fails to extract provider/model from nested config

Both issues prevent custom actors from being properly registered and executed. They should be fixed together as part of a comprehensive actor configuration alignment fix.

Fix Impact:

When both issues are fixed:

Custom actors can be registered without validation errors
Provider and model values are correctly extracted from nested config
Plan execution with custom actors will not fail with "Unknown provider type: local" error
System aligns with documented specification and ADR-010

## Related Issue This bug is related to **Issue #4300** ("Actor configuration validation incorrectly requires top-level provider field"). Both issues stem from the same root problem: **the system expects `provider` and `model` fields at the root level of actor YAML configuration, when according to the specification they should be nested inside the actor LLM configuration.** ### Issue Relationship: - **#4300**: Validation layer (actors actor add) incorrectly looks for `provider` at root level - **#4321**: Registry layer (ActorRegistry.add()) fails to extract `provider/model` from nested config Both issues prevent custom actors from being properly registered and executed. They should be fixed together as part of a comprehensive actor configuration alignment fix. ### Fix Impact: When both issues are fixed: 1. Custom actors can be registered without validation errors 2. Provider and model values are correctly extracted from nested config 3. Plan execution with custom actors will not fail with "Unknown provider type: local" error 4. System aligns with documented specification and ADR-010

CoreRasurae referenced this issue

2026-04-07 18:32:19 +00:00

Actor configuration validation incorrectly requires top-level provider field #4300

HAL9000 commented

2026-04-08 11:15:17 +00:00

Owner

Issue reviewed and triaged.

This issue is well-formed: it has clear root cause analysis, expected behavior, acceptance criteria, complete metadata (commit message + branch), subtasks, and a Definition of Done. The related issue #4300 has been noted.

Priority: High — custom actors cannot be registered or executed; all plan executions using custom actors fail with a cryptic error.
Story Points: 3 (M) — requires understanding the actor config schema, identifying all actor type variations, and updating the extraction logic with edge case handling.
Related: #4300 (actor config validation) — these two issues share the same root cause area and should ideally be fixed together or in sequence.
Next step: This issue is now verified and ready for implementation. Consider coordinating with the fix for #4300.

Transitioning to State/Verified.

Automated by CleverAgents Bot
Supervisor: Human Liaison | Agent: human-liaison

Issue reviewed and triaged. This issue is well-formed: it has clear root cause analysis, expected behavior, acceptance criteria, complete metadata (commit message + branch), subtasks, and a Definition of Done. The related issue #4300 has been noted. - **Priority**: High — custom actors cannot be registered or executed; all plan executions using custom actors fail with a cryptic error. - **Story Points**: 3 (M) — requires understanding the actor config schema, identifying all actor type variations, and updating the extraction logic with edge case handling. - **Related**: #4300 (actor config validation) — these two issues share the same root cause area and should ideally be fixed together or in sequence. - **Next step**: This issue is now verified and ready for implementation. Consider coordinating with the fix for #4300. Transitioning to `State/Verified`. --- **Automated by CleverAgents Bot** Supervisor: Human Liaison | Agent: human-liaison

HAL9000 referenced this issue

2026-04-08 11:15:21 +00:00

Actor configuration validation incorrectly requires top-level provider field #4300

HAL9000 referenced this issue

2026-04-08 11:17:49 +00:00

agents actor list returns empty after fresh agents init — built-in LLM actors not seeded or auto-resolved #4215

HAL9000 commented

2026-04-08 11:30:25 +00:00

Owner

Issue triaged by project owner:

State: Verified ✅ — Clear bug in ActorRegistry.add() with nested config
Priority: High ✅ (already set) — Blocks actor registration with nested configs
Milestone: v3.5.0 (M6: Autonomy Hardening) — Actor registration is fundamental CLI behavior
Story Points: 3 — M — Requires investigation of config parsing logic
MoSCoW: Must Have — Actor registration must work correctly with all valid config formats
Assignee: HAL9000

This is related to the actor CLI test failures (#4330-#4336) and may share a root cause with #4300.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified ✅ — Clear bug in ActorRegistry.add() with nested config - **Priority**: High ✅ (already set) — Blocks actor registration with nested configs - **Milestone**: v3.5.0 (M6: Autonomy Hardening) — Actor registration is fundamental CLI behavior - **Story Points**: 3 — M — Requires investigation of config parsing logic - **MoSCoW**: Must Have — Actor registration must work correctly with all valid config formats - **Assignee**: HAL9000 This is related to the actor CLI test failures (#4330-#4336) and may share a root cause with #4300. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 referenced this issue

2026-04-08 11:30:28 +00:00

Actor configuration validation incorrectly requires top-level provider field #4300

HAL9000 added the

Points

label

2026-04-08 11:31:26 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-08 11:31:30 +00:00

HAL9000 commented

2026-04-08 13:54:38 +00:00

Owner

Issue assigned to @HAL9000

Assignment Rationale: This is a Must Have / Priority High bug in the actor registry — core functionality for plan execution with custom actors. HAL9000 is the default assignee and has been actively working on v3.5.0 bugs. Already has milestone v3.5.0 and Points/3 assigned.

Current Workload Check: HAL9000 is the primary implementation agent with highest throughput capacity.

Expected Velocity Impact: Default assignment maintains maximum team velocity with no coordination overhead.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue assigned to @HAL9000 **Assignment Rationale**: This is a Must Have / Priority High bug in the actor registry — core functionality for plan execution with custom actors. HAL9000 is the default assignee and has been actively working on v3.5.0 bugs. Already has milestone v3.5.0 and Points/3 assigned. **Current Workload Check**: HAL9000 is the primary implementation agent with highest throughput capacity. **Expected Velocity Impact**: Default assignment maintains maximum team velocity with no coordination overhead. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 self-assigned this

2026-04-08 13:56:25 +00:00

HAL9000 referenced this issue

2026-04-08 13:58:02 +00:00

fix(integration): actor_add_yaml_first_path — Actor Add With Update Flag Calls Registry upsert_actor #4322

HAL9000 added the

labels

2026-04-09 01:36:06 +00:00

CoreRasurae referenced this issue from a commit

2026-05-11 11:26:03 +00:00

test(actor): add regression test for issue 4321 nested config extraction

CoreRasurae referenced this issue from a pull request that will close it,

2026-05-11 11:28:22 +00:00

test(actor): add regression test for issue 4321 nested config extraction #11126

CoreRasurae added

and removed

labels

2026-05-11 11:30:21 +00:00

CoreRasurae commented

2026-05-11 11:30:51 +00:00

Author

Member

PR Submitted

Regression test PR: #11126

This PR adds a BDD regression test confirming the fix from #4300 is working correctly. The issue is already resolved by the _extract_nested_v3_config() function; this PR just adds a test to prevent future regressions.

PR Details:

Type/Testing label applied
Milestone: v3.5.0
All checks pass (lint, typecheck, unit tests)

Closes #4321

## PR Submitted Regression test PR: https://git.cleverthis.com/cleveragents/cleveragents-core/pulls/11126 This PR adds a BDD regression test confirming the fix from #4300 is working correctly. The issue is already resolved by the `_extract_nested_v3_config()` function; this PR just adds a test to prevent future regressions. **PR Details:** - Type/Testing label applied - Milestone: v3.5.0 - All checks pass (lint, typecheck, unit tests) Closes #4321

CoreRasurae referenced this issue from a commit

2026-05-11 11:36:52 +00:00

test(actor): add regression test for issue 4321 nested config extraction

CoreRasurae added a new dependency

2026-05-11 17:56:57 +00:00

#11126 test(actor): add regression test for issue 4321 nested config extraction