81–84 of 84 posts
I believe the principles would be easier to follow if there is a consistent narrative through the factors, why which I mean using potentially real-world example for such a system.
This is a great bit of feedback - what kinda of use cases do you think would make sense? Definitely wanna evolve this in the open with the community
Very informative wiki, thank you, I will definitely use it. So Ive made my own "AI Agents framework" [0] based on actor model, state machines and aspect oriented programming (released just yesterday, no HN post yet) and I really like points 5 and 7: 5: Unify execution state and business state 8. Own your control flow That is exactly what SecAI does, as it's a graph control flow library at it's core (multigraph instea…
"Another thing often missed by other frameworks are dedicated devtools" From my experience, PydanticAI really nailed it with Logfire—debugging[0] agents was significantly easier and more effective compared to the other frameworks and libraries I tested. [0] https://ai.pydantic.dev/logfire/#pydantic-logfire
Execution trees are enough for workflows, but bots/agents aren't simple workflows.
Earlier quoted context omitted.
interesting - I think I have to side with the Boundary (YC W23) folks on this one - if you want bleeding edge performance, you need to be able to open the box and hack on the insides. I don't agree fully with this article https://www.chrismdp.com/beyond-prompting/ but the comparison of punchards -> assembly -> c -> higher langs is quite useful here I just don't know when we'll get the right abstraction - i don't thin…
It's always true that you need to drop down a level of abstraction in order to extract the ultimate performance. (eg I wrote a decent-sized game + engine entirely in C about 10 years ago and played with SIMD vectors to optimise the render loop) However, I think the vast majority of use cases will not require this level of control, and we will abandon prompts once the tools improve. Langchain and DSPY are also not the…