-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix agent scopes, and add documentation #45
Conversation
@raulraja I flattened the |
There is a distinction in libraries like langchain where agents have multiple running and execution policies, and that is the only difference. If we assume agents and tools are just functions and provide those behaviors through other means, such as retrying, and parallelizing, outside of the agent execution, then this is great. |
@nomisRev I think regarding the We don't need to worry about combining, adding, or removing vector stores from contexts if we have something with these capabilities. The context that wants to be isolated would create its own table if needed or use the global memory. This is related to the issue of long and short memory. Multiple agents may want to contribute to long-term memory for the entire ai block. In other use cases, agents or tools may want to have access to persistence but for a short period of time and then get rid of the memory when they are done. That ephemeral data while persisted or large may have only been relevant in the context of the agent run. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, @nomisRev, Looks great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nomisRev !
Currently the
agent
blocks were updating theAtomic
reference inside theAIScope
, this mean that agents could change during the execution of such a block.Since these blocks can be executed in parallel using
parMap
, or other concurrency operators. To prevent this I've scoped the lambdas toAIScope
which create a child scope with an updated agent parameter. This way the blocks are truly scoped.This PR also adds documentation to the current
AI
data type, and DSL.Discussion / future work
This brings to question what to do with
VectorStore
, should anagent(..) { }
block have it's own scopedVectorStore
whilst also having access to theVectorStore
of it's parent? We potentially have some kind-of factory to createVectorStore
and compose them together by query'ing both and aggregating the results.This brings to question to what to do with persistent vector stores like
Postgres
since all storage there is shared, and persisted across allai
calls and even multiple runs of the application. To avoid this we could create unique tables, which are destroyed at the end of anagent
block but I guess that defeats the purpose of having a persisted vector store?WDYT? @xebia-functional/team-ai