Agent Relation And Communication Architecture Theory Proposal #39
Replies: 10 comments 16 replies
-
|
I love this |
Beta Was this translation helpful? Give feedback.
-
|
I had something similar drawn up. From a technical PoV, I think that one huge problem is the threads... how does an agent know whether it should direct it's next response to it's parent up the chart, or a child down the chart from it. We could have a thread for each possible agent the current one could talk too, but how would information be shared between channels... i.e how would an information request from a low layer agent be passed up. I realized you would need each agent to have a thread with itself, where all threads it belongs to post their chat history each update to the "self-thread". the "self-thread" will the make outputs telling the assistant which thread to continue the conversation with next... effectively triage for communication. |
Beta Was this translation helpful? Give feedback.
-
|
I think a reliable way of tracking the successful completion of tasks would also be helpful in reassingment of new tasks. Certain agents will have been given better directives or in fact learn over time resulting in better outcomes. if these could be reliably tracked, this could be used to assign subsequent tasks. |
Beta Was this translation helpful? Give feedback.
-
|
One agent per task. Pass/fail and the agent self terminates when it succeeds or fails |
Beta Was this translation helpful? Give feedback.
-
|
An Agent Library can be established. Regardless of the outcome, agents are terminated after the task is completed or failed, and their score in the library is updated accordingly. |
Beta Was this translation helpful? Give feedback.
-
|
Great thoughts, all! Seems to me that one agent per task is the way for sure here (scope of the task directly proportional to the tier that the agent is on). I don't think any other options make sense here. With regard to scope of audience, this might be a hot take but I don't see any reason why a sub-agent should want to know or "talk to" his grandfather's thread, or know/talk to his grandchild's thread. If we want to make each agent as effective as possible, I think delegating specific tasks for each agent (sort of how I've outlined/hinted at in this discussion thread) is the way to go as opposed to a "mass knowledge sharing" approach where every agent knows all sorts of things about every agent below it. The method I propose of 'reporting progress' to the parent bakes into the system a sense of accountability for actions, and because the SOB can intervene at any time, it seems like the mass knowledge sharing only makes sense for the people who understand the main directive of the system (the SOB). Of course, this entire thing is an experiment so we'll see how this shakes out.
I feel like this shouldn't necessarily be a problem with the current setup we're looking at here (if I'm missing anything with this which is totally possible, definitely let's talk about it). The key is the tick system. If the entire system is operating methodically in lock step with one another (every agent does 1 action per step), then one branch can't get wildly chaotic in the wrong direction, because the SOB has the opportunity to look at every action in between every step. Further, since I propose an action queue in between ticks, that means any potentially destructive actions can be caught before they are carried out. The checks/balances process is recursive. |
Beta Was this translation helpful? Give feedback.
-
There is room for improvement, but I don't think info needs to necessarily be passed up outside of reports. (see my previous response here). There could be other reporting systems, but I feel like this one might be worth a shot. Specifically, we definitely don't need an infinite web of scaling communication between all agents - only the SOB needs to know everything. Each agent is in charge of one task and one task only, and everything they should need to accomplish that task can be found in the parent and in its children I think, so I think in theory (at least, my theory here) is that is all they need. Other thoughts on this? Holes? |
Beta Was this translation helpful? Give feedback.
-
|
@daveshap have you seen the "agency" project? I am not affiliated with them, but it feels like there are some things you could use from there (agent spaces, invoking other agents, talking to other systems etc.). Check it out here: https://github.com/operand/agency |
Beta Was this translation helpful? Give feedback.
-
|
Looks useful thanks for bringing it into the conversation. The Collective will assimilate all useful technological novelties... |
Beta Was this translation helpful? Give feedback.
-
|
Thinking about agents as machines, the communication protocols for M2M have been widely developed already. It could be that using something like MQTT, each tier would have a Topic to which any agent would post, that would be async so that all agents within the Topic could hear what others are saying and update it states each iteration with the latest information posted. I think this communication scheme should follow standard IoT methods for streaming data. Considering Tiers as MQTT (or similar) Topics, there would be a topic for each tier and maybe a topic for bridging between tiers. This would also ensure communication flows both ways, that is, the firing order should return information to the higher tier personas, a feedback loop of information and transparent across the tier participants |
Beta Was this translation helpful? Give feedback.
-
TL;DR:My idea is that agents should communicate with their parent and children to minimize noise, streamline tasks, simplify communication, and enhance the SOB's ability to regulate agents. This approach aims to avoid the complexity of managing communication channels across tiers and improve the effectiveness of agents in accomplishing their tasks by streamlining their communication channels. I’m not familiar with MQTT, but sounds like a very interesting prospect! Great thought. Main ThoughtI think topic-based threads across tiers like you are proposing is a pretty different idea than the one I proposed (although equally valid). To clarify the reasoning behind my thoughts on this a bit more, I think task-based individual agent threads would be preferred over topic based threads across tiers. Let me explain why I think this is the case. With what I’ve proposed in this discussion, I would expect that agents would themselves silo their topics to their own agents, each with their own threads, which would effectively be creating a topic channel for the topic they are assigned to research/create like you proposed. I wonder if it makes more sense to have each agent only communicating with their parent and children for 4 reasons:
I would imagine if there were agents that were tasked with doing task A, those agents would become less effective at accomplishing task A if they were also in charge of communicating with team X back and fourth (an entire question-asking system would get rather complex, as well as managing who joins what topic channels and how they are organized/grouped together which seems like a bit of a different system than what I am talking about here). Rather, they can check the context store that is relevant to them (namely, their own, and parent feedback and summaries from children) to accomplish their one task. Should they not perform well, their parent can de-provision them. In a communication channel with lots of agents talking across an entire tier, I think we would need to solve the additional problem of making sure all the other agents know that this agent’s thoughts are “no longer valid since they have been de-provisioned”, and any other logic that would go along with that. There’s a TON of iteration to be done on these ideas! Great thoughts. Other thoughts on this? |
Beta Was this translation helpful? Give feedback.
-
|
This is looking more and more like an internal Twitter. I love it. |
Beta Was this translation helpful? Give feedback.
-
|
Considering that the SOB will have 1 input and 1 output channel, we could use it as I have seen with Professor Synapse. It calls several specialists in a single chat. This could help reduce API costs by not having to send a SOB agent's conversation to all other SOB members. as in the example I made in the link. SOB chat |
Beta Was this translation helpful? Give feedback.
-
|
I like having a gated IO with SOB. Chinese Room kinda thing. |
Beta Was this translation helpful? Give feedback.
-
|
I just came out of my own Strategy planning session at work and was curious how much we want to emulate how organizations handle goal setting that cascades from the top-down. Thoughts? Is this solving a problem that doesn't exist? TL;DR: Implementing Dynamic OKRs within HAAS for Enhanced Goal Realization Objectives and Key Results (OKRs) are a goal-setting framework that enhances strategic alignment, operational efficiency, and accountability through measurable results. They drive focus on what matters most, promoting transparency and engagement. In the context of HAAS, integrating OKRs could significantly bolster agents' ability to rapidly and efficiently self-organize towards mission-critical outcomes.
|
Beta Was this translation helpful? Give feedback.
-
|
This would be a good set of principles to include in standard docs for the SOB. SOPs for SOBs! |
Beta Was this translation helpful? Give feedback.
-
|
I'm new to this space but given how rigid the hierarchical structure is I see a potential issue down the line Organizational InertiaThe effectiveness of large hierarchies, like those in big corporations, can be hindered by organizational inertia. I see a lot of potential for middle management reinventing wheels. I'm particularly concerned with two areas: Improving Agent Development: Knowledge about building and evaluating agents should not be isolated or scattered. Better to have a system where improvements in agent design are quickly shared with upper management and tested at each level. This would allow for consistent updates and enhancements across the entire hierarchy. Access to Essential Tools: Universally beneficial tools, like advanced web search and summary tools, should be easily accessible to all agents. Perhaps each tool's description is put in a lookup table that a manager can search when creating new agents. Curious to hear potential remedies for this, these discussions are very exciting |
Beta Was this translation helpful? Give feedback.
-
|
Fortunately you can terminate agents in real time. Elon shows you can do this with employees too, but then they launch class action lawsuits. We don't have to worry about that with agent swarms. We can pivot fast. |
Beta Was this translation helpful? Give feedback.
-
|
Agree completely. That is why I think agent creator should be like a freelancer, anybody can call it and it has knowledge of all created agents since at least after some runs we will sparsely create new agents, it will be more effective to use already tested ones and also maybe improve them a little.. Agent creator after being instructed by requestor will give newly spawned agent access to tools it needs, if during agent task it turns out it lacks some tools it asks tool creator to add tolls to its tool list, then again tool creator having knowledge of all tools first looks for already created one that fits current needs, in none found it creates new one. All of that assumes that there may be some back and forth communication for requesters (both for agents and tools) and creators. We would have to provide creators with list of data that is needed in order to create something, like a checklist, so we could minimize guess on their side. Communication parent children is one thing second is amongst siblings, third would be to freelancer. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, well thought out swarm-gpt dynamics. Let's see how it performs after building it :) |
Beta Was this translation helpful? Give feedback.
-
Proposal for single process event loop Message SystemIdea: Pros:
Cons:
Conclusion: |
Beta Was this translation helpful? Give feedback.
-
|
This actually becomes more complex than decoupled service based architecture. The simple answer is no. Thanks for bringing it up though. |
Beta Was this translation helpful? Give feedback.
-
|
@daveshap I think you won't be able got around some complexity which at least service bus between, becomes elicit instead of hidden inside agent code. Especially because in the end the agents need to be designed by SOB. The main points it will solve:
The part which I do agree can give some problems it the programing with taking into account of the event loop. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I hope I'm right here. When I look at the picture in first post, I see similiarities with the ACE image. In ACE there is an hierarchy (the layer on top is more important than on the bottom) and every layer has it's own tier (Aspirational - tier 1, Global strategy - tier 2, ...), like in HAAS. So why not implement a communication, like in ACE. There will be a North-bound communication channel, and South-bound channel. Every Agent will be able to read and filter communication in these channels and also write to them. This is just an idea. Maybe it is, maybe it is not sufficient. Needs more thinking, discussions and experiments. |
Beta Was this translation helpful? Give feedback.
-
TL;DR:
I propose two ideas for agent communication and regulation. Each agent follows a sequence of steps in a tick, including executing actions, checking context, reviewing goal progress, queuing actions, and reporting to upper-level agents. The SOB agents have the authority to review and intervene in agent threads to ensure adherence to directives
Problems
I have done my best to keep this post as short, dense, actionable, and contained as possible. Feedback and thoughts welcome.
There are two problems I will address that are intimately related:
The ideas I have are very high level, and I do not propose a code implementation yet. I want to work through the high-level architecture and receive feedback before getting into the code of my proposed solution.
Terms
High level agent: Agent closer to the SOB, broad strategic goals
Low level agent: More specialized and task-oriented
Sub-agents: Any agent that is not an SOB agent or an executive agent
Regulation: the process by which the SOB and executive agents ensure sub-agents are keeping to guidelines and solving tasks effectively and efficiently.
Agent communication: The process by which agents communication with each other, including:
Thread: Every sub-agent has it’s own “thread” in which every action it has taken is logged, sequentially, paired with the feedback that it received for that action from it’s parent agent. Threads will be stored in a vector-store of choice on a per-agent basis (Pinecone or Weaveiate). When agents are terminated, their individual action/feedback store context is deleted as well. Each time an agent takes an action, the store is updated with that action. Each time a parent agent gives feedback on that action, that agent’s thread is updated to reflect the feedback.
Agent Context: An agent’s context is all of the information that the agent knows about the problem at hand, including general knowledge, tools it has access to, it’s current thread, the threads of each of it’s children, etc. SOB agents have access to ALL threads. High-tier agents have access to low-tier agent threads, but low-tier agents do not have access to high-tier agent threads. Each agent (with the exception of SOB agents) can only 'talk' (enter information into it's thread) to its parent and any children that it has.
Tick: The highest-level concept in the agent swarm simulation. Each tick represents one step of the simulation, or one unit of time. Each tick, every agent (SOB agents, executive agents, and sub-agents) ”fires” ************************(i.e. performs the following five tasks in order):
Agent Firing Order
When an agent “fires”, they complete the above 5 steps. The order that sub-agents fire in is important. See the diagram below:
Agents fire recursively from bottom to top in a depth first approach. After each tick (i.e., all of the executive level agents have fired ONCE).
Below is more detail about each tick:
1. Execute action from previous tick
At the start of each tick, when the agent fires, it completes the action that was queued from the previous tick.
2. Check Known Context
This includes feedback on the previous tick from the parent agent, reports from child agents, general agent guidebook baseline understanding, the overall goal it is trying to accomplish, and any other context that the agent might have. Any agent does not need to see too much context - JUST reports from child agents, feedback from parent agent, goal, and it’s own action history paired with the feedback from the parent agent after each action.
3. Review goal progress
From the context, the agent reviews what it’s goal is in preparation for the next step, logging to it’s own thread. In addition, the agent reviews the progress from it’s children agents and gives feedback to each in each agent’s respective thread. If any of the children queued actions is problematic, then this is the stage where an edit to the thread can be made by this agent, and the action can be cancelled and feedback on why can be given.
4. Queue an action based on the context
After the agent has reviewed it’s own context, the agent chooses an action to take from the actions that are available to it and then queues that action. The action metadata is logged in the thread history for this agent, but the action is not performed yet. This is so that there is a chance for the parent agent to overrule the action.
5. Report/summarize progress to upper-level agent.
This is a critical step. In this step, the agent reports on all that it did in this step, and summarizes to the parent agent for review.
SOB Intervention:
The SOB agents have an opportunity to review ALL PROGRESS that it would like to check from the tick that just happened. The SOB board can collectively review each thread, starting with the executive board threads for each agent, and if it deems there is a problem in the thread, it can choose to investigate the threads of child agents. If the SOB thinks that an agent is not following it’s directives, it can choose to modify, add, or delete anything from the thread for that agent (including giving it tasks to do next, or even deleting the agent and it’s sub agents entirely). After the SOB has reviewed what it wants to, then the next tick begins.
What I did not cover
I did not talk about specific communication channels, or technically how communication would work. I also did not hash out SOB chat room communication, but I do have thoughts on that that I will share later.
Let me know what you think, and let’s see how we can improve on this idea!
Beta Was this translation helpful? Give feedback.
All reactions