I think before going on with Agent #6 since I don't have really good usecase so far, working on conversation chain with tools access may be can be a good stepping stone.
Let's explore how it will looks like to have a conversation chain with access of tools, this will not only evolve the chain but also tools and retrieval in general.

Many interesting question :

1. Should tools interface compatible with retrieval?
2. Should retrieval can be used directly as a tool?
3. Or maybe we need to create a retrieval tool where it consume a retrieval and give user opportunity to put definition by them selves?

On LangChain there is the kwargs where it's passed from front to back, with the nature of Python's dynamic typing this kwargs can be reused by many layers from agent, to chain until model.
However, to have an idiomatic Go developer experience, that model is not ideal. If we talk about the perfect way, it should use a functional option pattern.

Need more research on how this model will looks like.

Need to investigate if elastic support dynamic dimension, if yes we may not need to do this

In LangChain there's tracing functionality where we can see all the LLM invocation and use it to debug the implementation.

This functionality will be useful to have, however the API of langchain-server is opaque. I don't know where to get the source of it or any possibility to reuse it.
I would love to reuse any available tracer and UI, one idea is probably to use OpenTelemetry. I don't think it has proper UI for development need.

For implementation detail, we can use callback.

Langchain has this concept of an agent, which gives Model access to a wide range of functionality or what it calls tools.

Supporting Agent is obviously a must, however, the implementation in Langchain is not easy to follow. I feel like there's need to simplify the way the agent works and we can probably also use this opportunity to use openAI function call to describe the tools instead.

Today vector store search function will still do vector based search to the database. Instead of having vector parameter, it has string based parameter which will be converted to vector later.

Is it better for search to do a nonvector search instead if applicable?
do we need an extra option for this? what will be the default behavior?

How about hybrid search?