https://www.boundaryml.com logo
Powered by
Why Bash Might Be Holding AI Agents Back
# general
v
Why Bash Might Be Holding AI Agents Back | Rhys Sullivan I watched this episode and was thinking about whether BAML 1.0 could be used to implement code mode. Simply put: BAML handles orchestration, and if code needs to be written, it generates BAML code, then through some method, calls the actual npm package or CLI.
v
that is one of the goals! especially with our updated eval constructs
v
I plan to start trying to implement it next week and use DS V4 Flash to generate BAML code.
Sharing some progress, I'm trying to develop a visual workflow using BAML combined with CodeMode to allow ordinary users to create workflows, with more user-friendly interaction and customization compared to low-code platforms like dify/n8n
Hi BAML team, we are building a user-facing workflow visualization on top of BAML workflows, and we would like to avoid vendoring the current playground WASM build. Would you consider publishing a stable npm package for the BAML playground/visualization runtime? Ideally it would expose APIs such as 
requestControlFlowGraph(project, functionName)
, stable TypeScript types for 
ControlFlowGraph
, 
RuntimeEvent
, and 
FetchLogEntry
, and a supported Node/browser WASM initialization path. If possible, it would also be very helpful to publish the same graph pipeline used by the playground, such as CFG-to-graph conversion, runtime-event-to-node-state mapping, and layout helpers. Our goal is to render official BAML workflow structure and runtime state without copying playground internals or committing third-party WASM binaries into our repository.
@Vaibhav (BAML 🐑)
v
hi @vEth sorry for the delay here!
we are thinking of how to make 2 things possible: 1. make the playground more extendable (with your custom visualizations) 2. make the playground embeddable so these are both on our roadmap!
v
@Vaibhav (BAML 🐑) One question we have is whether BAML has, or plans to support, a runtime lifecycle similar to a notebook/cell-based orchestration runtime: - execute a generated workflow/script as a long-running unit - yield control during execution - return a run/cell id - later wait/resume/terminate that run - emit structured runtime events during execution - support host-side approval/auth waits as first-class runtime states For context, we are comparing this with a V8-backed Code Mode design where the model writes orchestration code, the runtime executes it in an isolated cell, and the host can 
yield
, 
wait
, or 
terminate
the cell while tools continue to be mediated by host bindings. Does BAML 1.0 have anything like this runtime lifecycle on the roadmap? Or is BAML intended to stay focused on typed workflow definitions and function/tool orchestration, with durable execution, pause/resume, cancellation, and approval waits handled by the host application?
PreviousNext
Powered by