EdgeChains VS awesome-ai-agents

We build a WASM compiler to compile our prompts and chains into webassembly. Honojs was a critical part of it.

https://github.com/arakoodev/EdgeChains/

EdgeChains: github.com/arakoodev/EdgeChains

would love your thoughts on this as well - https://github.com/arakoodev/edgechains

got frustrated in the same way with "Black Box Prompting - every library hides prompts/chains in layers of libraries...while it should have been declarative.

EdgeChains - allows u to specify ur prompt and chain in jsonnet. This why i think Generative AI needs declarative orchestration and not previous generations. https://github.com/arakoodev/edgechains#why-do-you-need-decl...

when will you have pgvector as a destination ? we (https://github.com/arakoodev/edgechains) work with a lot of enterprises and they would not move away from using redis or pgvector even as their vector store. Is there a way where we can leverage that ?

Second, for a LOT of enterprises, they want to use non-openai embedding models (minilm, GTE, BGE), will you support that. For e.g. in Edgechains we natively support BGE and minilm. Would you be able to support that ?

oh really ? Thats awfully kind. I'll take that in for EdgeChains as well.

https://github.com/arakoodev/EdgeChains/issues/172

Promptfile is written in markdown, which is unsuited for templates and config management.

I have an attempt in the same domain, would love feedback

We didnt invent a new markup - we used jsonnet which is used in large scale kubernetes and has a grammar that has been well tested for config mgmt.

https://github.com/arakoodev/EdgeChains/blob/main/Examples/r...

Prompts live outside the code.

# TODO: Get your Groq AI API key from https://console.groq.com/ GROQ_API_KEY = "" # TODO: Get your E2B API key from https://e2b.dev/docs E2B_API_KEY = "" # Or use 8b version # MODEL_NAME = "llama3-8b-8192" MODEL_NAME = "llama3-70b-8192" SYSTEM_PROMPT = """you are a python data scientist. you are given tasks to complete and you run python code to solve them. - the python code runs in jupyter notebook. - every time you call `execute_python` tool, the python code is executed in a separate cell. it's okay to multiple calls to `execute_python`. - display visualizations using matplotlib or any other visualization library directly in the notebook. don't worry about saving the visualizations to a file. - you have access to the internet and can make api requests. - you also have access to the filesystem and can read/write files. - you can install any pip package (if it exists) if you need to but the usual packages for data analysis are already preinstalled. - you can run any python code you want, everything is running in a secure sandbox environment""" tools = [ { "type": "function", "function": { "name": "execute_python", "description": "Execute python code in a Jupyter notebook cell and returns any result, stdout, stderr, display_data, and error.", "parameters": { "type": "object", "properties": { "code": { "type": "string", "description": "The python code to execute in a single cell.", } }, "required": ["code"], }, }, } ]

Hey everyone! I'm the CEO of the company that built this SDK.

We're a company called E2B [0]. We're building and open-source [1] secure environments for running untrusted AI-generated code and AI agents. We call these environments sandboxes and they are built on top of micro VM called Firecracker [2].

You can think of us as giving small cloud computers to LLMs.

We recently created a dedicated SDK for building custom code interpreters in Python or JS/TS. We saw this need after a lot of our users have been adding code execution capabilities to their AI apps with our core SDK [3]. These use cases were often centered around AI data analysis so code interpreter-like behavior made sense

The way our code interpret SDK works is by spawning an E2B sandbox with Jupyter Server. We then communicate with this Jupyter server through Jupyter Kernel messaging protocol [4].

We don't do any wrapping around LLM, any prompting, or any agent-like framework. We leave all of that on users. We're really just a boring code execution layer that sats at the bottom that we're building specifically for the future software that will be building another software. We work with any LLM. Here's how we added code interpreter to the new Llama-3 models [5].

Our long-term plan is to build an automated AWS for AI apps and agents.

Happy to answer any questions and hear feedback!

[0] https://e2b.dev/

[1] https://github.com/e2b-dev

[2] https://github.com/firecracker-microvm/firecracker

[3] https://e2b.dev/docs

[4] https://jupyter-client.readthedocs.io/en/latest/messaging.ht...

[5] https://github.com/e2b-dev/e2b-cookbook/blob/main/examples/l...

github.com/awesome-ai-agents

Github: https://github.com/e2b-dev/awesome-ai-agents and https://github.com/EmbraceAGI/Awesome-AGI