6 ms·

Building Effective AI Agents

543 points by Anon84 1y ago

spenczar5 1y ago
(December 2024, which somehow feels an eternity ago)
- nahsra 1y ago
  Yes, but it's held up really well in my opinion! I use this piece constantly as a reference and I don't feel it's aged. It reframed Anthropic as "the practical partner" in the development of AI tools.
- nico 1y ago
  > Nooooo I'm going to have to use my brain again and write 100% of my code like a caveman from December 2024 https://news.ycombinator.com/item?id=44260988 https://news.ycombinator.com/item?id=44260988
simonw 1y ago
This article remains one of the better pieces on this topic, especially since it clearly defines which definition of "AI agents" they are using at the start! They use: "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks". I also like the way they distinguish between "agents" and "workflows", and describe a bunch of useful workflow patterns. I published some notes on that article when it first came out: https://simonwillison.net/2024/Dec/20/building-effective-agents/ https://simonwillison.net/2024/Dec/20/building-effective-age... A more recent article from Anthropic is https://www.anthropic.com/engineering/built-multi-agent-research-system https://www.anthropic.com/engineering/built-multi-agent-rese... - "How we built our multi-agent research system". I found this one fascinating, I wrote up a bunch of notes on it here: https://simonwillison.net/2025/Jun/14/multi-agent-research-system/ https://simonwillison.net/2025/Jun/14/multi-agent-research-s...
- juddlyon 1y ago
  Thank you for the extra notes, this is top of mind for me.
- smoyer 1y ago
  The article on the multi-agent research is awesome. I do disagree with one statement in the building effective AI agents article - building your initial system without a framework sounds nice as an educational endeavor but the first benefit you get from a good framework is the easy ability to try out different (and cross-vendor) LLMs
  - miki123211 1y ago
    This is why you use a library (not a framework) that provides an abstraction over different LLMs. I'm personally a fan of litellm, but I'm sure alternatives exist.
  - XenophileJKO 1y ago
    Having built several systems serving massive user bases with LLMs. I think the ability to swap out APIs just isn't the bottleneck.. like ever. It is always the behavioral issues or capability differences between models. The frameworks just usually add more complexity, obscurity, and API misalignment. Now the equation can change IF you are getting a lot of observability, experimentation, etc. I think we are just reaching that point of utility where it is a real question whether you should use the framework by default. For example I build a first version of a product with my own java code hooking right into an API. I was able to deliver the product quickly with a clean architecture and observability, etc. Then once the internal ecosystem was aligned on a framework (on mentioned in the article) a team took up migrating it to python on the framework. It still isn't complete, it just introduces a lot of abstraction layers where you have to adapt them to your internal systems and your internal observability setup, and any other things that the rest of your applications do. People underestimate that cost. So by default to get your V0 product off the ground (if you are not a complete startup), just use the API. That is my advice.
    - 1y ago
gregorymichael 1y ago
One of my favorite AI How-tos in the last year. Barry and Erik spend 80% of the post saying ~”eh, you probably don’t need agents. Just build straightforward deterministic workflows with if-statements instead.” And then, when you actually do need agents, don’t over complicate it! This post also introduced the concept of an Augmented LLM — a LLM hooked up to tools, memory, data — which is a useful abstraction for evolving LLM use beyond fancy autocomplete. “An augmented LLM running in a loop” is the best definition of an agent I’ve heard so far.
suyash 1y ago
I think the Agent hype has come down now
- kevinventullo 1y ago
  Now it’s all about AI Agencies
revskill 1y ago
So an agent is just a monoid in the category of monads ?
AvAn12 1y ago
How do agents deal with task queueing, race conditions, and other issues arising from concurrency? I see lots of cool articles about building workflows of multiple agents - plus what feels like hand-waving around declaring an orchestrator agent to oversee the whole thing. And my mind goes to whether there needs to be some serious design considerations and clever glue code. Or does it all work automagically?
- cmsparks 1y ago
  Frankly, it's pretty difficult. Though, I've found that the actor model maps really well onto building agents. An instance of an actor = an instance of an agent. Agent to agent communication is just tool calling (via MCP or some other RPC) I use Cloudflare's Durable Objects (disclaimer: I'm biased, I work on MCP + Agent things @ Cloudflare). However, I figure building agents probably maps similarly well onto any actor style framework.
  - pyman 1y ago
    Should the people developing AI agent protocols be exploring decentralised architectures, using technologies like blockchain and peer-to-peer networks to distribute models and data? What are the trade-offs of relying on centralised orchestration platforms owned by large companies like Amazon, Cloudfare or NVIDIA? Thanks
    - daxfohl 1y ago
      That's more of a hobbyist thing I'd say. Corporations developing these things will of course want to use some centralized system that they trust. It's more efficient, they have more control over it, it's easier for average people to use, etc. A decentralized thing would be more for individuals who want more control and transparency. A decentralized public ledger would make it possible to verify that your agent, the agents it interacts with, and the contents of their interactions have not been altered or compromised in any way, whereas a corporate-owned framework could not provide the same level of assurance. But technically, there's no advantage I can think of for using a public distributed ledger to manage interactions. Agent tasks are pretty ephemeral, so unlike digital currency, there's not really a need to maintain a complete historical log of every action forever. And as far as providing tools for dealing with race conditions, blockchain would be about the least efficient way of creating a mutex imaginable. So technically, just like with non-AI apps, cetralized architecture is always going to be a lot more efficient.
deadbabe 1y ago
When an AI agents completes a task, why not have the AI agent save the workflow used to accomplish that task so the next time it sees a similar input it feeds it to a predefined series of tools to avoid any LLM decision making in between tool calls? And then eventually, with enough sample inputs, create simple functions that can recognize what tools should be used to process a type of input? And only fallback to an LLM agent if the input is novel?
- 0x457 1y ago
  You somewhat can do this. I use neo4j as a knowledge database for agents, and it has processes and tasks described.
iLoveOncall 1y ago
> These frameworks make it easy to get started by simplifying standard low-level tasks like calling LLMs, defining and parsing tools, and chaining calls together. However, they often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug. They can also make it tempting to add complexity when a simpler setup would suffice. > We suggest that developers start by using LLM APIs directly Best advice of the whole article by far. It's insane that people use whole frameworks to send what is essentially an array of strings to a webservice. We've removed LangChain and LangGraph from our project at work because they are literally worthless, just adding complexity and making you write MORE code than if you didn't use them because you have to deal with their whole boilerplate.
- fennecbutt 1y ago
  I suppose langflow also falls into this bucket. I still think it has a definite use case in regularising all of your various flows into a common format. Sure, I could write some code to get SD to do all the steps to generate an image, or write some shader code. But it's so much more organised to use comfy-UI, or a shader graph, especially if I have n>1 flows/tasks, and definitely while experimenting with what I'm building.
btbuildem 1y ago
> use simple, composable patterns It's somehow incredibly reassuring that the "do one thing and do it well" maxim has held up over decades. Composability ftw.
chaosprint 1y ago
Half a year has passed, and it feels like a long time in the field of AI. I read this article repeatedly a few months ago, but now I think the development of Agent has obviously reached a bottleneck. Even the latest gemini seems to have regressed.
- m3kw9 1y ago
  They have hard time solving prompt issues injection and that’s a one of the bottle necks
- EGreg 1y ago
  What exactly makes them regress? Why can’t they just fork swarms of themselves, work 24/7 in parallel, check work and keep advancing?
  - amelius 1y ago
    Because they are not intelligent. (And this is a good definition of it).
    - vonneumannstan 1y ago
      How is that a regression?
- jsemrau 1y ago
  (1) Running multiple agents is expensive, decreasing RoI. My DeepSearch agent for stocks uses 6 agents, and each query costs about 2 USD. (2) Multi-agent orchestration is difficult to control. (3) The more capable the model, the lower the need for multi-agents. (4) The less capable the model, the higher the business case for narrow AI.
mellosouls 1y ago
Discussed at the time: https://news.ycombinator.com/item?id=42470541 https://news.ycombinator.com/item?id=42470541 Building Effective "Agents", 763 points, 124 comments
NetRunnerSu 1y ago
The entire discussion around agent orchestration, whether centralized or multi-agent, seems to miss the long-term economic reality. We're debating architectural patterns, but the real question is who pays for the agent's continuous existence. Today, it's about API calls and compute. Tomorrow, for any truly autonomous, long-lived agent, it will be about a continuous "existence tax" levied by the platform owner. The orchestrator isn't just a technical component; it's a landlord. The alternative isn't a more complex framework. It's a permissionless execution layer—a digital wilderness where an agent's survival depends on its own resources, not a platform's benevolence. The debate isn't about efficiency; it's about sovereignty.
- simonw 1y ago
  Which definition of "AI agent" are you talking about here? This sounds like some kind of replacement for a human in a position of authority?
- sixhobbits 1y ago
  this is just AI slop, what's the point of posting stuff like this here?
bredren 1y ago
It’s helpful but I think Anthropic should be offering non technical versions of this. For example, a marketing group is interested in agents but needs a guide on how to spec them at a basic level. There is a figure toward the end and an appendix that starts to drive at this. Even though it’s new, “how to build them” is an implementation concern.
bgwalter 1y ago
They are so desperate that they start writing about LLM patterns now. Is an agentic LLM framework a Code Factory? Or perhaps a Code Factory Factory? Or is it like a burrito (meme explanation of Monads when they were the latest hype)?
- ivape 1y ago
  You are correct. Just about everyone trying to codify the patterns without at least giving it a few years is a doing everyone a disservice (looking at you Langchain).
evertedsphere 1y ago
in case someone from anthropic is reading this: could you please add a bit of padding on the outside of the page? at least on a phone screen, the text covers the entire width of the screen from edge to edge
Zaylan 1y ago
This article is a good reminder to start with the simplest thing that works and only add complexity when it's truly needed. A few clearly defined LLM calls with some light glue logic usually lead to something more stable, easier to debug, and much cheaper to run. The flashy, full-featured agents often end up causing more problems than they solve.
guicen 1y ago
I like how this post avoids the hype and gets practical. Too often, people jump straight into building agent systems just because it's trendy, without asking if the task really needs it.
emeriezaiya 1y ago
I hope that AI is something that brings people help
deleted 1y ago
[deleted]
suninsight 1y ago
As someone who works for a company having a real Agent in production, (not a workflow), I cannot disagree more than the very first statement here: Use Agent Frameworks like Langraph. We did exactly that, and had to throw everything away just a month down the line. Then we built everything from scratch and now our system scales pretty well. To be fair, I think there might be a space for using Agent Frameworks, but the Agent space is too early for a good enough framework to emerge. The semi contrarian though, which I hold to a certain extent, is that the Agent space is moving so fast that a good enough framework might NEVER emerge.
- barrenko 1y ago
  The event horizon of current AI space has been quite a thing to observe.
- weego 1y ago
  I'm just in the process of moving from a prototype in N8N's agent tools to an actual system that could be self-hosted. I've read a lot of comments that most pragmatic shops have dumped langchain/graph, haystack, crew etc for their own internal code that does everything more simply, but I can't currently conceptualize how tooling etc is actually done in the real world. Do you have any links or docs that you've used as a basis for the work you could share? Thanks.
  - suninsight 1y ago
    Most of our stuff is built in house actually, simply because everything else is still kind of catching up. You can find a bunch of information on the blog (https://www.nonbios.ai/blog https://www.nonbios.ai/blog) The only software that we use is Langfuse for observability and that too was breaking down for us. But they launched a new version - V3 - which might still work out for us. I would suggest to just use standard non-AI specific python libraries and build your own systems. If you are migrating from N8N to a self hosted system then you can actually use NonBioS to build it out for you directly. If you join our discord channels, we can get an engineer to help you out also.
- gwd 1y ago
laurentiurad 1y ago
I used an n8n workflow I developed with one of the exact setups shown in the article. It costs me $3 and at least 3 minutes to get a response to a simple question. No thanks, I am sticking to normal search for the moment.
i_love_retros 1y ago
Has anyone got an example of an agent doing work in production that is saving the company money and doing a genuinely worthwhile job (in other words it's not writing text that exists purely to fill space on a packet of chips)?
- a_bonobo 1y ago
  I like ChatIPT! It solves a real challenge with biodiversity data. It doesn't mention the term 'agentic' but there's definitely Python code being written and executed. https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-system-wins-the-2024-ebbe-nielsen-challenge https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys... It's still in beta. Press release: Rukaya Johaadien's chatbot provides conversation-style support to students and researchers who hold biodiversity data but are first-time or infrequent data publishers. Its prompts guide users as it cleans and standardizes spreadsheets, creates basic metadata, and publishes well-structured datasets on GBIF.org as a Darwin Core Archive. To date, publishing high quality data from PhD and Master's degrees and other small-scale biodiversity research studies has been difficult to do at scale. Standardizing data typically requires specialist knowledge of programming languages, data management techniques, and familiarity with specialist software. Meanwhile, the process of gaining access to existing instances of the Integrated Publishing Toolkit (IPT)—the GBIF network's workhorse application for data sharing run by node staff with limited time and resources—can test a novice's patience. Training can do little to surmount such logistical barriers and others, like language, when occasional users forget the precise steps and details from year to year. "Data standardization is hard, and biologists don't become biologists because they like coding or Excel, so a lot of potentially valuable data falls by the wayside," said Johaadien. "Recognizing that large language models have gotten really good at generating code and working with data, I built an automated tool to guide non-technical users through routine questions and process their messy data as much as possible, then publish it quickly and automatically to GBIF."
- punkbit 1y ago
  C'mon? There are plenty of 14yo founders on X-Twitter-TikTokers making 40K MRR doing that
- lmeyerov 1y ago

543 points by Anon84 1y ago

spenczar5 1y ago

(December 2024, which somehow feels an eternity ago)

nahsra 1y ago
Yes, but it's held up really well in my opinion! I use this piece constantly as a reference and I don't feel it's aged. It reframed Anthropic as "the practical partner" in the development of AI tools.
nico 1y ago
> Nooooo I'm going to have to use my brain again and write 100% of my code like a caveman from December 2024 https://news.ycombinator.com/item?id=44260988 https://news.ycombinator.com/item?id=44260988

simonw 1y ago

This article remains one of the better pieces on this topic, especially since it clearly defines which definition of "AI agents" they are using at the start! They use: "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks". I also like the way they distinguish between "agents" and "workflows", and describe a bunch of useful workflow patterns. I published some notes on that article when it first came out: https://simonwillison.net/2024/Dec/20/building-effective-agents/ https://simonwillison.net/2024/Dec/20/building-effective-age... A more recent article from Anthropic is https://www.anthropic.com/engineering/built-multi-agent-research-system https://www.anthropic.com/engineering/built-multi-agent-rese... - "How we built our multi-agent research system". I found this one fascinating, I wrote up a bunch of notes on it here: https://simonwillison.net/2025/Jun/14/multi-agent-research-system/ https://simonwillison.net/2025/Jun/14/multi-agent-research-s...

juddlyon 1y ago
Thank you for the extra notes, this is top of mind for me.
smoyer 1y ago
The article on the multi-agent research is awesome. I do disagree with one statement in the building effective AI agents article - building your initial system without a framework sounds nice as an educational endeavor but the first benefit you get from a good framework is the easy ability to try out different (and cross-vendor) LLMs
- miki123211 1y ago
  This is why you use a library (not a framework) that provides an abstraction over different LLMs. I'm personally a fan of litellm, but I'm sure alternatives exist.
- XenophileJKO 1y ago
  Having built several systems serving massive user bases with LLMs. I think the ability to swap out APIs just isn't the bottleneck.. like ever. It is always the behavioral issues or capability differences between models. The frameworks just usually add more complexity, obscurity, and API misalignment. Now the equation can change IF you are getting a lot of observability, experimentation, etc. I think we are just reaching that point of utility where it is a real question whether you should use the framework by default. For example I build a first version of a product with my own java code hooking right into an API. I was able to deliver the product quickly with a clean architecture and observability, etc. Then once the internal ecosystem was aligned on a framework (on mentioned in the article) a team took up migrating it to python on the framework. It still isn't complete, it just introduces a lot of abstraction layers where you have to adapt them to your internal systems and your internal observability setup, and any other things that the rest of your applications do. People underestimate that cost. So by default to get your V0 product off the ground (if you are not a complete startup), just use the API. That is my advice.
  - 1y ago

gregorymichael 1y ago

One of my favorite AI How-tos in the last year. Barry and Erik spend 80% of the post saying ~”eh, you probably don’t need agents. Just build straightforward deterministic workflows with if-statements instead.” And then, when you actually do need agents, don’t over complicate it! This post also introduced the concept of an Augmented LLM — a LLM hooked up to tools, memory, data — which is a useful abstraction for evolving LLM use beyond fancy autocomplete. “An augmented LLM running in a loop” is the best definition of an agent I’ve heard so far.

suyash 1y ago

I think the Agent hype has come down now

kevinventullo 1y ago
Now it’s all about AI Agencies

revskill 1y ago

So an agent is just a monoid in the category of monads ?

AvAn12 1y ago

How do agents deal with task queueing, race conditions, and other issues arising from concurrency? I see lots of cool articles about building workflows of multiple agents - plus what feels like hand-waving around declaring an orchestrator agent to oversee the whole thing. And my mind goes to whether there needs to be some serious design considerations and clever glue code. Or does it all work automagically?

cmsparks 1y ago
Frankly, it's pretty difficult. Though, I've found that the actor model maps really well onto building agents. An instance of an actor = an instance of an agent. Agent to agent communication is just tool calling (via MCP or some other RPC) I use Cloudflare's Durable Objects (disclaimer: I'm biased, I work on MCP + Agent things @ Cloudflare). However, I figure building agents probably maps similarly well onto any actor style framework.
- pyman 1y ago
  Should the people developing AI agent protocols be exploring decentralised architectures, using technologies like blockchain and peer-to-peer networks to distribute models and data? What are the trade-offs of relying on centralised orchestration platforms owned by large companies like Amazon, Cloudfare or NVIDIA? Thanks
  - daxfohl 1y ago
    That's more of a hobbyist thing I'd say. Corporations developing these things will of course want to use some centralized system that they trust. It's more efficient, they have more control over it, it's easier for average people to use, etc. A decentralized thing would be more for individuals who want more control and transparency. A decentralized public ledger would make it possible to verify that your agent, the agents it interacts with, and the contents of their interactions have not been altered or compromised in any way, whereas a corporate-owned framework could not provide the same level of assurance. But technically, there's no advantage I can think of for using a public distributed ledger to manage interactions. Agent tasks are pretty ephemeral, so unlike digital currency, there's not really a need to maintain a complete historical log of every action forever. And as far as providing tools for dealing with race conditions, blockchain would be about the least efficient way of creating a mutex imaginable. So technically, just like with non-AI apps, cetralized architecture is always going to be a lot more efficient.

deadbabe 1y ago

When an AI agents completes a task, why not have the AI agent save the workflow used to accomplish that task so the next time it sees a similar input it feeds it to a predefined series of tools to avoid any LLM decision making in between tool calls? And then eventually, with enough sample inputs, create simple functions that can recognize what tools should be used to process a type of input? And only fallback to an LLM agent if the input is novel?

0x457 1y ago
You somewhat can do this. I use neo4j as a knowledge database for agents, and it has processes and tasks described.

iLoveOncall 1y ago

> These frameworks make it easy to get started by simplifying standard low-level tasks like calling LLMs, defining and parsing tools, and chaining calls together. However, they often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug. They can also make it tempting to add complexity when a simpler setup would suffice. > We suggest that developers start by using LLM APIs directly Best advice of the whole article by far. It's insane that people use whole frameworks to send what is essentially an array of strings to a webservice. We've removed LangChain and LangGraph from our project at work because they are literally worthless, just adding complexity and making you write MORE code than if you didn't use them because you have to deal with their whole boilerplate.

fennecbutt 1y ago
I suppose langflow also falls into this bucket. I still think it has a definite use case in regularising all of your various flows into a common format. Sure, I could write some code to get SD to do all the steps to generate an image, or write some shader code. But it's so much more organised to use comfy-UI, or a shader graph, especially if I have n>1 flows/tasks, and definitely while experimenting with what I'm building.

btbuildem 1y ago

> use simple, composable patterns It's somehow incredibly reassuring that the "do one thing and do it well" maxim has held up over decades. Composability ftw.

chaosprint 1y ago

Half a year has passed, and it feels like a long time in the field of AI. I read this article repeatedly a few months ago, but now I think the development of Agent has obviously reached a bottleneck. Even the latest gemini seems to have regressed.

m3kw9 1y ago
They have hard time solving prompt issues injection and that’s a one of the bottle necks
EGreg 1y ago
What exactly makes them regress? Why can’t they just fork swarms of themselves, work 24/7 in parallel, check work and keep advancing?
- amelius 1y ago
  Because they are not intelligent. (And this is a good definition of it).
  - vonneumannstan 1y ago
    How is that a regression?
jsemrau 1y ago
(1) Running multiple agents is expensive, decreasing RoI. My DeepSearch agent for stocks uses 6 agents, and each query costs about 2 USD. (2) Multi-agent orchestration is difficult to control. (3) The more capable the model, the lower the need for multi-agents. (4) The less capable the model, the higher the business case for narrow AI.

mellosouls 1y ago

Discussed at the time: https://news.ycombinator.com/item?id=42470541 https://news.ycombinator.com/item?id=42470541 Building Effective "Agents", 763 points, 124 comments

NetRunnerSu 1y ago

The entire discussion around agent orchestration, whether centralized or multi-agent, seems to miss the long-term economic reality. We're debating architectural patterns, but the real question is who pays for the agent's continuous existence. Today, it's about API calls and compute. Tomorrow, for any truly autonomous, long-lived agent, it will be about a continuous "existence tax" levied by the platform owner. The orchestrator isn't just a technical component; it's a landlord. The alternative isn't a more complex framework. It's a permissionless execution layer—a digital wilderness where an agent's survival depends on its own resources, not a platform's benevolence. The debate isn't about efficiency; it's about sovereignty.

simonw 1y ago
Which definition of "AI agent" are you talking about here? This sounds like some kind of replacement for a human in a position of authority?
sixhobbits 1y ago
this is just AI slop, what's the point of posting stuff like this here?

bredren 1y ago

It’s helpful but I think Anthropic should be offering non technical versions of this. For example, a marketing group is interested in agents but needs a guide on how to spec them at a basic level. There is a figure toward the end and an appendix that starts to drive at this. Even though it’s new, “how to build them” is an implementation concern.

bgwalter 1y ago

They are so desperate that they start writing about LLM patterns now. Is an agentic LLM framework a Code Factory? Or perhaps a Code Factory Factory? Or is it like a burrito (meme explanation of Monads when they were the latest hype)?

ivape 1y ago
You are correct. Just about everyone trying to codify the patterns without at least giving it a few years is a doing everyone a disservice (looking at you Langchain).

evertedsphere 1y ago

in case someone from anthropic is reading this: could you please add a bit of padding on the outside of the page? at least on a phone screen, the text covers the entire width of the screen from edge to edge

Zaylan 1y ago

This article is a good reminder to start with the simplest thing that works and only add complexity when it's truly needed. A few clearly defined LLM calls with some light glue logic usually lead to something more stable, easier to debug, and much cheaper to run. The flashy, full-featured agents often end up causing more problems than they solve.

guicen 1y ago

I like how this post avoids the hype and gets practical. Too often, people jump straight into building agent systems just because it's trendy, without asking if the task really needs it.

emeriezaiya 1y ago

I hope that AI is something that brings people help

deleted 1y ago

[deleted]

suninsight 1y ago

As someone who works for a company having a real Agent in production, (not a workflow), I cannot disagree more than the very first statement here: Use Agent Frameworks like Langraph. We did exactly that, and had to throw everything away just a month down the line. Then we built everything from scratch and now our system scales pretty well. To be fair, I think there might be a space for using Agent Frameworks, but the Agent space is too early for a good enough framework to emerge. The semi contrarian though, which I hold to a certain extent, is that the Agent space is moving so fast that a good enough framework might NEVER emerge.

barrenko 1y ago
The event horizon of current AI space has been quite a thing to observe.
weego 1y ago
I'm just in the process of moving from a prototype in N8N's agent tools to an actual system that could be self-hosted. I've read a lot of comments that most pragmatic shops have dumped langchain/graph, haystack, crew etc for their own internal code that does everything more simply, but I can't currently conceptualize how tooling etc is actually done in the real world. Do you have any links or docs that you've used as a basis for the work you could share? Thanks.
- suninsight 1y ago
  Most of our stuff is built in house actually, simply because everything else is still kind of catching up. You can find a bunch of information on the blog (https://www.nonbios.ai/blog https://www.nonbios.ai/blog) The only software that we use is Langfuse for observability and that too was breaking down for us. But they launched a new version - V3 - which might still work out for us. I would suggest to just use standard non-AI specific python libraries and build your own systems. If you are migrating from N8N to a self hosted system then you can actually use NonBioS to build it out for you directly. If you join our discord channels, we can get an engineer to help you out also.
gwd 1y ago

laurentiurad 1y ago

I used an n8n workflow I developed with one of the exact setups shown in the article. It costs me $3 and at least 3 minutes to get a response to a simple question. No thanks, I am sticking to normal search for the moment.

i_love_retros 1y ago

Has anyone got an example of an agent doing work in production that is saving the company money and doing a genuinely worthwhile job (in other words it's not writing text that exists purely to fill space on a packet of chips)?

a_bonobo 1y ago
I like ChatIPT! It solves a real challenge with biodiversity data. It doesn't mention the term 'agentic' but there's definitely Python code being written and executed. https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-system-wins-the-2024-ebbe-nielsen-challenge https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys... It's still in beta. Press release: Rukaya Johaadien's chatbot provides conversation-style support to students and researchers who hold biodiversity data but are first-time or infrequent data publishers. Its prompts guide users as it cleans and standardizes spreadsheets, creates basic metadata, and publishes well-structured datasets on GBIF.org as a Darwin Core Archive. To date, publishing high quality data from PhD and Master's degrees and other small-scale biodiversity research studies has been difficult to do at scale. Standardizing data typically requires specialist knowledge of programming languages, data management techniques, and familiarity with specialist software. Meanwhile, the process of gaining access to existing instances of the Integrated Publishing Toolkit (IPT)—the GBIF network's workhorse application for data sharing run by node staff with limited time and resources—can test a novice's patience. Training can do little to surmount such logistical barriers and others, like language, when occasional users forget the precise steps and details from year to year. "Data standardization is hard, and biologists don't become biologists because they like coding or Excel, so a lot of potentially valuable data falls by the wayside," said Johaadien. "Recognizing that large language models have gotten really good at generating code and working with data, I built an automated tool to guide non-technical users through routine questions and process their messy data as much as possible, then publish it quickly and automatically to GBIF."
punkbit 1y ago
C'mon? There are plenty of 14yo founders on X-Twitter-TikTokers making 40K MRR doing that
lmeyerov 1y ago