Friend of mine just open sourced his agent framework.
It's written in Rust and supports some cool features like time-travel debugging, embedded code interpreter (Deno + Starlark), human-in-the-loop, and agent evals.
Sharing here cause he's an introvert :) Would love to hear what the HN community thinks!
As someone that might well be interested in using this (as in someone that is likely to make use of better tooling around LLMs), I'm really struggling to understand what it does. Can anyone provide a summary of what an agent is in this context and an example of why this library makes things better?
In what I think of as engineering terms: an agent is a long running service that invokes LLMs during its execution. In contrast to an LLM driven application where the primary function is synchronous with the end user (like chatGPT). There's a blurry line there but that's how I think about it.
AutoGPT and BabyAGI are probably the two most well known examples so far.
A significant struggle when building these types of applications is understanding and debugging behavior many execution steps deep. This tries to assist with that by giving a framework for structuring the way your agent runs.
Maybe a similar concept is breaking out a web application into services, or individual route handlers, rather than implementing everything as one massive loop that responds to events.
So essentially a long running process that responds to events etc. So my understanding is now: when stuff happens, say a database gets updated, or a timer triggers, the agent wrangles the data and passes it to OpenAI for some LLM heavy lifting, then wrangles what is returned somehow. Is that correct?
I hope that people will be able to build agents in a way that makes deliberate methodical progress towards them successfully executing given tasks. Part of this could be tracing alone, which is something that I explored using opentelemetry on my own agents. But I found that I wanted to be able to understand the specific structure of the agent as I iterated on it as well. So Chidori attempts to allow you to do that, while having some properties that I feel assist with managing complexity!
Agents that work 80-90% of the time rather than 30-40% of the time would be awesome. And I think part of that is being able to iterate on specific pieces of the agent's behavior in a deliberate way.
You stole the name from Naruto...didn't you? Which is fine. It's been what, over 15 years since the episode/manga with that technique debuted? I guess I shouldn't be surprised someone young who watched it grew up and made a thing.
Lore dump: This is not a coincidence, as the characters themselves refer to the chidori being named due to sounding like thousands of birds. The alternate name used by kakashi, raikiri, is related to https://en.wikipedia.org/wiki/Tachibana_D%C5%8Dsetsu
Interestingly, in the Shona language it means 'puppet' which I found very appropriate as it is a functional framework which you have behave in whatever way you want.
The discord server linked from the github would work! I'd love to find out what the specific questions are. Alternatively twitter DM would also work @kveykva.
Well.. i'll be damned. I've been wanting to toy with LLMs on a local-only and simple "command<->LLM glue" style development. If i understand this project right.. it looks like Chidori implements most of the foundational stuff i wanted to do. Notably defining commands (nodes in this, i think?), monitoring node IO and LLM IO, etc.
Looks like i'll need to give this a try. Awesome!
edit: My goal is single binary local-only install though, so sounds like Chidori struggles here due to OpenAI required. Unfortunate for now
I've built something similar with a focus on returning structured data from the Agent and making it simple to expose an Agent as an OpenAPI. If that sounds interesting, I've wrote up some details here: https://wundergraph.com/blog/beyond_functions_seamlessly_bui...
I like the idea of the agent-protocol they define, I do feel that long term there might be a common interface for agent <-> agent or user <-> agent communication.
Hey, CEO of e2b here (the ones currently pushing the protocol). Congrats to the launch of Chidori! Great work!
> I do feel that long term there might be a common interface for agent <-> agent or user <-> agent communication.
Definitely! We're just starting really small so we don't build the wrong thing and abstraction.
We'd would love to hear your thoughts and feedback on the direction of the protocol. And how the protocol could help Chidori and your users. Essentially, how we can get it to more agent devs and make it useful for them.
Would you be up for a chat? I'm @mlejva on Twitter
I'm most interested in the reactive runtime though and like the temporal.io and Timely Dataflow references. Is it possible to just have access to that in Rust and leave out the agent bits?
You could build a system that never invoked prompt nodes, and I think that would be equivalent! Re: timely dataflow, there are only hints of that in there right now - but I intend to expand on it.
Currently it only supports openAI. I'm looking into patterns for supporting local LLMs! I think the best approach for that might be to allow you to update the api endpoint to your own and assume you're using something that mirrors the structure of their API.
The main escape hatch for everything right now are custom nodes though. But then you'll need to bring your own templating pattern.
My goal is to build a single binary, local only command<->LLM interface. Chidori looks to overlap with that significantly, but of course i'd need custom LLM resolution.
It's written in Rust and supports some cool features like time-travel debugging, embedded code interpreter (Deno + Starlark), human-in-the-loop, and agent evals.
Sharing here cause he's an introvert :) Would love to hear what the HN community thinks!