whether future BAML language features might support dynamic injection of tool schemas without disrupting prefix caching

hmm interesting

Let me give you an example, hold on. Currently, I think this is a significant gap in BAML's support for agents

this is actually a very very well-written proposal. i don't know if that's the exact syntax we can use but i now see the idea of what you mean. you basically want to only show certain tools in the first ctx output format but then want a way to inject more types later on to keep the prompt stable. makes sense. let me think about it a little bit more.

@Vaibhav (BAML 🐑) Now I have abandoned the typebuilder approach and switched to using the code mode approach to avoid breaking prefix caching. By using the general-purpose tool.search and tool.describe to return new code mode functions, and then letting the orchestration function write scripts instead of dynamically injecting new BAML schemas, I found that this approach has a very low probability of parsing errors and is much more stable.

That’s good to know. I think it’s going to be in line with BEP 66 (https://beps.boundaryml.com/beps/66) specifically reflect.compile

Hey @vEth ,i've been poking around how to do code mode in BAML as well - so have you implement baml tools (tool.search / describe) on your own, then execute that in your own QuickJS-style execution enviornment? or is there something more out of the box that you're doing

I implemented the BAML tool, but I tried multiple JS runtimes, including quickJS, SES/Endo runtime, and even Bun. My goal is to run CodeMode directly on Vercel. If you want to push the tool list to the package level, rather than maintaining all tools entirely by yourself, you might consider using Bun.

Ahh I see ok thanks for the context!