I recently gave a talk arguing that most companies don't actually need AI "agents" - they need workflows. The agent/workflow distinction has become one of the most confusing topics in AI engineering, since the "Building Effective Agents" blog from Anthropic: https://www.anthropic.com/engineering/building-effective-age....
My definition: An agent is a system where the LLM controls its own execution flow based on environmental feedback. Everything else (prompt chaining, routing, parallelization, orchestrator-worker) is a workflow, even if it uses LLMs.
The problem is the line is incredibly blurry. To illustrate this, I built an interactive quiz with 7 code examples that test your intuition on what's an agent vs workflow.
The community voting results are fascinating - even technical folks disagree on edge cases like "research agents" with only 3 predefined action types, or orchestrator-worker patterns where the LLM dynamically determines task structure.
The quiz shows live voting results, so you can see how your intuitions compare to others. Would love to hear HN's take - where do you draw the line?
Recently wrote a step-by-step guide using the open-source ZenML (Disclaimer: I'm the co-creator). Thought it covered some nice concepts and is OSS, so the HN community would appreciate. Peace!
Not at all harsh! Very valuable. Tbh it was really about just trying it out for now, its very arbitrary! :-) Do you have any suggestions on what exactly you'd like to do after you find out its Trending?
Wouldn't it make sense to decouple the orchestration later from the authoring layer for the dags? That way you could solve the authoring problems separately from the lower level orchestration problems. We're trying this over at ZenML (https://zenml.io) but have yet to get feedback
ZenML is hiring for a Design Engineer | Remote-friendly | Freelancer or Employee | Full-time or Part-time
ZenML is an extensible, open-source MLOps framework to create production-ready machine learning pipelines. Built for data scientists, it has a simple, flexible syntax, is cloud- and tool-agnostic, and has interfaces/abstractions that are catered towards ML workflows.
We’re looking for a Design Engineer with a multi-disciplinary skill-set who can take over the look and feel of the ZenML experience. ZenML is a tool designed for developers and we want to delight them from the moment they land on our web page, to after they start using it on their machines. We would like a consistent design experience across our many touchpoints (including the [landing page](https://zenml.io), the [docs](https://docs.zenml.io), the [blog](https://blog.zenml.io), the [podcast](https://podcast.zenml.io), our social media, the product itself which is a [python package](https://github.com/zenml-io/zenml) etc).
A lot of this job is about communicating complex ideas in a beautiful way. You could be a developer or a non-coding designer, full time or part-time, employee or freelance. We are not so picky about the exact nature of this role. If you feel like you are a visually creative designer, and are willing to get stuck in the details of technical topics like MLOps, we can’t wait to work with you!
Hey @sabalaba, that sounds pretty interesting. Would you be willing to integrate with ZenML? https://github.com/maiot-io/zenml . We're looking for solutions like that that have synergies
Yes this is aimed at being a simpler API rather than complicated one. Also MLFlow does not orchestrate self-starting preemptible instances, so you'd have to pay the full amounts.
Big fan of cortex and i'm also on its boards often :-)
However, this works without a Kubernetes cluster, while Cortex does not. A managed kubernetes cluster on GCP e.g. costs $100/month[1].AWS, Azure is similar. For bare-metal, self managed solutions, if you can manage a cluster on your own like that then yes there is no need for BudgetML :-)
OP here. Probably some form of container orchestration system like Kubernetes to manage the deployments + resources. There is also specialized ML tooling like Kubeflow to help out. Its still a developing landscape though.
We made BudgetML not to replace the above but to make it easy for scenarios where the need would be to just "get out there and deploy". Do you see value in that too?