Redundant Data Retrieval

[hshang315]

Redundant Data Retrieval for Previously Fetched Time Ranges

Problem

The framework always retrieves data from the archiver/SDDS even when the same data for the same time range has already been retrieved earlier in the conversation. This causes unnecessary API calls and delays, especially for large time ranges or multiple channels.

Current Behavior

1. User asks: "Plot SR beam current and SR correctors from 10/10/25 to 10/12/25"
2. Framework retrieves data from archiver → creates plot successfully
3. User asks: "Please make the correlation plot between the SR correctors and SR beam current"
4. Framework correctly remembers the time range (10/10/25 to 10/12/25)
5. But it retrieves the same data again from the archiver instead of reusing the previously fetched data

The framework is smart enough to remember the time range context, but it doesn't reuse the already-retrieved data.

Expected Behavior

The framework should:

1. Cache retrieved archiver data in the conversation state
2. Check if requested channels and time range overlap with previously fetched data
3. Only fetch new data for channels/time ranges not already in cache
4. Reuse cached data when the same channels and time range are needed for follow-up analysis (e.g., correlation plots, different visualizations)

Suggested Implementation

• Add a data cache to the conversation state that stores:
  • Channel name
  • Time range (start, end)
  • Retrieved data (DataFrame or similar)
• Before calling archiver API, check cache for overlapping data
• Implement cache invalidation strategy (e.g., time-based or explicit refresh)

Impact

• Reduced API calls to archiver appliance
• Faster response times for follow-up queries
• Lower load on archiver infrastructure

---

[thellert]

Thanks for this detailed feedback! We've been investigating this issue.

Current Status:
We were able to reproduce this behavior, though it appeared intermittent - sometimes the orchestrator would correctly reuse cached data, sometimes it wouldn't. This indicated a fragile implementation.

Partial Fix (PR #113):
The issue was partly addressed by #113, which ensured chat history is properly propagated to the orchestrator. This helped in cases where the user explicitly referenced previous data ("same time range", "that data", etc.).

Further Improvements (PR #114):
We've now implemented additional robustness improvements:

1. Context metadata storage: When capabilities store their output context, we now also store the task_objective from the execution plan step as metadata. This gives the orchestrator semantic information about what each cached context was created for.

2. Improved orchestrator prompt: The orchestrator now sees context in the same format used in execution plans:

   {"ARCHIVER_DATA": "historical_beam_data"}: "Retrieve historical SR beam current data from archiver for the last 24 hours"
   

   Instead of just the context key. This ensures consistency between how context is displayed and how it needs to be referenced in the plan.

3. Softened reuse guidance: Changed from requiring "explicit references" to encouraging reuse based on semantic similarity - even when the user doesn't explicitly say "that data".

4. Better prompt organization: Reorganized prompt sections to keep all context-reuse related guidance together, with clearer visual separation of chat history.

See PR #114 for the implementation.