11–16 of 16 posts
Nice work. Thanks for sharing it! I've been thinking about using something like this for LLM agent workflows - the outbound action pattern would work well for tool calls that need to wait on external APIs. I'm working on DSPy.rb [1] and this could pair nicely for multi-step reasoning chains. Curious - any plans for async gem support? [1] https://oss.vicente.services/dspy.rb/
Nice work. Thanks for sharing it! I've been thinking about using something like this for LLM agent workflows - the outbound action pattern would work well for tool calls that need to wait on external APIs. I'm working on DSPy.rb [1] and this could pair nicely for multi-step reasoning chains. Curious - any plans for async gem support? [1] https://oss.vicente.services/dspy.rb/
How does DSPy.rb differ from BAML?
DSPy is a programming paradigm. I like to look at it like the MVC for the Web. You define Signatures[0]: typed contracts governing the relationship between your models and your app. Signatures model prompts as functions too, without leaving Ruby. Then compose them into modules (Predict, ChainOfThought, ReAct, your own). The framework can automatically optimize prompts based on your metrics.
DSPy.rb brings the DSPy paradigm's tooling (optimizers, evaluation loops) to Ruby. Comes with OpenTelemetry OOTB. It also borrows BAML's schema format for 85% token savings vs JSON Schema in complex signatures. [1]
Everyone is talking about prompt, context, and harness engineering -and I agree they are good ways to frame how to build workflows and agents- this is just programming really.
[0] https://oss.vicente.services/dspy.rb/core-concepts/signature...
[1] https://oss.vicente.services/dspy.rb/articles/baml-schema-fo...
Seems pretty similar to https://github.com/radioactive-labs/chrono_forge which is what I found when I typed in "rails durable execution patterns" into Google. Have you seen this and if so, how do you think it compares?
Nice work. Thanks for sharing it! I've been thinking about using something like this for LLM agent workflows - the outbound action pattern would work well for tool calls that need to wait on external APIs. I'm working on DSPy.rb [1] and this could pair nicely for multi-step reasoning chains. Curious - any plans for async gem support? [1] https://oss.vicente.services/dspy.rb/
Congratulations on shipping this, I’m sure folks will find it useful! The rails native way to do this is to track state in a db row and queuing “next step” jobs as the data changes. This can get verbose especially for smaller pass/fail workflows. However, I find this works better (not worse imo) in more complex workflows as the state is tracked, queryable, can be surfaced in UIs, and resumed “manually” in the event o…
Nice work. Thanks for sharing it! I've been thinking about using something like this for LLM agent workflows - the outbound action pattern would work well for tool calls that need to wait on external APIs. I'm working on DSPy.rb [1] and this could pair nicely for multi-step reasoning chains. Curious - any plans for async gem support? [1] https://oss.vicente.services/dspy.rb/
Not sure how async gem would fit into this. The backbone of Stepped Actions is ActiveJob which handles execution. Where do you think this would fit in?