Agent lifecycle service for the Agent Platform: creates, updates, deletes and inspects agents as Flux HelmReleases of the Generic agent chart, pins every skill to a commit or a digest, validates the values against the chart's schema before anything is applied, reads readiness from the platform Harness's status on the template, and lists the ModelConfigs and skills an agent can be built from. The API is served as REST/JSON (portal) and as MCP tools (muster) from one process.
Agent-manager defines 9 tools with consistent verb-noun naming (create_agent, update_agent, delete_agent, get_agent, list_agents, get_agent_status, list_skills, list_model_configs, validate_toolset). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas are present with typed parameters and descriptions. However, output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling is absent from descriptions. No enum constraints on string parameters (e.g., 'modelConfig' accepts free-form strings). Parameter descriptions lack format/constraint details (e.g., 'name' says 'DNS-1123 label of at most 63 characters' but no regex pattern). Destructive tools (delete_agent) lack confirmation/dry-run guidance. No pagination documented for list_* tools despite potential for large result sets.
Create a new agent as a Flux HelmRelease with validated values against the chart's schema
Delete an agent and its associated Flux HelmRelease
Retrieve details of a specific agent including its status and configuration
Get the readiness status of an agent from the platform Harness
List all agents in a namespace or across managed namespaces
List available model configurations for agents
List available skills from configured GitHub repositories
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects) for downstream tool chaining or data extraction. create_agent, update_agent, get_agent, list_agents, get_agent_status, list_skills, list_model_configs all lack return type documentation.
list_* tools (list_agents, list_skills, list_model_configs) lack pagination parameters (limit, offset/cursor) and total count in response. Large result sets will blow context window and degrade LLM reasoning.
delete_agent lacks confirmation/dry-run guidance in description. Destructive operations should support a confirmation step to prevent accidental data loss when agents make mistakes.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Update an existing agent's configuration, skills, toolset, and other properties
Validate a toolset declaration against the inline grammar
String parameters accept free-form values without enum constraints. 'modelConfig' and 'toolset' selectors (preset:<name>, server:<name>, workflow:<name>, tool:<name>) should declare valid formats or enums to prevent hallucinated values.
Parameter descriptions lack actionable format/constraint details. 'name' states 'DNS-1123 label of at most 63 characters' but no regex pattern. 'skills' and 'toolset' arrays lack item type/format specs. LLMs cannot validate inputs without explicit constraints.