agentResponse in Flow - Different Output Types

[Rick Johnston]

I have created a Rovo agent to assist my team with estimations. It is designed to produce an output that looks like this:

Estimate: 5 Story Points

Rationale

1. Complexity & Scope

Systemic Integration Issue:
This is a multi-client outage involving the third-party lead ingestion path. The scope includes the Lead Intake API, cross-database provider mapping tables, and tenant-level configuration validation.

Technical Depth:
The investigation requires tracing lead flow through the OEM/API processing pipeline and validating provider identity resolution. This includes backend API logic and database integrity checks across multiple environments (Production vs. Staging).

2. Comparison to Similar Work

Ticket-AAAA (5 points):
Involved investigating delayed or stalled lead processing. Similar to this issue, it required identifying root causes across application logic and backend processing jobs, resulting in infrastructure-level fixes.

Ticket-BBBB (5 points):
Addressed leads failing due to configuration inconsistencies. The work required database patching and service-layer updates, closely matching the multi-layer investigation required here.

3. Effort & Uncertainty

Investigation Heavy:
A significant portion of the effort is dedicated to triage and root-cause analysis. Initial findings indicate an environment misconfiguration was a primary factor, but the acceptance criteria also require lead recovery and documentation of the remediation steps.

Deployment Coordination:
The fix involves updating deployment instructions for cloud environments and coordinating a release of the updated lead-processing service, adding testing and validation overhead.

4. Testing Requirements

• Validation must be performed across multiple affected client accounts to ensure the fix works system-wide.
• Recovery or re-ingestion of failed leads during the outage window introduces additional data-integrity testing requirements.

Summary of Work

Backend

• Verify and correct API connection strings and environment-specific configurations.

Database

• Audit provider mapping tables and lead-domain configuration records for inconsistencies.

DevOps

• Update deployment pipelines and operational documentation.

Data Recovery

• Recover and reprocess leads that failed during the outage window.
  
  

I now want to add this Agent into a Flow, with my thinking being that when a label is added to a story, the agent runs and set the story point field on the issue and then posts its rationale as a comment to the story. I have built the agent so that it can do these things, but I believe it requires user confirmation. 

Here's my question: when I am building the flow to do this, I am only given the ability to capture the agentResponse - does this mean I need to use my agent twice (as described below):

1. on value change for label (meets my criteria) take action

2. use custom rovo agent to estimate, in the prompt, specify that the output must be numerical only 

3. edit work item, set story points = agentResponse

4. use the same agent again (hoping that it never produces a different result set to the first run lol) and on this prompt, allow it to pass entire response, with rationale

5. edit work item, post comment with agentResponse

I'm just concerned about running the agent twice for the same thing - does this make sense??

[Ben Spillane]

Hi Rick, 

From what you've shown here, your agent looks to be producing some excellent rationale in it's response.

I see a few options available that I'd try:

1. Parse the story points from the agentResponse
   • Ensure your agent will provide at least the consistent story point estimate as displayed in your example: "Estimate: 5 Story Points"
   • Based on the expected format of the agentResponse it shouldn't be too hard to consistently pull out the story point estimate from the response.
   • You could then update your work item subsequently with the extracted story point estimate.
   • The agentResponse could then be added as a comment in a subsequent flow action.
2. Multiple agent invocations is another option.
   • Your agent could make use of sub-agents (scenarios) to provide a simple estimate as the only response data (as you've suggested). Your prompt to the agent should trigger this sub-agent accordingly.
   • A subsequent agent invocation could provide rationale for the estimate. Optionally you could supply the estimate previously provided as additional context in the prompt.

I look forward to hearing how you go with this idea. It looks like a nifty use of agents.

Cheers, 

Ben

[Rebekka Heilmann _viadee_]

I'd second Ben on the first approach. Make sure that the Agent Response always starts with the number of Story points in the same format. You can parse those out the Agent response and post the whole response as a comment.

With invoking the Agent twice I'd have the same concern as you, Rick. Although Rovo has been getting much better at consistency.