planning: Cortex API supports `/assistants`

[dan-homebrew]

Goal

• Cortex should support the Assistants API and implement underlying data structures
  • cortex.db has Assistants table
  • assistant.yaml
• Linked: https://github.com/janhq/jan/issues/3909

[dan-homebrew]

@namchuai @louis-jan For migration of Assistant, I think we can scope it down into two things:

Legacy "Assistants"

• For legacy assistants, I think we should follow the strategy in /threads
• v1 assistants should be handled by v1 thread.json assistants, and not exposed via API

Legacy Retrieval Tool

I would like to understand the possible approaches for us to handle this:

• Option 1: Maintain as a legacy Retrieval tool (eg have a legacy API handler in Cortex)
• Option 2: Migrate files, vector DB to Cortex?

I think it is easier for us to scope this to having legacy handlers and focus specifically on migration. With system stability, it is the possible for us to use v2 API handlers to build proper APIs, which will handle new Threads, Assistants and Tools

[dan-homebrew]

@louis-jan @namchuai While this ticket is for a v1 of Assistants, I think we should project forward to the likely roadmap for Assistants:

• Are we able to implement Assistants using an existing framework?
  • e.g. Assistants have type, e.g. Langchain or LlamaIndex
  • e.g. Assistants implement Tools differently based on type, e.g. https://python.langchain.com/v0.1/docs/modules/agents/

We should evaluate this; if it is too messy or difficult to align with an OpenAI-compatible API, I am open with also just going with our own (e.g. Runs, etc).