Last updated: July 23, 2026
Migration map
New integrations should use POST /v1/agents/run for execution, POST /v1/agents/create for definitions, and POST /v1/models/completions for direct model calls—keeping auth headers stable.
Legacy /assistant_* routes remain mounted for backward compatibility, but they do not represent the preferred contract for new enterprise workloads. The /v1 surface inherits current RBAC, governed requests, and routing.
Run agents
Prefer POST /v1/agents/run over legacy assistant chat for new execution flows.
Create agents
Use POST /v1/agents/create for the control-plane definition flow.
Call models
Use POST /v1/models/completions when you need completion rather than an agent run.
Compatibility-first sequence
Inventory legacy calls, migrate execution to /v1/agents/run, validate streaming and tools in staging, then retire assistant routes only when client and server behavior match.
Step through each client: list, update, delete, and chat flows. Keep existing X-Kimss-Key or bearer authentication. Use the SDK conversation_id for continuation even when historical concepts referenced thread_id.
Verify usage attribution and error handling in a non-production workspace before cutover. Not every legacy management endpoint has a one-for-one public SDK wrapper—consult /docs/api_docs.
Client alignment
Keep the OpenAI or Anthropic client you already ship. Point it at the Kimss gateway and send X-Kimss-Agent-Id. New Python agents use Kimss Forge.
Follow /docs/route_traffic. Do not pip install kimss or add com.kimss:kimss-java for this migration. Coding agents fetch the control-plane contract at github.com/kimss-ai/kimss-control-plane.
Rollout communication
Tell internal consumers the deprecation timeline, which environments still accept assistant_* calls, and where to report parity gaps before you disable legacy paths.
Track progress in your changelog and link teams to /enterprise-ai-control-plane for architectural context. Published Kimss updates appear at /changelog.