yup. there are two differences - we model prompts AND chains (the looping logic) as a config management problem. So we model it in jsonnet and then compile it to wasm as a deployment step. The rest of everything we do is javascript and api-centric. In that way, we are solving a DX (or a developer UX problem) if you will.

AICI takes a more abstract approach here - first everything not related to prompt or token compilation is out of scope. So your api is not wasm-ed. Second, the job of creating the wasm prompts is your responsibility - use what you will. While we fundamentally try to answer the question "how can prompts and chains be expressed in a WASM friendly way without locking urself to the language and having it as a config"