Depending on what side you're on and "only time will tell."
We’re not really seeing any significant development with this. What LLMs need most desperately (and are far from getting) is reliability and not being convincing liars. Being able to query existing server models from your oven timer is a cool gimmick but not really transformative or advancing anything.
It’s like a reverse JFK Space Effort speech: “We choose to indiscriminately throw at the wall every single LLM-adjacent idea we can think of. Not because it is useful, but because it is easy and potentially profitable”.
https://chatgpt.com/share/68679564-6a44-8012-b1bd-25819bfbf0...
Why would you need WASM for this?
Surely that's a prime use for AI?
For example in the next few years if Operating System companies and PC producers make small local models stock standards to improve the operating system functions and other services. This local LLM engine layer can be used by browser applications too and that being done through WASM without having to write Javascript and using WASM sandboxed layer to safely expose the this system LLM Engine Layer.
> The agent code is nothing more than a Python script that relies on the openai-agents-python library to run an AI agent backed by an LLM served via an OpenAI-compatible API.
The openai-agents-python code is useful for writing agents but it is possible to use it to write code that isn't very agentic. None of the examples are very agentic.
I'd like to offer a less skeptical view on this, contrary to what I've read here so far. LLMs that act (a.k.a. agents) bring a whole lot of new security and privacy issues. If we were already heading toward a privacy dystopia (with trackers, centralized services, etc.), agents could take that to a whole new level.
That's why I can only cheer when I see a different path where agents are run locally (by the way, Hugging Face has already published a couple of spaces demonstrating that). As a plus, because they're small, their environmental footprint will also be smaller (although, admittedly, I can also see the Jevons Paradox possibly happening here too).
we hook into the android workmanager framework and do some quirky things with tab handling to make this work. its harder to do this on mobile than on desktop.
bunch of people are trying to do interesting things like an automatic labubu purchase agent (on popmart) :D lots of purchase related agents
pull requests welcome ! https://github.com/wootzapp/wootz-browser/pull/334
Also, connecting a model to a bunch of tools and dropping it into some kind of workflow is maybe 5% of the actual work. The rest is spent on observability, background tasks, queueing systems, multi-channel support for agents, user experience, etc., etc., etc.
Nobody talks about that part, because most of the content out there is just chasing trends - without much real-world experience running these systems or putting them in front of actual customers with real needs.
https://huggingface.co/spaces/webml-community/llama-3.2-webg...
I can't run it on Linux since WebGPU is not working for me...
Sure, but there are a ton of ways for doing that today. What this specific thing is addressing, is removing the requirement of "the dependency on extra tools and frameworks that need to be installed before the agents can be run".
WASIp3[1] is gonna be awesome. Hopefully releasing later this year.
That library defines an agent as a system prompt and optional tools - notable because many other common agent definitions have the tools as required, not optional.
That explains why their "hello world" demo just runs a single prompt: https://github.com/mozilla-ai/wasm-agents-blueprint/blob/mai...
We built CodeRunner (https://github.com/BandarLabs/coderunner) on top of Apple Containers recently and have been using it for sometime. This works fine but still needs some improvement to work across very arbitrary prompts.
This is also not Gemini-cli specific and you could use the sandbox with any of the popular LLMs or even with your local ones.
raybb•6h ago
ape4•5h ago