fix: widen provider type to SupportedProvider#158
Merged
Conversation
…torConfig/OrchestratorConfig `AgentConfig.provider`, `CoordinatorConfig.provider`, and `OrchestratorConfig.defaultProvider` were typed as a narrow 5-provider union (anthropic/copilot/grok/openai/gemini) while `createAdapter()` already accepts the full 8-provider `SupportedProvider` union (adds azure-openai/deepseek/minimax). This forced users to cast when passing valid providers. Widens the three fields to reference `SupportedProvider` directly. Fully additive: no narrowing of previously valid usage. Surfaced in #153 review (Engram integration example used `as AgentProvider` to work around the narrow type).
Agentscreator
added a commit
to Agentscreator/open-multi-agent
that referenced
this pull request
Apr 23, 2026
…m, orchestrated demo) - EngramMemoryStore: MemoryStore implementation backed by Engram REST API - EngramToolkit: registers engram_commit, engram_query, engram_conflicts, engram_resolve tools with a ToolRegistry - research-team.ts: standalone three-agent pipeline (researcher → fact-checker → writer) coordinating via Engram tools directly - team-research.ts: orchestrated demo using runTeam() with EngramMemoryStore plugged in as sharedMemoryStore, exercising the TeamConfig.sharedMemoryStore feature from open-multi-agent#157 Both demos support all 8 providers via AGENT_PROVIDER/AGENT_MODEL env vars. SupportedProvider imported from src/index.js (no local type alias or cast) per review feedback on open-multi-agent#157 and the type widening in open-multi-agent#158.
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Surfaced in #153 review (Engram integration example used
as AgentProviderto work around the narrow type).Summary
AgentConfig.provider,CoordinatorConfig.provider, andOrchestratorConfig.defaultProviderwere typed as a narrow 5-provider union ('anthropic' | 'copilot' | 'grok' | 'openai' | 'gemini') whilecreateAdapter()insrc/llm/adapter.tsalready accepts the full 8-providerSupportedProviderunion (addsazure-openai,deepseek,minimax). This forced users to cast when passing statically-valid providers.Changes
src/types.ts: three config fields now referenceSupportedProviderdirectly. One newimport typefrom./llm/adapter.js.Backward compatibility
Fully additive. Any code that compiled against the narrow 5-provider union still compiles; only previously-rejected valid providers now type-check without a cast.
Test plan
npm run lintpassesnpm testpasses (667/667; provider dispatch coverage via existingtests/{deepseek,minimax,grok,gemini,openai,anthropic,copilot}-adapter.test.tsandtests/azure-openai-adapter.test.ts)Follow-up
Once merged, #153 can drop the
as AgentProvidercast after rebase.