3 ms·
1. Yes! This is useful for parsing unstructured data or inferring an argument (sometimes we can simply define a static data transformation through jq). 2. Anyt
by samuelbrashears 3y ago
1. Yes! This is useful for parsing unstructured data or inferring an argument (sometimes we can simply define a static data transformation through jq).
2. Anything too complex (e.g. 5+ steps) tends to be unreliable. Also, any workflow where potential failure/unexpected behavior is too risky to leave up to an LLM.
3. The only actions we take are with our user's tools, so many workflows are simply organizing their information between their apps. However, e.g. gmails could be sent externally so we have guardrails/sanity checks to mitigate risk there.
- thoughtlede 3y agoThanks. What happens right now when the workflow fails mid-way? Do you ensure atomicity or durable execution?
- samuelbrashears 3y agoWe do a fixed number of retries, including redoing any AI arguments. We've thought about making it atomic/more durable -- it's tricky, given that most steps interact with external systems e.g. Google Sheets, and while not typically "destructive" (Google Sheets has version history), undo-ing is often difficult.
- thoughtlede 3y agoYeah. Rollbacks or reruns are hard when dealing with external systems. Actions need to be idempotent for reruns to work. One thing you may focus on is making workflows more durable: Checkpointing and sending to users summaries of last checkpoints when things fail. The last thing you want a non-tech user (your target customer) is to figure out what’s the state of a failed workflow.
- samuelbrashears 3y agoGreat idea -- we're looking at showing workflow history and this is a good addition.