Cache

​

Overview

​

Configuration

• Configure caching at task level using the cache property.
• Enable caching with the enabled field.
• Specify the cache location with the path field. Jinja templates can be used to dynamically generate paths.
• The cache format can be sql or json, depending on the task type (whether it generates SQL or JSON output - JSON is commonly used for structured output from the agent).

​

Core Components

​

Example

tasks:
  - name: sql
    type: agent
    cache:
      enabled: true
      path: output/cache/groupings_{{grouping_value}}.sql

​

Referencing Cached Queries

steps:
  - name: report
    type: agent
    prompt: |
      Generate a detail {{schedules.value}} report using {{metrics.value}} metrics:
      {{table}}. Retain the Jinja but treat it as if they are strings, so '{{ }}'.
    agent_ref: agents/local.agentic.yml
    cache:
      path: output/agent.sql

  - name: metrics
    type: loop_sequential
    values:
      - "responses"
      - "rejected"
    steps:
      - name: report
        type: execute_sql
        sql_file: output/agent.sql

• The report task generates a query and caches it in output/agent.sql.
• The metrics loop references the cached query in the execute_sql task.

​

Benefits

• Efficiency: Saves time by reusing cached results.
• Reusability: Cached data persists across runs.
• Debugging: Provides snapshots of intermediate outputs.
• Task Interoperability: Cached queries can be referenced in subsequent tasks, enabling seamless integration between tasks.

​

Best Practices

1. Use descriptive, unique paths to avoid conflicts.
2. Include the workflow name or a unique identifier as part of the cache file path to ensure clarity and avoid overwrites.
3. Regularly clean up outdated cache files.
4. Validate cached results for consistency.
5. Add the cache folder to .gitignore to avoid committing cached files.

​

Related Documentation