# ASSETS - Exploration of Prefect Assets in Slackbot

## What We Learned

Starting from Jake's PR example, we discovered the basic syntax for Prefect Assets:

```python
from prefect.assets import Asset, materialize

# Define assets
ASSET_A = Asset(key="some://uri/a")
ASSET_B = Asset(key="some://uri/b")

# Create materialization with dependencies
@materialize(ASSET_B, asset_deps=[ASSET_A])
async def create_b_from_a():
    # This function materializes ASSET_B, which depends on ASSET_A
    pass
```

Key discoveries:
- Assets are URI-like identifiers representing materialized data
- `@materialize` decorator creates `MaterializingTask` instances that emit asset events
- `asset_deps` parameter establishes dependencies between assets
- `add_asset_metadata()` can only be called from within a materialization context
- Asset metadata includes user-defined properties plus automatic tracking

## The Square Peg Problem

Our initial attempts to map assets onto the Slackbot revealed a fundamental mismatch:

1. **Forced Dependencies**: We created `SLACK_MESSAGES → USER_FACTS` but this felt artificial. The agent extracts facts from conversations, but the dependency isn't really about data transformation - it's about context.

2. **Granularity Mismatch**: Assets seem designed for batch data processing (like ETL pipelines), while the Slackbot operates on individual messages and facts in real-time.

3. **Missing Evolution**: The real value in the Slackbot is how knowledge compounds over time. Facts from different conversations combine to form richer understanding. But assets track point-in-time materializations, not evolution.

## Current Implementation

We settled on a simple two-asset chain:
- `CONVERSATION`: Represents a Slack thread
- `USER_FACTS`: Facts extracted from conversations

This works but feels unsatisfactory because:
- The dependency is weak (facts don't really "transform" from conversations)
- We're not capturing the interesting part: how facts relate to each other
- Assets are just metadata wrappers around our existing vector store operations

## Better Uses We Could Explore

### 1. Research Cache as Assets
```python
DOCS_QUERY = Asset(key="research://query/{hash}")
RESEARCH_RESULT = Asset(key="research://result/{hash}")

@materialize(RESEARCH_RESULT, asset_deps=[DOCS_QUERY])
async def research_topic(question: str) -> ResearchFindings:
    # This makes more sense - research results truly depend on queries
    # Could cache expensive research operations
```

### 2. Knowledge Graph Evolution
```python
# Track how understanding evolves
FACT_v1 = Asset(key="knowledge://user/{user_id}/fact/{fact_id}/v1")
FACT_v2 = Asset(key="knowledge://user/{user_id}/fact/{fact_id}/v2")

# v2 depends on v1 - shows knowledge refinement
```

### 3. Conversation Summaries
```python
THREAD = Asset(key="slack://thread/{thread_ts}")
SUMMARY = Asset(key="summaries://thread/{thread_ts}")
FACTS = Asset(key="facts://thread/{thread_ts}")

# Both summary and facts depend on thread
# This better represents actual data flow
```

As an initial step, the Slackbot now materializes a `THREAD_SUMMARY` asset
whenever a conversation progresses. The summary depends on the `CONVERSATION`
asset representing the Slack thread, creating a chain:

```
CONVERSATION -> THREAD_SUMMARY -> USER_FACTS
```

This allows future assets to build on the evolving thread summary.

### 4. Model Outputs as Assets
```python
USER_QUESTION = Asset(key="questions://user/{user_id}/{timestamp}")
MODEL_RESPONSE = Asset(key="responses://model/{model_id}/{timestamp}")
FEEDBACK = Asset(key="feedback://response/{response_id}")

# Track model performance and feedback loops
```

## The Real Insight

Assets work best when there's actual data transformation or expensive computation to track. The Slackbot's value isn't in transforming data but in accumulating context. Maybe what we really need isn't asset tracking but:

1. **Event Sourcing**: Track every interaction as an event
2. **Knowledge Graphs**: Model relationships between facts
3. **Temporal Tracking**: Show how understanding evolves
4. **Provenance**: Track which conversations led to which insights

Assets feel like they're designed for "I turned CSV A into Dashboard B" not "I learned fact X which refined my understanding of fact Y."

## Future Directions

Instead of forcing assets onto chat interactions, we could:
1. Use assets for expensive operations (research, embeddings, summaries)
2. Track model fine-tuning or evaluation datasets as assets
3. Create assets for exported knowledge (e.g., "everything I know about user X")
4. Use assets for batch operations on conversation history

The key is finding places where there's real materialization happening, not just storage.