Local catalog snapshot · 2026-08-19
AI APPLICATION / AGENT WORKFLOW CASE · 2025—2026
MusicFlow
From one idea to a releasable music asset
- Role
- Owner / workflow product / AI Builder
- Time
- 2025-2026 · Ongoing
- Platforms
- Intent / Generation / Scheduling / Processing / Review / Release
I rebuilt a music-production process that demanded daily supervision and repeated cross-device work into a long-running system with state, boundaries, and human judgment.
01 / VERIFIED OUTCOME
The result first: this is not a concept prototype
- In three seconds: this AI music production system has run independently for more than a year and moved 1,138 structured songs into the public catalog.
- Figures come from local directories and file scans dated 2026-08-19. The catalog contains released and scheduled assets, not universal platform availability.
Includes released and scheduled assets
80%
70%
data files
candidate generation inputs
task-state records
one observed run
The local catalog and current public site use different scopes; catalog assets are not all presented as released.
These figures describe structured catalog assets, not universal availability across every platform.
Candidate inputs for generation
26%
6.3%
Candidate tasks are not executed tasks, accepted results, or released results. The funnel shows conversion, not full automation.
The current public catalog: 119 releases, five listening platforms, and an evolving body of work.
02 / PROBLEM & BEFORE
Generation is fast; production is slow
- The real cost is never one generation click; it is the full chain of intake, quota waiting, repeated submission, download, renaming, archiving, auditioning, forms, and retries.
Ideas waited for the desktop; quota windows needed supervision; device state was fragmented; failures often meant restarting.
Spoken ideas enter the queue; status drives execution; progress returns across devices; recoverable steps keep their work; attention moves to listening and release.
The redesign moves human attention from repetitive operation back to creative judgment.
Generating a track takes minutes, but downloading, splitting stems, renaming, archiving, comparing, and filling forms can eat an entire evening.
Ideas arrive when only a phone is at hand; by the time I am back at the desk, the exact flavour is gone.
Generation quota comes in windows; a missed window wastes a day of capacity.
NetEase and DistroKid expect different metadata shapes, creating dozens of manual fields per album.
A machine cannot hear which take is good or pick the right cover.
Creator-reported: formerly 0.5–1 hour daily, peaking at 3–5 hours; now roughly 3–5 minutes. This remains a baseline awaiting instrumentation.
FIVE REAL PAIN POINTS
The project starts from places where I personally got stuck.
03 / ARCHITECTURE
One map clarifies what the person, Agent, and system own
- The goal is not to automate every step, but to identify work that is verifiable and replayable while leaving sound and release judgment to a person.
- Automation does not replace taste; every production write needs an explicit boundary, task identity, receipt, and idempotency.
Spoken idea → structured request → production plan
Quality gate → quota-aware queue → generation → status receipt
Local processing → human curation → platform preparation → approval
IDEA → ASSET → CATALOG → RELEASE
Three lanes clarify intent and planning, governed production, and curation and release—along with who owns each step.
04 / PRODUCT DECISIONS
Three decisions that matter more than which AI was used
- The product value is not the number of models or scripts, but whether responsibility, state, and failure semantics can run over time.
A track does not end at generation; state becomes the entry to the next action.
The system prepares while sound, artwork, and release remain human judgments.
Explicit modes, authorization, task identity, receipts, and idempotency define the production boundary.
PRODUCT DECISIONS
The product value lies in three choices: asset lifecycle, quality ownership, and execution boundaries.
Machines carry repeatable, checkable steps.
The system prepares; a person handles exceptions.
Taste and final selection remain human.
AUTOMATION BOUNDARY
This boundary defines where automation helps and where human judgment stays essential.
05 / REAL INTERFACES
Four real interfaces, each answering one question
- The screenshots are evidence for orientation, cross-device feedback, runtime intervention, and human curation; each interface maps to one product decision.
Question 01 · Where is today blocked? Inventory, task capacity, local assets, and workflow position come before execution.
Question 02 · Can the person leave the computer and still know what happened? Notifications are a control mechanism, not an add-on.
Question 03 · Has automation become a black box? Manual and background tasks stay beside logs, result folders, and stop controls.
Question 04 · Where should human attention go? Listen first, then inspect metadata; states are work queues, not decoration.
06 / METRICS & SCOPE
After the large numbers comes scope and traceability
- Audited facts, creator recall, and future instrumentation stay separate so task counts do not replace finished assets and best cases do not become long-term efficiency.
142 album records, 1,138 structured assets, 912 with lyrics, and 801 with ISRC.
Previously 0.5–1 hour daily, peaking at 3–5 hours; now roughly 3–5 minutes. Not converted into an efficiency percentage before continuous measurement.
Audited facts stay separate from personal recall so a best-case result does not become a long-term efficiency claim.
P50
min / day
%
%
%
%
%
¥ / item
Planned instrumentation spans queue, PromptPack, generation, review, and release; cost remains null rather than estimated.
Uninstrumented metrics remain empty rather than being presented as completed evidence.
Supported by the local catalog scan.
Supported by runtime views, notifications, and task records.
Creator-reported; instrumentation is still needed.
The catalog includes released and scheduled assets, not universal release.
Sound, artwork, and final release remain human quality gates.
CLAIM BOUNDARY
The figures stay paired with the claims they can and cannot support.
07 / QUALITY & RUNTIME GOVERNANCE
The most valuable iterations came from real failures
- Productizing generative AI is not “retry when it fails”; it is turning failures into defined, graded, regressable product rules.
Two PromptPacks degraded into Topic 01/02 sequences. Parseable JSON is not task success; exit criteria must include semantic diversity and usability.
A structurally complete result may still over-copy historical hooks; duplication fails closed.
Verify promptTrack, language, and model before browser execution rather than trusting documentation alone.
A ten-minute health check spammed alerts during upstream LLM 503s; the task was disabled and alerts need debounce and consecutive-failure thresholds.
Content-language errors are P0, untranslated semantics P1, and source identity P2; a blanket ban is not complete business semantics.
Keep inputs and logs → define error types → classify block/isolate/warn → encode schema/eval/runtime gates → migrate → regress.
QUALITY & RUNTIME GOVERNANCE
Productizing generative AI means turning failures into defined, graded, regressable product rules—not simply retrying.
08 / CAPABILITY BOUNDARY
Be explicit about what runs and what remains partial
- The case separates running, partial, and planned capabilities to avoid presenting a vague “complete system.”
Feishu intake and production path; local processing and asset board; human curation and partial release; backed by source, directories, and run records.
Assisted operation with human quality and exception handling; artwork remains human-confirmed; platform adapters absorb differences.
Weekly inventory detection and complete release packages remain a target state, not a completed capability.
CURRENT CAPABILITY BOUNDARY
Running, partial, and planned capabilities remain explicitly separated.
Experience in depth
Pain points, user stories, and interaction design
Not a tech stack section. This is about the situation people are in, where they get stuck, and what I did about it.
My pain points
Every project here starts from somewhere I personally got stuck.
- P01
Generating a track takes minutes, but downloading, splitting stems, renaming, archiving, comparing, and filling forms can eat an entire evening.
- P02
Ideas arrive when only a phone is at hand; by the time I am back at the desk, the exact flavour I wanted is gone.
- P03
Generation quota comes in windows, and nobody can sit and wait for them — a missed window wastes a day.
- P04
NetEase and DistroKid expect different metadata shapes, so one album means dozens of hand-typed fields.
- P05
Yet full automation would destroy quality — a machine cannot hear which take is good or pick the right cover.
User stories
Written as "as … I want … so that …", each mapped to a verifiable product action.
- US01
As someone with an idea on the move, I want to dictate it and get a trackable PromptPack, so ideas do not depend on being at a desk.
- US02
As a creator on limited quota, I want the system to drain the backlog whenever a window opens, so throughput continues without me.
- US03
As someone with taste requirements, I want one board to audition and mark liked / to-fix / to-release, so attention goes only to judgment.
- US04
As a multi-platform releaser, I want the system to prepare each platform's metadata and leave me the confirmation, so I stop typing dozens of fields.
- US05
As a long-term operator, I want every audio asset to carry an explicit state, so six months later I still know where a track stands.
Experience journey
In real usage order: what they are doing, where it hurts, how the product responds.
StageWhat they are doingFrictionProduct response
01Intake
Dictating a direction inside Feishu.
A manual transcription step sits between the idea and the pipeline, and most ideas die there.
ChatOps turns the dictation directly into a stateful PromptPack in the queue — no admin console required.
02Generate
A quota window opens while requests are still queued.
Watching for quota windows is not realistic, and a missed window wastes a day.
Queue-driven generation drains the backlog when the window opens, with visible processing state.
03Process
Analysis, stem separation, vocals, and timeline work.
Purely mechanical work that still consumes the most time.
Python / shell / Reaper chain the processing steps, and idle machines pick up local post-production.
04Curate
Auditioning takes, fixing flaws, assembling an album.
"Does this sound good" and "which cover" cannot be delegated to a machine.
Music Board carries liked / to-fix / to-release states. The system prepares; the aesthetic call stays human.
05Release
Preparing albums and metadata for NetEase and DistroKid.
Different field conventions on each platform, dozens of manual entries, easy to get wrong.
Per-platform forms and album material are prepared for confirmation, and post-release state is written back to the asset.
Interaction details
The micro-decisions that make it feel fluid or clumsy.
- AUTO / SEMI / MANUAL labels
- Every step declares which tier it belongs to, so it is obvious at a glance where a human is needed.
- State as entry point
- Liked / to-fix / to-release are not tags but work queues — tapping a state moves straight into the next action.
- Dictation enqueues
- A Feishu message is the entry point; no separate back office has to be opened.
- Audition before metadata
- The board plays first and shows fields second, because the order of judgment sets the order of layout.
- Failures are not silent
- A broken processing step returns the asset to its previous state instead of losing it in the queue.
Design details
Tradeoffs in the visual system, state language, and pacing.
- State-driven asset lifecycle
- The interface is organised around asset state from intake to release, not around a generate button.
- An explicit human boundary
- System preparation and human decision are visually separated, so automation never impersonates taste.
- Dense board layout
- The local asset board fits a batch on one screen for fast auditioning and filtering.
- Platform differences absorbed inside
- Per-platform adapters absorb field differences so the interface keeps one operating vocabulary.