It's great to see this kind of infrastructure work to integrate a variety of agents into whatever system you're building. Keep up the good work! I may crib some notes from this for use in non-Python projects.
We have a number of things we're looking at for agents. One is derived from internal code, but has to clear some legal hurdles to OSS. One is a new codebase, but not quite up to the current spec. We're also keeping an eye on other OSS projects. We don't really want to reinvent the wheel here, but we clearly have our own ideas about how to run jobs :)
Doing it in python was a way to quickly demonstrate the ideas and make something that works, albeit minimally. I expect that we will want to do more interesting things that will really ask for a "proper" (sorry python) language like Go or C++.
Yes, this will be an interesting next experiment - adding agents with additional tools (also for example access to internal APIs) will be quite powerful.
I and my team have been building a python library for improving the steerability of AI agents, the library also allows us to add an essentially unlimited number of tools to agents, add safety guardrails, etc. We have a lot more coming and I'm just excited to share our first public release. Let us know your thoughts!
I'm sure the other engineers on the project will have their own opinions here, but for me there's the obviously visible parts to the project (the prompt, tools, ...) and the invisible parts (indexing, tokenising/chunking, parallelising, streaming, ...).
Building agents is an experimental process. You test an approach, maybe it works, and there's not always an obvious reason why certain experiments fail or succeed. We built three prototype agents in a Python and JS, because those languages favour scrappy fast iteration. This helped us quickly nail down our approach to the 'visible' parts.
Once we nailed down our approach, we rebuilt the agent in Rust because the speed and safety favoured all the 'invisible' parts of the project.
Have been working with this and very impressed so far - it’s a step ahead of LangChain agents and seems to be receiving more attention/development than LangChain was interested in committing to agents.
FWIW the “group research” and “chess” examples from the notebooks folder in their repo have been the best for explaining the utility of this tech to others - the meme generator does a good job showing functions stripped down but misses a lot of the important bits
I get the same feeling. AI Agents sounds very cool but reliability is a huge issue right now.
The fact that you can get vastly different outcomes for similar runs (even while using Claude 3 Opus with tool/function calling) can drive you insane. I read somewhere down in this thread that one way to mitigate these problems is my implementing a robust state machine. I reckon this can help, but I also believe that somehow leveraging memory from previous runs could be useful too. It's not fully clear in my mind how to go about doing this.
I'm still very excited about the space though. It's a great place to be and I love the energy but also measured enthusiasm from everyone who is trying to push the boundaries of what is possible with agents.
I'm currently also tinkering with my own Python AI Agent library to further my understanding of how they work: https://github.com/kenshiro-o/nagato-ai . I don't expect it to become the standard but it's good fun and a great learning opportunity for me :).
Hey Nick and Ben, congrats to launch! I really like that you're going in the TS way by default. I personally think there will me more AI Engineers (devs building LLM apps/agents) working in TS than in Python.
I wanted to ask if you accept PRs for integrations?
I'm a co-founder of E2B [0]. We give private sandboxed cloud envs to any agent. We're building two things:
- [1] Agent Protocol - it's an open protocol that defines how to communicate with an agent. The current goal is to make benchmarking agents simple (it's used for example by folks at AutoGPT and other popular agents)
- [2] SDK that gives your agent a cloud environment (currently in early access)
Would love to figure out how to integrate these to into Axilla if it makes sense to you. What would be the best way to connect?
I shared the motivating use case for why Marcin and I built this (LLM agents using terminals) in a diff comment but I’ll also expand the readme to give examples of use cases.
I've been tinkering with LangChain for a few days and I agree. Is there a resource that collects the agents so we can experiment? I'd love to see an aggregated list of the most impressive agents and use cases if anyone knows of any. This stuff is the future of computing no doubt.
reply