KultureSync: Taskmaster Agent for Regional Music Curation

Inspiration

Mainstream music recommendation platforms operate on an assumption of unmetered broadband and uniform metadata schemas. In South Africa, standard mobile data tariffs average R85 to R120 per gigabyte. As a result, listeners prioritize offline storage and peer-to-peer transfers over active mobile streaming to manage high data costs.

Commercial collaborative filtering engines also compress regional music movements into broad umbrella categories. Distinct South African subgenres—such as Amapiano, Lekompo, Gqom, Bacardi, Motswako, and Maskandi—are routinely grouped into generic labels like "Afrobeats" or "World Music".

Our empirical research pilot ($N=152$ listeners across Johannesburg and Pretoria) evaluated this pattern through the Inversion Problem. Standard recommenders assume completed streams ($B = 1$) reflect unconstrained listener preference ($M$), ignoring how default playlist placements and interface recommendations ($C$) act as confounders:

$$P(B \mid M, C) \neq P(B \mid M)$$

When listeners spend extra data and time searching past these generic defaults for local tracks, they incur an operational and financial Cultural Context Tax ($\tau_c$):

$$\tau_c(u) = \sum_{i \in S_u} \Phi(i) \cdot \mathbb{I}(i \in G_{\text{local}}) - \gamma \sum_{j \in S_u} \Phi(j) \cdot \mathbb{I}(j \notin G_{\text{local}})$$

We built KultureSync as an asynchronous background Taskmaster agent to de-flatten track metadata into authentic local subgenres while protecting user mobile data budgets.


What It Does

KultureSync operates as a decoupled, event-driven background service that ingests music libraries, aligns metadata to regional movements, and protects users from unexpected cellular data usage:

  • Decoupled Background Execution: The client initiates a sync through our FastAPI gateway, which returns an immediate HTTP 202 ACCEPTED handshake. The client disconnects immediately while the agent handles processing asynchronously in the background.
  • Cellular Data-Saver Guard: Before network-heavy steps, the agent inspects network telemetry (WIFI vs. metered CELLULAR). On metered connections, the execution graph raises an ADK 2.0 NodeInterruptedError and pauses execution to prevent mobile data charges.
  • Dual-Engine Cultural Alignment: On unmetered connections (or upon user override), the agent routes tracks to Gemini 3.5 Flash using structured Pydantic schemas. The model reclassifies tracks into specific South African subgenres and calculates cumulative Context Tax ($\tau_c$) saved.
  • Idempotent Session Checkpoints: Progress is committed to Cloud Firestore after each chunk. If the job is interrupted or the container restarts, execution resumes from the last completed track index without repeating earlier inference calls.

How We Built It

  • Agent Engine: Built with the Google Agent Development Kit (ADK 2.0) graph engine as a directed graph of single-responsibility nodes: IngestionNode, DataSaverNode, CulturalAlignmentNode, and HumanInTheLoopNode.
  • Serverless Backend: Deployed on Google Cloud Run (us-central1) in a custom container. We configured --no-cpu-throttling to preserve active background CPU cycles and set --min-instances 1 to eliminate cold starts while maintaining a budget ceiling (--max-instances 3).
  • Database & State Layer: Integrated directly with Google Cloud Firestore (kulture_sync_sessions collection) to manage session states, track indices, and transaction checkpoints.
  • AI & Fallback Core: Primary classification is handled by Gemini 3.5 Flash with structured JSON output schemas, paired with a deterministic, rule-based ethnomusicological fallback engine to maintain zero downtime during rate limits or offline conditions.
  • Telemetry & Logging: Integrated with Google Cloud Logging for OpenTelemetry audit traces and live node lifecycle monitoring.

Challenges and Solutions

Serverless State and Idempotency

Serverless runtimes can terminate mid-sync during large imports, risking duplicate processing and wasted API tokens on restart. We used Firestore as an atomic transaction ledger. Every state transition commits its chunk index immediately, ensuring zero-duplicate recovery across restarts.

Small Pilot Sample Size

Our research pilot ($N=152$) yields a sample-to-feature ratio of $N/p \approx 3.62$, which is insufficient to train custom classifiers without overfitting or amplifying regional sampling skews. We used a dual-engine architecture: Gemini 3.5 Flash handles zero-shot semantic reasoning, while hardcoded regional heuristics manage deterministic edge cases and offline fallbacks.

Cloud Run CPU Throttling

Default serverless configurations throttle container CPU once an HTTP response completes, which halts background graph processing. Deploying with the --no-cpu-throttling flag maintains dedicated CPU allocation until the background pipeline finishes.


Key Results

  • Connected decolonial recommendation theory directly to a working serverless implementation on Google Cloud.
  • Maintained high performance and reliability with zero-downtime fallback heuristics and sub-second classification latency.
  • Implemented network-aware interruption gates that prioritize mobile data conservation over continuous background execution.

What We Learned

  • Adapt existing tools: Rather than asking users to adopt a separate platform, background tools can refine and preserve cultural metadata directly inside their current streaming libraries.
  • Intentional interruptions in agent design: In constrained environments, programmatic pauses (such as raising NodeInterruptedError on metered connections) give users control before automated tasks consume billable network resources.

Next Steps

  • Edge and Peer-to-Peer Sync: Adapt Firestore state checkpoints to work with local peer-to-peer sharing protocols, allowing commuters to sync and verify libraries offline without cellular data usage.
  • Open-Source Rule Base: Expand the fallback heuristics into a community-maintained database of regional subgenre rules for cultural archivists and ethnomusicologists.

Built With

  • adk
Share this project:

Updates

posted an update —

Evolving Local Music Curation: Reflections on My First Iteration and What's Next

When I started for the kulture, my goal was to run a small pilot study to measure how commercial recommendation algorithms flatten distinct South African music subgenres—like Motswako, Gqom, Lekompo, Bacardi, and Maskandi—into generic umbrella categories like "World Music" or "Afrobeats."

To fix this, my first iteration tested custom approaches to correct the categorization. Looking back, this first version was essentially an offline lab experiment: it successfully proved that I could un-flatten these playlists using local scripts. However, I quickly realized that running a static script has major real-world bottlenecks:

  • It can't adapt to changing tastes: A one-time script can't track an evolving music library. Over time, commercial algorithms would just pull the user's recommendations back toward mainstream hits.
  • It breaks if the internet drops: My manual scripts didn't save their progress. If the network dropped, the process failed completely and had to start over from scratch.

What I'm Building Next: A Smart Background Agent

These limitations have completely reshaped how I am approaching the next phase of this research. To make this actually work for people in the real world, I am moving away from heavy, app-blocking local scripts and building a smart, cloud-based background agent.

Here is what I am working on next:

1. Seamless Cloud Processing Instead of making the user wait while their library is processed, the new system (built on FastAPI and Cloud Run) will instantly accept a request and handle all the heavy lifting silently in the background.

2. Network-Aware Data Saving Crucially, I am designing this architecture to respect local data costs. Before downloading or processing a heavy library, the system will check the user's connection. If they are on metered mobile data, it will automatically pause to save them money. It will log its exact progress in the cloud, so when the user reconnects to Wi-Fi, it picks up right where it left off without wasting a single megabyte or repeating work.

3. Continuous Curation with Gemini Behind the scenes, I plan to integrate Gemini to continuously and accurately classify music into authentic subgenres. This background agent will constantly fine-tune the user's recommendations, actively pushing back against the mainstream algorithm so that local artists stay front and center as the user's tastes evolve.

Ultimately, this transition from a static script to a stateful agent is about building something that doesn't just work in theory, but actually respects the user's context, data, and culture.

Log in or sign up for Devpost to join the conversation.

Submission history