Consider merging tool calling loop logic between genui_google_generative_ai and genui_firebase_ai

[jacobsimionato]

https://github.com/flutter/genui/tree/main/packages/genui_firebase_ai and https://github.com/flutter/genui/tree/main/packages/genui_google_generative_ai have a lot of similar logic, e.g. the tool loop.

Ideally, they would be structured like:

• genui: contains some LocalAgent utility which implements generic agent loop etc in Dart
• genui_google_generative_ai implements a thing that can make an inference via the REST API, do conversion of types etc.
• genui_firebase_ai the same for Firebase AI Logic

Deduplicating this code will allow us to put more effort into the local agent pattern which could be helpful for some customers, because we will centralize this logic. For example, what if we want to abandon tool calling and use regular unstructured output instead, with error correction etc?

[jacobsimionato]

Coding agent prompt:

Feasibility Report from Gemini

Summary of the Request

The issue proposes to deduplicate the tool-calling and agent loop logic currently present in both the genui_firebase_ai and genui_google_generative_ai packages. The goal is to create a centralized, generic LocalAgent utility within the core genui package. This would abstract the tool-calling loop, while the specific AI packages would only be responsible for the API communication and type conversions, leading to better maintainability and focused development on the core agent pattern.

Analysis of Affected Areas

My analysis of the codebase confirms the issue's premise. The following files contain significant duplicated logic for managing the tool-calling loop:

• packages/genui_firebase_ai/lib/src/firebase_ai_content_generator.dart: The private _generate method in FirebaseAiContentGenerator contains a while loop that handles sending content to the model, processing FunctionCall responses, invoking the corresponding AiTool, and sending the results back to the model until a final answer is produced.

• packages/genui_google_generative_ai/lib/src/google_generative_ai_content_generator.dart: The _generate method in GoogleGenerativeAiContentGenerator contains a nearly identical while loop with the same responsibilities.

The primary differences between these implementations are isolated to:

1. The specific client library used (firebase_ai vs. google_cloud_ai_generativelanguage_v1beta).
2. The data model classes for content, parts, and tools.
3. The schema adapter used to convert json_schema_builder schemas to the format required by the respective backend.

The core flow—prepare tools, generate content, check for tool calls, execute tools, repeat—is the same.

High-Level Implementation Proposal

To address this, I propose creating a generic agent that orchestrates the tool-calling loop, delegating the backend-specific communication to an adapter.

1. Create a ModelAdapter Interface (in packages/genui)
   A new abstract interface will be created to abstract the operations specific to each AI backend.

   File: packages/genui/lib/src/local_agent/model_adapter.dart

   // Simplified concept
   abstract interface class ModelAdapter<TTool, TContent, TResponse> {
     // Adapts generic AiTools to the backend-specific tool format.
     List<TTool> adaptTools(List<AiTool> tools);
   
     // Converts generic ChatMessages to the backend-specific content format.
     List<TContent> convertMessages(Iterable<ChatMessage> messages);
   
     // Calls the AI model to generate content.
     Future<TResponse> generateContent(List<TContent> content);
   
     // Processes the model's response to extract tool calls and text.
     ModelTurnResult processResponse(TResponse response);
   }

2. Create a Generic LocalAgent (in packages/genui)
   This new class will contain the shared tool-calling while loop. It will be initialized with a concrete ModelAdapter.

   File: packages/genui/lib/src/local_agent/local_agent.dart

   // Simplified concept
   class LocalAgent {
     final ModelAdapter adapter;
     // ... constructor ...
   
     Future<Object?> execute(Iterable<ChatMessage> messages) {
       // The shared while loop logic from the _generate methods will live here.
       // It will use the adapter for all backend-specific operations.
     }
   }

3. Implement Concrete Adapters in AI Packages
   Each AI package will provide a concrete implementation of the ModelAdapter interface.

   • packages/genui_firebase_ai/lib/src/firebase_model_adapter.dart: This class will wrap the firebase_ai client, GeminiContentConverter, and GeminiSchemaAdapter.
   • packages/genui_google_generative_ai/lib/src/google_model_adapter.dart: This class will wrap the google_ai service, GoogleContentConverter, and GoogleSchemaAdapter.

4. Refactor ContentGenerator Implementations
   The existing FirebaseAiContentGenerator and GoogleGenerativeAiContentGenerator classes will be simplified significantly. They will now delegate the core work to the new LocalAgent.

   • The _generate, _setupToolsAndFunctions, and _processFunctionCalls methods will be removed.
   • The sendRequest method will instantiate the LocalAgent with the appropriate adapter and call its execute method.

Complexity and Potential Risks

• Complexity: Medium. The primary challenge lies in designing a robust ModelAdapter interface that cleanly abstracts the two distinct Google AI SDKs without becoming overly complex. The generic LocalAgent must also be carefully designed to handle all facets of the tool-calling loop (e.g., forced tool calling, error handling) in a backend-agnostic way.

• Potential Risks:

  • Leaky Abstraction: The ModelAdapter could become a leaky abstraction if the differences between the two SDKs are too great, forcing backend-specific logic into the generic LocalAgent.
  • Testing Overhead: This is a significant refactoring that touches three packages. All existing tests for both content generators will need to be updated, and new tests for the LocalAgent and adapters must be written to ensure no regressions are introduced.

Estimated Level of Effort

Medium

This is a valuable architectural improvement that will improve code quality and maintainability. While not a trivial change, it is a well-understood refactoring task. The effort involves careful API design for the new abstractions, implementation across three packages, and a thorough update of the corresponding tests.

[gspencergoog]

This sounds good to me.

[sethladd]

should we tell Jules to make a PR for this? Seems Jules-able