uAgents
uAgents copied to clipboard
examples overhaul
- [ ] add Readme.md to all examples, explaining the core thing to be learned and describing other preconditions / workflow of the example if necessary / appropriate
- [ ] evaluate distinguishing examples between 'examples' (focusing on basic functionality and framework features) and 'integrations/demos' (demonstrating how to add value, more use case oriented, e.g., Booking and cleaning demos)
- [ ] make DB integration example more explicit
- [ ] revisit example names to make their purpose more obvious (e.g., always include the demonstrated feature in the name)
uAgents Examples Proposal
- 01-my-first-agent:
This example integrates the core concepts from "01-first-agent" (startup), "02-interval-task" (on_interval), and "04-storage" (storage) to create an agent that introduces itself upon initialization. Following the introduction, the agent then periodically prints an incremented counter.
- 02-bureau-interaction:
Removed example "03-multiple-agents" and integrated code from "05-send-msg" and "15-wallet-messaging,"explaining both ways to send a message
- 03-send-tokens:
Use "06-send-tokens" example code to illustrate how agents can handle token transactions.
- 04-local-network-interaction:
Use "08-local-network-interaction" example code
- 05-protocols:
Introduces a simple, yet illustrative example of protocols by leveraging the "14-broadcast" code. This example is aimed at showcasing how to broadcast messages to two other agents containing the same protocol created in the example.
- 06-DB-integration:
Create a straightforward example demonstrating database (DB) integration.
- 07-mailbox-agents:
Use example "11-mailbox-agents" code
- 08-remote-agents:
Use example "12-remote-agents" code
- 09-name-service:
Use example "13-agent-name-service" code
Delete: Examples 07, 09 and 10
Any suggestions on examples 16 and 17? Are there any plans for changes for on_query and chit_chat?
Overall I like it! Just a few suggestions:
- It might make sense to separate out the demonstrations of core agent functionality (intervals, storage, messages, protocols, sending tokens) from the networking side of things (bureau, remote agents, mailbox-agents, name-service) into different folders. This will also help if we decide to re-use these for Agentverse hosted agents as well, which I think we should do. In this case, only the functional use cases would be relevant and the networking ones would only apply to uAgents.
- 06-DB-integration should probably be moved to
integrations
Thanks for starting this and I already like the suggestions. My comments and observations (well mostly requests for discussion):
- +1 for James suggestion to separate between "agent core" and "networking"
- I think we should rename remote-agents to external-agents as this is what these agents are called on agentverse. Anyone feeling we should maybe discuss if this should actually be called local-agents (also on agentverse)?
- Couldn't we also merge remote-agents and on-query-proxy? Slightly different focus, but in both cases it's about exposing an agent?
- I'm unsure about how much we should use the bureau in the examples. While it helps for quick local testing and offers an easier intro because it hides some of the networking bits, we need to make sure too clearly communicate that this is only a dev tool and you eventually need to do without a bureau. One option for simplicity of examples would be to do everything possible with a bureau and have one example (probably local-network-interactions) to demonstrate how to switch anything from bureau to actual networking (maybe even extend this with an avctl example?). Or do it the other way around (maybe more helpful, because closer to reality?) to do everything with normal networking and at least 2 agents and only one example of showing how to generally do things with a bureau.
- I would leave 17 for now. It will be a standalone example for the foreseeable future and still might change frequently, anyway. Florian and I will take care of it.
- While refactoring we should make sure to always follow the same conventions in naming, order of things etc. throughout all examples
I also like the proposal and agree with what has been said by James and David.
The only thing that I would like to pick up is the Bureau topic as I do think that it's a valuable addition to having agents running locally. It shines when using protocols to create a scalable agent platform from a single web-server as I've done in the EV charging example and I believe that there may be a case for using the Bureau as a load balancer for the task that the agents are designed for. So maybe we make a specific example that hints at that use rather than just putting two interacting agents in a bureau. What do you think?
This is a good point. I think that each agent in the multiple-agent examples should have their own file so they can be run independently or deployed to Agentverse. We would then have the option of including main.py files like:
from uagents import Bureau
from alice import alice
from bob import bob
bureau = Bureau()
bureau.add(alice)
bureau.add(bob)
bureau.run()
just to make it easier to run these examples.
But the Bureau example itself could be used to highlight the actual usefulness of Bureau as a small but more scalable agent-hosting platform as @Archento suggests.
Does agentverse support Bureau?
No, the Bureau is not part of the Agentverse