"One Agent - Many Actions" vs "Several Agents - Fewer Actions"

Rovo
,
1

Hey there,

What’s the suggested way to implement the Rovo Agents? Should there be one Agent supporting many (e.g. 8+) actions? Or multiple agents with fewer (e.g. <3) actions each?

The main reason behind this question is organizing the prompt inside the Agent. It can be quite hard to follow if you have to give detailed instructions for each action, all within the same prompt.

Or can we maybe reference prompts in other files?

Thanks,
Vladimir

2

@VladimirNegacevschi,

My experience so far favors “several agents with fewer actions each”.

Atlassian does not yet have support for referencing across agents; however, I find reasons to want some kind of composition with each new agent. I don’t have enough data points to have a strong opinion yet, but my current light preference would a way to “import” actions from other agents. For that matter, I’d really like to let users have access to actions without having a pre-defined Forge agent. My preferences might be a function of the kinds of agents I’m writing; I have no intent to distribute or sell on Marketplace. Have you developed any opinions about how composition should work?

I don’t yet have any rule-of-thumb advice about number of actions. Indeed, my experience is more about the size & complexity of the prompt. So I try to push as much as possible into actions for more reliable outcomes and better observability.

3

Thank you for the answer, @ibuchanan. I haven’t formed any opinions, because I haven’t tested the different possibilities yet.

But I would imagine that if you have a workflow that could take the user through several stages, where each stage calls at least one action, the single prompt could get quite big. Splitting agents would make sense in this case.

As a solution, similar to what you were proposing, I’m imagining it would be nice to have an “Orchestrator” Agent that calls “Activity” Agents. This way you could implement different orchestration mechanisms (chaining, fan-in/fan-out, etc). And the orchestration logic would be written inside an action, from where you can invoke different agents.