-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'Splitter Agent' #287
Comments
At the moment, you could add a I could imagine a system where you could specify a pattern when subscribing to events, but that might get complex. What is your use case for this? |
I think my original use case was for single 'large' agent that handles an entire service (eg. not split up like the twitter agent is) So for example, a Facebook agent that can create distinct events for things like:
They could all be made to work in a single event, or use an eventType field on it, but I feel like having a standard method for this would be useful (as I doubt this will be an isolated issue as the number of agents grows) Having the standardised method would also allow easier chaining without the TriggerAgent/etc in the middle. |
I think you're struggling with the same thing that I have been for a while: certain tasks require a complex group of agents, but there may be similar tasks with only slightly different configurations. I think this fits in with the "scenarios" idea that forms a more logical grouping of a collection of agents into manageable, duplicatable, self contained things with their own set of inputs and outputs. |
On the 'scenarios' aspect just had a thought re: UI/etc. Could have them as 'meta agents', only display them as a single agent on the agents page/in the graph, but allow you to drill down further into them. |
Moved this from #262 to a new thread at the request of @cantino
I will try and find some time today to clarify my thoughts a bit more. The tl;dr is that I want to emit distinctly different events from an agent in a clean way, and then be able to handle them downstream nicely. I was thinking at one stage along the lines of being able to define multiple different output streams/channels ('event type') from an agent, and then being able to wire up the downstream agents not only to the agent, but also a particular channel ('event type') on that agent.
The original note in my todo list:
The text was updated successfully, but these errors were encountered: