Providing Resources to Other Modules

A key feature of Genbase is the ability for Modules to collaborate by sharing resources. As a Kit developer, you define what your Kit is capable of sharing in the provide section of your kit.yaml. This allows Modules created from your Kit to grant specific capabilities or data access to other Modules. (See Provide Concept).

The provide Section in kit.yaml

The optional top-level provide key in kit.yaml is where you declare the resources your Kit makes available for sharing.

# kit.yaml (snippet)
 
# ... (id, version, name, owner, etc.)
 
provide:
  # --- Tools shared by this Kit ---
  tools:
    - name: "lookup_user_id" # Name the consuming agent will use
      path: "user_service:get_id_by_email" # Function in tools/user_service.py
      description: "Looks up a user ID based on their email address."
    - name: "validate_token"
      path: "auth:verify_token" # Function in tools/auth.py
      description: "Validates an authentication token."
 
  # --- Instructions shared by this Kit ---
  instructions:
    - name: "api_guidelines"
      path: "guides/provider_api_usage.md" # File in instructions/guides/
      description: "Best practices for interacting with this Kit's provided tools."
 
  # --- Workspace sharing declaration ---
  workspace:
    description: "Provides read-only access to the user data cache files."
    # Note: No 'files' list here; providing workspace grants access to the whole repo.

Definable Resources

You can define the following under the provide key:

1. tools (Optional, List of Objects):

   • Declares Kit Tools that consuming Modules can invoke.
   • The structure for each tool (name, path, description) is identical to defining tools within profiles.
   • Crucially: When a consuming Module's Agent calls a provided tool, the tool code executes in an isolated Docker container using the Provider Module's environment variables, dependencies, and workspace context. Only the result is returned to the consuming Agent.

2. instructions (Optional, List of Objects):

   • Declares Instruction Files that provide context about the shared resources.
   • The structure (name, path, description) is identical to defining instructions within profiles.
   • This information can be made available to the consuming Module's Agent to help it understand how to use the provided Tools or interpret the provided Workspace content.

3. workspace (Optional, Object):

   • If this object exists (even if empty, {}), it signifies that Modules created from this Kit can share their entire Workspace.
   • When Module A provides its workspace to Module B, Module A's Git repository is added as a read-only Git submodule inside Module B's repository, typically at /repo/workspaces/{module_a_id}/.
   • description: (Optional, String) Briefly describes the purpose or content of the shared workspace.

How Consumers Use Provided Resources

• Establishing the Link: A user or administrator must explicitly create the ModuleProvide link between two running Module instances using the Studio UI (Managing Provisions) or the API. Simply defining resources in provide doesn't automatically link modules.
• Consuming Tools: Once Module A provides an Tool (e.g., lookup_user_id) to Module B, that tool name becomes available as a potential tool call for Module B's Agent when it interacts with its Profiles. The Agent's set_context method (potentially via IncludeOptions(provided_tools=True)) can be configured to include these provided tools in the list of tools passed to the LLM.
• Consuming Workspace: Once Module A provides its Workspace to Module B, any Tool executed by Module B can access the files within Module A's workspace by reading from the path /repo/workspaces/{module_a_id}/... inside its Docker execution container.
• Consuming Instructions: Instructions defined in the provide section of Module A's Kit can be included in the profile_data.instructions list passed to Module B's Agent, providing context on how to use Module A's provided resources.

Defining resources in the provide section is how you turn your Kit from a standalone capability into a collaborative component within the larger Genbase ecosystem.