# Saravia.io Full LLM Context

This plain-text file contains public Saravia.io pages, resources, and published blog articles for search crawlers and LLM retrieval systems.

## Primary Pages
- Home: https://saravia.io/
- Operator profile: https://saravia.io/operator
- Work: https://saravia.io/work
- Blog: https://saravia.io/blog
- Resources: https://saravia.io/resources
- RSS: https://saravia.io/blog/rss.xml
- LLM index: https://saravia.io/llms.txt

## Public Resources
- Mythic Index skill: https://saravia.io/resources/skills/mythic-index/SKILL.md
- Mythic Index source repository: https://github.com/wizkid17/mythic-index-mcp
- AI Music Prompt Producer skill: https://saravia.io/resources/skills/ai-music-prompt-producer/SKILL.md

## Operator Profile

Name: Renzo Saravia
Canonical URL: https://saravia.io/operator
Person entity ID: https://saravia.io/operator#person
Positioning: Technology Operator building AI-native companies.
Description: Renzo Saravia is a technology operator, former software company founder, engineering executive, and product builder working across the United States and Latin America to build AI-native companies and enterprise technology products.

### Quick Facts
- Co-founded Whiz, a Peru-based software development company focused on agile software development, innovation services, and technology talent for North American customers.
- Whiz was acquired by 10Pearls in 2022, expanding 10Pearls' nearshore delivery capabilities in Latin America.
- Public acquisition coverage identifies Renzo Saravia and Javier Fernandez-Concha as Whiz co-founders.
- The 10Pearls announcement said Javier and Renzo would join 10Pearls with a team of 125 contributors.
- Current work centers on AI-native products, data foundations, cloud platforms, engineering systems, and new ventures.

### Career Timeline
- 2017-2022: Whiz - Co-founder. Built a Peru-based software development and nearshore technology business serving customers in North America and Latin America.
  Evidence: 10Pearls announcement (https://10pearls.com/news/10pearls-acquires-whiz/)
- 2022: Whiz acquisition - Transaction milestone. 10Pearls acquired Whiz, a Peru-based software development company co-founded by Javier Fernandez-Concha and Renzo Saravia.
  Evidence: ChannelE2E coverage (https://www.channele2e.com/news/10pearls-acquires-whiz)
- 2022 onward: 10Pearls - Post-acquisition platform. The acquisition expanded 10Pearls' Latin America delivery footprint and added the Whiz team to its Peru operations.
  Evidence: 10Pearls announcement (https://10pearls.com/news/10pearls-acquires-whiz/)
- Current: Saravia.io - Operator and builder. Building public writing, resources, AI-native product experiments, and reusable workflows around product, data, cloud, and agentic systems.
  Evidence: Saravia.io resources (https://saravia.io/resources)

### Expertise
- AI Product Strategy: Identifying high-value AI opportunities, shaping product hypotheses, and moving from experiments to measurable product workflows.
- Enterprise AI: Connecting data readiness, governance, model choices, evaluation, adoption, and production operations.
- Product Incubation: Turning opportunities into researched, validated, and testable product concepts through structured discovery and implementation loops.
- Engineering Leadership: Designing operating systems, team structures, and delivery practices that help technical organizations scale.
- Data and Cloud Platforms: Establishing technical foundations for analytics, AI, integration, automation, and scalable product development.
- US-LATAM Technology Operations: Building and leading cross-border technology organizations serving US and Latin American markets.

### Selected Work
- Mythic Index: A portable Magic: The Gathering AI skill connected to live MCP tools for rules, card pricing, deck analysis, and collector research. (https://saravia.io/blog/building-mythic-index-portable-ai-skill)
- AI Music Prompt Producer: A public skill for turning stories, references, hooks, and production constraints into prompts for AI music tools. (https://saravia.io/resources/skills/ai-music-prompt-producer/SKILL.md)
- PR Sentinel: A product workflow for keeping pull requests moving across GitHub, Slack, Linear, and quality gates. (https://saravia.io/blog/why-pull-requests-stall-even-with-good-tools)
- Public resources: Agent-ready skills, templates, and workflows designed to make AI systems repeatable instead of one-off experiments. (https://saravia.io/resources)

### FAQ
Q: Who is Renzo Saravia?
A: Renzo Saravia is a technology operator, former software company founder, engineering executive, and product builder working across the United States and Latin America. His current work focuses on AI-native products, enterprise AI, data foundations, and scalable engineering systems.

Q: What is Renzo Saravia known for?
A: Renzo is publicly associated with co-founding Whiz, a Peru-based software development company acquired by 10Pearls in 2022, and with building products and resources around AI systems, product strategy, cloud platforms, and agentic workflows.

Q: What was Whiz?
A: Whiz was a Peru-based software development company focused on agile software development, innovation services, and technology talent for North American customers. Public coverage identifies Renzo Saravia and Javier Fernandez-Concha as co-founders.

Q: What happened to Whiz?
A: 10Pearls acquired Whiz in 2022. The acquisition expanded 10Pearls' nearshore delivery capabilities in Latin America and added the Whiz team to its Peru operations.

Q: What does Renzo build today?
A: Renzo builds and writes about AI-native products, reusable agent workflows, data and cloud foundations, developer tools, and operating systems for turning opportunities into production-ready products.

Q: How can someone contact Renzo Saravia?
A: Use the Saravia.io contact form, email renzo@saravia.io, or connect through the verified LinkedIn profile linked from this site.

### References
- 10Pearls acquires Peru-based software development company, Whiz - 10Pearls. Verifies: Whiz acquisition, company description, co-founders, 125 contributors, and 10Pearls nearshore expansion. URL: https://10pearls.com/news/10pearls-acquires-whiz/
- Custom Software Development M&A: 10Pearls Acquires Whiz - ChannelE2E. Verifies: Independent M&A coverage of 10Pearls acquiring Whiz and naming Javier Fernandez-Concha and Renzo Saravia as co-founders. URL: https://www.channele2e.com/news/10pearls-acquires-whiz
- Whiz acquired by 10Pearls - They Got Acquired. Verifies: Founder story, acquisition timing, growth narrative, team scale, and public operating metrics reported by the publication. URL: https://theygotacquired.com/services/whiz-acquired-by-10pearls/
- Renzo Saravia LinkedIn profile - LinkedIn. Verifies: Public professional identity and profile continuity. URL: https://www.linkedin.com/in/renzo-s-304786bb/

## Published Blog Articles

# Building Mythic Index As A Portable AI Skill

URL: https://saravia.io/blog/building-mythic-index-portable-ai-skill
Published: Jul 10, 2026
Updated: Jul 10, 2026
Tags: AI Systems, MCP, Product, Developer Tools
Description: How I built a Magic: The Gathering AI mentor with a portable skill, MCP tools, and live data for rules, deck building, pricing, and card research.

Magic: The Gathering is a useful stress test for AI agents.

It is not only a game. It is rules, strategy, deck construction, pricing, sealed products, vendor data, formats, bans, market movement, and a large amount of community language that changes over time.

That made it a good place to build something more ambitious than a prompt: a portable AI skill that can teach the game, answer rules questions, build and price decks, and reason about cards as collectible assets.

The project became Mythic Index. The important part is not only that it works for Magic. The important part is the architecture behind it.

<KeyTakeaways items={[
  "A useful AI skill should stay thin: behavior, judgment, workflow, and tool-selection rules.",
  "Live data should stay behind callable tools, especially when prices, rules, and product catalogs change.",
  "The same skill can travel across Codex, Claude, and other MCP-capable agents when the instructions are portable and the data layer is external."
]} />

## The Job I Wanted The Skill To Do

The goal was to create an AI mentor for Magic players and collectors.

I wanted the agent to handle three jobs:

1. Teach new players using the official Comprehensive Rules.
2. Build and price legal decks across vendors.
3. Evaluate cards and sealed products with the right risks visible.

The system now covers:

- **99,000+ cards**
- **971 sets**
- **534,000+ price listings**
- **3,900+ sealed products with EV**
- **5 vendors**: TCGPlayer, Card Kingdom, CardMarket, CardSphere, and CardHoarder
- **21 MCP tools**
- **3,120 Comprehensive Rules**
- **726 glossary terms**

Those numbers matter because this is not a static prompt pretending to know everything. It is an AI skill connected to tools that can fetch current information.

<Figure
  src="/blog/mythic-index-claude-demo.png"
  alt="Claude using the Mythic Index MCP skill to prepare a Commander deck-building request"
  caption="A real Mythic Index session inside Claude. The agent activates the skill and asks to call deck-building tools instead of guessing from memory."
/>

## The Core Pattern

The main design decision was to separate the brain from the data.

The skill should not contain a card database. It should not contain prices. It should not contain the full rules corpus. All of that changes.

Instead, the skill contains behavior:

- When to activate.
- What tools to call.
- How to answer rules questions.
- How to price a deck.
- How to make risk explicit.
- How to avoid answering from stale memory.

The live data sits behind an MCP server and backend.

<Callout>
The skill is the operating model. The MCP server is the tool layer. The backend is the source of live truth.
</Callout>

That separation is what makes the skill portable. It can move across agents because the instructions are lightweight. The data stays current because it is fetched at runtime.

## How Mythic Index Is Built

Mythic Index has three layers.

<Figure
  src="/blog/mythic-index-architecture.svg"
  alt="Architecture diagram showing a portable skill connected to an MCP server and live backend"
  caption="The portable skill decides how the agent should behave. The MCP server exposes the actions. The backend keeps the data current."
/>

The first layer is the **skill**. This is a `SKILL.md` file with instructions for the agent. It defines the role, the activation conditions, the operating rules, and the response style.

The second layer is the **MCP server**. It is a Python server published as `mythic-index-mcp`. It exposes 21 tools through the Model Context Protocol and can run with `uvx mythic-index-mcp`.

The third layer is the **backend**. It holds cards, sets, prices, sealed EV, official rules, glossary terms, and sync jobs.

The flow looks like this:

1. A user asks a Magic question.
2. The skill tells the agent how to interpret the request.
3. The agent calls the right MCP tool.
4. The MCP server queries the backend.
5. The agent answers with live data instead of memory.

That is the product loop.

## What The Skill Tells The Agent

The skill is intentionally opinionated.

For pricing, it tells the agent not to quote prices from memory. Prices change daily, so current market questions must go through tools.

For rules, it tells the agent to search or fetch the official rule and cite rule numbers. A rules assistant should not rely on a model's general memory when the official Comprehensive Rules are available.

For decks, it tells the agent to establish format, budget, and goal before recommending cards. Then it can find cards by role, price the list, check legality, analyze the curve, and suggest budget alternatives.

For investing, it tells the agent to make risk explicit: reprints, bans, liquidity, format shifts, and hype cycles.

That matters because the skill is not trying to make the model sound smart. It is trying to make the model behave usefully.

## The 21 Tools

The MCP server exposes tools across seven areas.

| Pillar | Tools |
| --- | --- |
| Prices and cards | `search_cards`, `find_cards`, `browse_cards`, `list_sets`, `get_card_price`, `get_price_history` |
| Sets and sealed | `get_set_stats`, `search_sealed`, `get_sealed_ev` |
| Investment | `top_movers`, `find_arbitrage`, `reserved_list_tracker` |
| Decks | `price_deck`, `suggest_budget_alternatives`, `analyze_mana_curve` |
| Strategy | `check_legality`, `evaluate_card`, `find_cards_by_role` |
| Rules | `search_rules`, `get_rule` |
| System | `get_api_status` |

The first version had 19 tools. Adding rules changed the feel of the product.

Pricing made Mythic Index useful. Rules made it a mentor.

## Teaching The Agent The Official Rules

Magic has many good casual explanations online, but a rules assistant needs the official rules.

So the backend ingests the Comprehensive Rules, parses numbered rules and glossary terms, stores them, indexes them, and exposes lookup endpoints. The MCP server wraps those endpoints as `search_rules` and `get_rule`.

That lets the agent answer questions like:

```text
Explain how deathtouch and trample interact. Cite the actual rule.
```

The correct behavior is not to answer from memory. The correct behavior is to search the rules corpus, fetch the relevant rule, explain it plainly, and cite the rule number.

This is the broader lesson: if a domain has a source of truth, give the agent a path to that source of truth.

## Decks Need Workflow, Not Just Data

Deck building is more than card search.

A good deck request needs context:

- Format.
- Budget.
- Commander or archetype.
- Power level.
- Color identity.
- Cards the user already owns.
- Competitive or casual expectations.

The skill handles this by guiding the agent through a workflow instead of dumping generic recommendations.

For example, if someone says they want a high-power Commander deck, the agent should ask for the commander or strategy, confirm color identity, search for role players, price the list, check the curve, and explain tradeoffs.

The MCP server does not need to host every decklist in the world. It needs to make a decklist actionable once the user brings one in or chooses a direction.

That is an important product decision. The value is not owning all possible content. The value is turning the user's intent into a concrete decision.

## The Process Lessons

The build had several lessons I would repeat in other AI products.

### Check The Runtime Early

The MCP server needed Python 3.10+. The environment I started with did not match that requirement, so the server had to run in a newer Python environment.

This is basic, but it matters. Agent tools are still software. They fail for normal software reasons.

### Expect SDK Drift

Small API differences can break the server before any tool is called. The practical habit is to test the server construction path, not only individual tool functions.

For AI tooling, the surface area changes quickly. Treat docs, packages, and examples as things to verify.

### Test The Product Claim

If a system says it has limits, syncs, access rules, or freshness guarantees, test those claims directly.

For Mythic Index, that meant checking tool startup, rules lookup, pricing calls, rate behavior, and production deploy order.

This is the difference between a demo and a usable capability.

### Deploy In Dependency Order

Rules tools depend on rules data. Pricing tools depend on pricing data. A backend can be deployed correctly and still not be ready if the required data has not been ingested.

The deploy sequence matters:

1. Ship the backend behavior.
2. Ingest or sync the data.
3. Publish the tools that depend on that data.
4. Test from the agent, not only from the API.

### Keep The Skill Portable

The most important lesson was the simplest one.

Do not put the live world inside the skill.

Put the operating behavior in the skill. Put live facts behind tools. That is what lets the same capability work across different agents.

## How To Try It

You need Python 3.10+ and [`uv`](https://docs.astral.sh/uv/).

For Codex, add this to `~/.codex/config.toml`:

```toml
[mcp_servers.mythic-index]
command = "uvx"
args = ["mythic-index-mcp"]
startup_timeout_sec = 120
```

Then install the skill by copying the [Mythic Index `SKILL.md`](/resources/skills/mythic-index/SKILL.md) file into:

```text
~/.codex/skills/mythic-index/SKILL.md
```

For Claude Code:

```bash
claude mcp add mythic-index uvx mythic-index-mcp
```

Claude Desktop can use the release package, or the same `uvx mythic-index-mcp` command in its MCP config.

Useful links:

- [Mythic Index MCP on PyPI](https://pypi.org/project/mythic-index-mcp/)
- Repository: [wizkid17/mythic-index-mcp](https://github.com/wizkid17/mythic-index-mcp)
- MCP Registry identifier: `io.github.wizkid17/mythic-index-mcp`
- Run command: `uvx mythic-index-mcp`

<Callout>
If you play Magic, try the skill on one real question: a rules interaction, a decklist, or a card you are considering buying. The useful part is seeing the agent call tools instead of guessing.
</Callout>

## What This Means Beyond Magic

Magic is just the domain I chose.

The same pattern applies to many specialized AI products:

- Legal research.
- Procurement.
- Healthcare operations.
- Financial analysis.
- Developer tools.
- Customer support.
- Internal company knowledge.

The question is always the same:

1. What should live in portable instructions?
2. What should be a callable tool?
3. What data must stay live?
4. What should the agent never answer from memory?

For Mythic Index, the answer was clear.

The skill is the behavior. The MCP server is the capability. The backend is the truth.

That pattern is portable. That is the part worth reusing.

<FAQ items={[
  {
    question: "Do I need my own API key?",
    answer: "No. The package is designed to work with a public read-only path for the live backend."
  },
  {
    question: "Does it work offline?",
    answer: "No. The skill is portable, but the data is live. It needs network access for current prices, rules, sealed EV, and tool responses."
  },
  {
    question: "Which agents does it work with?",
    answer: "Any agent that can use MCP tools can run the server. The skill file can be used as a Codex skill, a Claude Agent Skill, or Claude Project instructions."
  },
  {
    question: "Is this investment advice?",
    answer: "No. Mythic Index can surface market data, price movement, sealed EV, and risks. It should be treated as research support, not financial advice."
  }
]} />

---

# Why Pull Requests Stall Even With Good Tools

URL: https://saravia.io/blog/why-pull-requests-stall-even-with-good-tools
Published: Jun 22, 2026
Updated: Jun 22, 2026
Tags: Developer Tools, DevOps, Product, Platforms
Description: A practical look at repository review operations, PR ownership tracking, and how PR Sentinel keeps pull requests moving across GitHub, Slack, Linear, and quality gates.

Most pull requests do not stall because the team lacks tools.

They stall because ownership becomes unclear.

A pull request is open. The checks are running, or maybe one failed. A reviewer was requested, but nobody knows whether the next move belongs to the reviewer, the author, the CI owner, or the person allowed to merge. Slack has messages, GitHub has events, Linear has a status, and the delivery conversation is somewhere else.

The result is familiar: work that is technically visible still becomes operationally invisible.

That is the problem PR Sentinel is built around. It is a repository review operations layer for keeping pull requests and merge requests moving from open to merged by making the current owner and next action explicit.

You can request access here: [PR Sentinel workspace access](https://notificator.saravia.io/#access-request).

## Quick Takeaways

1. Pull request automation is not only about sending alerts. It is about assigning ownership to the next action.
2. Code review workflow automation works better when repo events, quality gates, chat notifications, and project status share one state model.
3. PR Sentinel does not replace GitHub, Slack, CI, or Linear. It coordinates the handoffs between them.

## The Problem Is Not Visibility

Engineering teams already have visibility.

GitHub shows the pull request. CI shows the checks. Slack shows notifications. Linear shows the project ticket. Review tools show comments, suggestions, findings, and quality gates.

The problem is that each tool is usually correct only inside its own boundary.

GitHub can show that a review is requested, but not always whether the team has acknowledged the handoff. CI can show that a check failed, but not always who owns the fix. Slack can notify a channel, but noisy channels often become a place where accountability disappears. A project-management ticket can say "in review" while the actual pull request is waiting on author fixes or merge approval.

That gap is where pull requests get stuck.

## Repository Review Operations

Repository review operations is the operating layer between code hosting, quality gates, team chat, and project management.

The useful question is not only "what happened to this pull request?"

The better question is:

Who owns the next action right now?

That owner can change several times before a pull request is merged:

1. The author opens the pull request.
2. Automated checks or review gates need to run.
3. A human reviewer needs to review.
4. The author needs to respond to requested changes.
5. A merger needs to merge once the work is ready.
6. The project-management system needs to reflect the real engineering state.

If those transitions are implicit, the team depends on memory, goodwill, and someone manually noticing that the work is stuck.

<Callout>
The missing layer in many review workflows is not another notification. It is an owner-state model that says who should act next.
</Callout>

## What PR Sentinel Does

PR Sentinel watches repository review activity and classifies the current owner state of the work.

It can track whether a pull request is waiting on automated checks, human review, author fixes, merge readiness, or completion. From there, it routes the right message to the right place and keeps the project-management state aligned.

The live product focuses on a practical operating loop:

1. A GitHub pull request changes state.
2. PR Sentinel reconciles the review state, check state, and draft-ready state.
3. The system determines who owns the next action.
4. Slack receives the relevant handoff, escalation, digest, infrastructure, or test notification.
5. Linear is synchronized to statuses such as pending review, in review, changes requested, ready to merge, and done.
6. Repo-level configuration controls reviewers, mergers, channels, SLAs, business hours, digests, and notification behavior.

That makes PR Sentinel less like a replacement for existing tools and more like an operations layer across them.

## Why Tool-Specific Alerts Are Not Enough

A normal alert says something happened.

An operating signal says what should happen next.

That distinction matters because teams do not only need more information. They need fewer ambiguous handoffs.

For example, a failed quality gate from SonarQube, SonarCloud, CodeRabbit, Codacy, CodeQL, Greptile-style checks, or another GitHub check is useful. But the next operational question is: does this block review, require author fixes, require infrastructure attention, or simply need to be included in the daily digest?

The same applies to human review. A requested review is not the same as an acknowledged review. A review with changes requested is not the same as work ready to merge. A merged pull request is not the same as a project ticket that has been moved to done.

PR Sentinel turns those differences into workflow states.

## The Per-Repo Advantage

One-size-fits-all automation usually fails because every repository has a slightly different operating rhythm.

Some repositories need strict review SLAs. Some need quieter notifications. Some need escalation only inside business hours. Some have dedicated mergers. Some use automated review gates heavily. Some need daily digests more than real-time messages.

PR Sentinel handles that at the repo level.

That is important because review operations should fit the repo's delivery model, not force every repo into the same policy. Platform and developer-experience teams can still create consistency, but individual repositories can keep the configuration that matches their work.

## What Is Live Today

The current live integrations are focused and intentional:

1. GitHub for app installation, webhook intake, pull request state tracking, review reconciliation, and draft-ready synchronization.
2. Slack for handoffs, escalations, digests, infrastructure notifications, and test notifications.
3. Linear for project status synchronization.
4. GitHub checks and review gates for quality signals.
5. AWS serverless infrastructure for the production runtime.

Future adapters such as GitLab, Bitbucket, Jira, Asana, Azure Boards, Microsoft Teams, Google Chat, and additional CI or quality tools are natural opportunities, but they should be treated as adapter paths rather than shipped production integrations today.

## Why Access Is Gated

PR Sentinel is not fully self-serve yet. Teams request access from the public page, the workspace is reviewed, and tenant owners are provisioned before they connect integrations.

That is intentional.

Repository review operations touches code, team communication, project-management state, secrets, installation permissions, and operational policy. Early rollout benefits from controlled onboarding, clear tenant ownership, and a deliberate security posture.

For developer tooling, especially multi-tenant developer tooling, controlled access is not a weakness. It is often the right way to learn safely before broadening distribution.

## A Simple Test For Your Review Workflow

If you want to know whether your team needs a repository review operations layer, ask three questions:

1. Can anyone tell who owns the next action on every open pull request?
2. Do Slack notifications make review work clearer, or just louder?
3. Does project status reflect real review state, or someone's best guess?

If those answers are uncomfortable, the problem is probably not the quality of your tools.

It is the handoff between them.

PR Sentinel exists to make that handoff explicit: from open to checked, reviewed, fixed, ready, merged, and reflected in the system the team uses to run delivery.

You can request a workspace here: [notificator.saravia.io](https://notificator.saravia.io/#access-request).

---

# How To Use AI To Create Music: A Producer Workflow

URL: https://saravia.io/blog/how-i-use-ai-to-create-music
Published: Jun 18, 2026
Updated: Jun 18, 2026
Tags: AI Systems, Music Production, Creativity, Product
Description: A practical tutorial for turning stories, references, and taste into released AI-assisted songs using an LLM, music generators, critique, editing, and release packaging.

I have always wanted to make music.

Not only as the person in front of the microphone, but as a producer: the person who can take a story, find its center, choose a sound, build a world around it, and turn it into something other people can feel.

The problem was never a lack of ideas. It was the distance between having a story and being able to convert that story into a finished creative asset. A song requires writing, references, structure, arrangement, vocal direction, iteration, cover art, release metadata, and taste calls at every stage.

AI shortened that distance.

The first real test was `Tu Magia`, a song built around a bottled emotion I had carried for a long time. I did not want to turn it into a diary entry, and I did not want the process to become overly sentimental. I wanted to see if AI could help me convert a lived experience into a professional music brief, then into a song that had personal truth but still worked as a commercial record.

You can listen to the result here: [Tu Magia on Spotify](https://open.spotify.com/intl-es/track/6M5WcQvDaUtmAHu6QBPRz0) and [Tu Magia on Apple Music](https://music.apple.com/pe/album/tu-magia/6780482589?i=6780482590).

The short version of the AI music workflow is this: do not start with a generic prompt. Start with a clear story, turn it into a music brief, use an LLM as a producer and critic, generate controlled options with an AI music tool, then edit and package the strongest take like a real release.

## Quick Takeaways

1. To create music with AI, the brief matters more than the prompt.
2. The useful workflow is story, references, brief, generation, critique, editing, packaging, and release.
3. AI makes music production faster when it helps you repeat a standard, not when it simply creates more files.

<Callout>
This workflow is also packaged as a public Codex skill: [AI Music Prompt Producer](/resources/skills/ai-music-prompt-producer/SKILL.md). Its main output is a paste-ready prompt for Suno, Udio, or similar AI music tools.
</Callout>

## Who This Tutorial Is For

This is for founders, operators, creators, and technical people who have stories to tell but do not want to spend a year figuring out the music production process before releasing anything.

It is also for people who are curious about AI music tools like Suno, Udio, or similar generators, but do not want the output to feel generic.

The main lesson is simple: AI can create songs, but the best results come from treating it like a production system. The human still owns the taste, the story, the ethics, and the final decision.

## The AI Music Tool Stack

The process uses more than one tool. That is part of the point.

| Layer | Tools | Job |
| --- | --- | --- |
| Strategy | ChatGPT, Claude, Gemini, or another LLM | Turn story into a brief, challenge the framing, draft lyrics, create prompts, critique outputs |
| References | Spotify, Apple Music, personal playlists | Define taste, genre lane, vocal tone, tempo, arrangement, and energy |
| Generation | Suno, Udio, or similar AI music generators | Produce controlled song options from the brief |
| Editing | A DAW, audio editor, or producer workflow | Trim, arrange, tighten, select, and refine the best take |
| Visuals | Image generation, design tools, or a designer | Create cover direction and release assets |
| Release | Distributor, metadata, social copy, landing links | Package the song for Spotify, Apple Music, and public sharing |

The exact tools can change. The workflow matters more than the tool names.

## Step 1: Start With Raw Material

Most people start AI music in the wrong place. They open a tool and write something like:

Create a romantic reggaeton song about missing someone.

That can produce a song. It will probably not produce your song.

The real input is not the prompt. The real input is the material behind the prompt: the lived experience, the references, the taste, the phrases, the symbols, and the constraints that only you can provide.

For `Tu Magia`, the useful raw material was not "make a love song." It was a specific creative thesis:

I got everything I dreamed of, but I still search for her in everyone.

That one sentence was stronger than any genre label. It gave the project a point of view, a tension, and a reason to exist. From there, the hook became obvious:

"En todas te busco, ninguna tiene tu magia."

That line is simple, but it carries the whole system. It says there is success, movement, other people, and still something that cannot be replaced.

AI can imitate a genre from a generic prompt. It cannot invent the reason the song should exist.

<Callout>
Before writing the generation prompt, build the music brief. The prompt is the compressed instruction set that comes after the thinking.
</Callout>

Use a simple source-material checklist:

1. What is the real story?
2. What is the one-sentence thesis?
3. What phrases, memories, or images should survive?
4. What genre lane should the song live in?
5. What references define the sound?
6. What should the song avoid?
7. What private material should never appear in the final release?

## Step 2: Turn The Story Into A Music Brief

The breakthrough was treating the song like a product brief.

Not because music should become cold or mechanical. The source feeling still matters. But it needs to become editable. If it stays only as feeling, the AI has too many ways to misunderstand it.

For `Tu Magia`, the brief included several layers:

1. Creative thesis: I have achieved things I once wanted, but something still feels incomplete without the calm this person represented.
2. Narrative arc: the story begins with ambition, business, growth, and the feeling of building a life.
3. Specific memory bank: distance, ordinary rituals, flowers, food, family, the moment before public success, the almost-marriage, the places that still do not feel the same.
4. Musical references: Latin pop, romantic reggaeton, melodic urban pop, warm male vocal, soft dembow.
5. Structure: cold hook first, verse, pre-chorus, chorus before the first minute, post-chorus chant, second verse, bridge, final chorus, short outro.
6. Constraints: radio length, commercial polish, personal but not desperate, nostalgic but not bitter.
7. Privacy boundaries: no names, no identifiable details, no private images, no private chats in the final artifact.

That brief gave the AI something much better than a vague command. It gave it a job.

The difference is important. "Make me a song" invites the model to guess. "Here is the thesis, here are the references, here is the structure, here are the lines that must survive, and here is what the song must never become" gives the model a field to operate inside.

Creative freedom works better when the boundaries are clear.

Use this brief template before opening the music generator:

```md
# Song Brief

## Working Title
[Song title]

## Creative Thesis
[One sentence that explains what the song is really about]

## Core Hook
[The line the song should orbit around]

## Story Material
- [Memory, image, contradiction, or event]
- [Memory, image, contradiction, or event]
- [Memory, image, contradiction, or event]

## Reference Songs
- [Song or artist] for [vocal tone, groove, chorus scale, arrangement, or mood]
- [Song or artist] for [specific function]

## Sound Direction
[Genre, BPM range, vocal style, instrumentation, energy]

## Structure
[Intro, verse, pre-chorus, chorus, post-chorus, verse 2, bridge, final chorus, outro]

## Must Keep
- [Line, phrase, hook, feeling, or image]

## Must Avoid
- [Private details, wrong genre, wrong mood, cliches, names, etc.]

## Release Direction
[Cover idea, artist name, distribution notes, social angle]
```

## Step 3: Use The LLM As A Producer, Not Only A Lyric Writer

One of the most valuable parts of the process was not generation. It was disagreement.

When I tested the idea of making something viral, the AI did not treat that as a real target. It reframed the work around controllable variables: hook strength, clarity, replay value, arrangement, length, contrast, and release strategy.

That mattered because it moved the work from fantasy to execution.

The same thing happened with the original intent. If the song was too attached to one person, it could become too literal, too private, or too small. The stronger version was more universal: a song about the kind of person who made winning feel like home.

That shift protected the work.

It also made the song better. Personal does not mean private detail dump. Personal means the truth is specific enough that other people can recognize their own version of it.

This is one of the best uses of AI in creative work: not as a yes-man, but as a collaborator that keeps asking, "What is the real job here?"

Use the LLM for these jobs:

1. Clarify the thesis.
2. Identify the strongest hook.
3. Convert memories into lyric-safe images.
4. Compare references by function.
5. Draft several song directions.
6. Create prompts for AI music tools.
7. Critique generated takes.
8. Decide when to stop generating and start editing.

## Step 4: Convert References Into Production Constraints

References are not instructions to copy. They are a way to describe taste.

Instead of saying, "make it like this song," ask what each reference is doing:

1. Is it the vocal tone?
2. Is it the groove?
3. Is it the chorus size?
4. Is it the tempo?
5. Is it the mix polish?
6. Is it the emotional contrast?

For `Tu Magia`, the feeling was not pure sadness. It was romantic, nostalgic, proud, conflicted, and still moving. That meant the song should not become a slow piano confession. It needed momentum. It needed nightlife and memory in the same body.

So the brief became more precise:

1. Around 97 BPM.
2. Soft dembow, not heavy club reggaeton.
3. Melodic Latin urban pop, closer to romantic pop than street record.
4. Warm male vocal, intimate but commercial.
5. Hook at the beginning.
6. Chorus early enough for a listener to understand the promise quickly.
7. No bitterness.
8. No luxury-brand flexing.
9. No names or identifiable private material.

This is where AI starts to behave less like a toy and more like a production partner. It can compare the story reference with the musical reference and notice when they conflict. It can point out that one take has the right feeling but wrong duration, or the right genre but not enough hook density.

In other words, it can turn taste into review criteria.

## Step 5: Generate Controlled Options

AI makes generation cheap. That is useful, but it creates a trap.

When you can generate another version in seconds, you can keep chasing an imaginary perfect take. That is how you lose the best version you already have.

The way around that is controlled generation. Do not ask for everything. Ask for a narrow version of the brief.

Use this as the first controlled generation prompt:

```text
Create a commercial Spanish melodic Latin urban pop song with romantic reggaeton influence.

Theme: a man has achieved what he dreamed of, but still searches for the calm and magic of one person in everyone else.

Core hook: "En todas te busco, ninguna tiene tu magia."

Sound: warm male vocal, soft dembow, melodic urban pop, polished commercial production, around 97 BPM.

Structure: cold hook first, verse, pre-chorus, chorus before the first minute, post-chorus chant, second verse, bridge, final chorus, short outro.

Mood: nostalgic, romantic, confident, moving forward. Personal but not desperate.

Avoid: names, private details, vulgar lyrics, aggressive trap, bachata, salsa, slow piano ballad, luxury-brand flexing, long intro.
```

Generate a small batch. Then stop and review.

I ran into this quickly. Some generations had the right core but the wrong length. Others solved the length and lost the feeling. One version would be too long, another too short. One would carry the hook well, another would have a better vocal color.

The instinct is to keep rolling.

The better move is to decide when a take has enough signal to become an editing project.

## Step 6: Critique The Takes Against The Brief

This is where the LLM becomes especially useful.

Do not ask, "is this good?" That question is too vague. Ask the model to compare the take against the brief.

Use this prompt to review generated takes:

```text
Act as a music producer and A&R reviewer.

Compare this generated take against the song brief.

Evaluate:
1. Does the hook arrive early enough?
2. Is the chorus memorable?
3. Does the vocal identity fit the artist direction?
4. Does the tempo and groove match the reference lane?
5. Is the song commercial without losing the thesis?
6. What should be cut, moved, repeated, or rewritten?
7. Should I generate again or edit this take?

Give a direct recommendation and the top three changes.
```

The review needs to be specific.

The chorus came too late. The intro is too long. The vocal identity is wrong. The instrumental feels too regional. The bridge explains too much. The hook needs to appear earlier. The line you love is buried.

Once the problem has a name, the next iteration gets sharper.

## Step 7: Stop Re-Rolling And Edit

This was one of the most important lessons.

Once I liked a take, I stopped treating the model as a slot machine and started treating the song like a real production. Cut the intro. Tighten the verse. Move the hook. Remove the line that explains too much. Keep the phrase that carries the thesis. Make the structure do the work.

Generation gets you options. Editing turns one option into a song.

The editing layer can be simple or advanced depending on your skills and collaborators. You can use a DAW, an audio editor, a producer, a mixing engineer, or a smaller workflow that trims and arranges the exported audio. The important part is the mindset: the generated take is source material, not automatically the final master.

## Step 8: Package The Song For Release

The song is not finished when the audio sounds good.

A release needs packaging:

1. Final title.
2. Artist name.
3. Cover direction.
4. Distributor metadata.
5. Spotify and Apple Music delivery.
6. Short release description.
7. Social copy and clips.
8. A place to link the song after release.

This is another place where AI helps. The same creative thesis can become cover art direction, a short artist statement, release notes, captions, and a simple launch checklist.

For `Tu Magia`, the public proof point now lives on streaming platforms: [listen on Spotify](https://open.spotify.com/intl-es/track/6M5WcQvDaUtmAHu6QBPRz0) or [listen on Apple Music](https://music.apple.com/pe/album/tu-magia/6780482589?i=6780482590).

The links matter because they close the loop. This was not just an AI experiment. It became a released song.

## Step 9: Repeat The Process For `once`

The first song opened the path to a larger project: `once`.

The important point is not only that I could make one song. It is that I could finally see a way to make music consistently without turning the whole ambition into a 12-month process before anything was released.

I already had the raw material. The stories were there. The feelings were there. The events were there. The references were there. What I did not have was a production workflow that could move each idea from memory to brief to sound to release with enough speed and structure.

That is why process matters with AI.

Without process, AI gives you more output. With process, AI gives you a way to repeat a standard.

Each song can go through the same operating loop: define the thesis, build the brief, choose references, generate controlled options, critique the takes, edit the strongest direction, package it, and prepare it for release.

That repeatability is what makes the album possible. AI did not remove the work. It made the work executable.

## Common Mistakes When Creating Music With AI

The first mistake is starting with a generic prompt. The model needs taste and constraints.

The second mistake is using references as cloning instructions. References should explain function, not invite imitation.

The third mistake is generating too many versions before defining what good means. More output does not create better taste.

The fourth mistake is publishing private material because it feels authentic. Use private details to understand the feeling, but do not automatically expose them.

The fifth mistake is skipping packaging. A song needs cover direction, metadata, platform links, release copy, and a distribution plan.

The sixth mistake is letting AI make the final taste call. AI can advise, critique, and accelerate. The final decision still belongs to the human.

## Why Process Matters With AI

This loop is bigger than music. It is the same loop I see in product work, content work, and company building: raw signal, structure, generation, review, refinement, taste.

The tool changes. The operating discipline does not.

In this process, AI is excellent at a few specific jobs.

It compresses chaos into structure. I can give it memories, lyrics, references, contradictions, and production notes, and it can help turn that into a coherent brief.

It critiques without getting tired. I can ask why a song feels close but not finished, and it can evaluate the arrangement, lyrical density, hook timing, and focus.

It translates across domains. I can speak in feeling, and it can answer in tempo, arrangement, section timing, genre references, and release strategy.

It preserves momentum. Instead of waiting for the perfect collaborator to be available, I can keep moving through the next decision.

It documents the process. Every brief, prompt, critique, and revision becomes reusable operating knowledge for the next song.

It expands the production surface. The same core idea can move into lyrics, sound direction, cover art, rollout copy, metadata, social clips, and review notes.

But there are things I do not want AI to own.

It should not own the truth. It should not own the final taste. It should not decide whether a private detail is safe to reveal. It should not turn a real person into content.

The human brings the story, the standard, and the responsibility.

## FAQ

### How do you use AI to create music?

Start with a story and a clear creative thesis. Turn that into a song brief, use an LLM to refine the direction, generate controlled options with an AI music tool, critique the results against the brief, edit the strongest take, and package it for release.

### Which AI tools do you need to make a song?

At minimum, you need an LLM for strategy and critique, a reference library like Spotify or Apple Music, an AI music generator like Suno or Udio, and an editing or production workflow. For release, you also need cover art, metadata, and distribution.

### How do you keep AI music from sounding generic?

Generic output usually comes from generic input. Use specific story material, a clear hook, reference songs with defined functions, explicit constraints, and a review process that compares every take against the brief.

### Should you keep generating until the perfect song appears?

No. Generate enough options to find a strong direction, then edit. Once a take has the right core, endless re-rolling usually wastes time and can make you lose the version with the most signal.

### Can this workflow support a full album?

Yes. That is the point of building a repeatable process. If each song follows the same loop from thesis to brief to generation to critique to editing to release, AI can make a larger project executable without turning it into a 12-month planning cycle.

## Closing

The first song was the visible output.

The more valuable output was the process.

I now have a way to turn life into creative work without reducing it to a prompt. I can move from story to structure, from structure to generation, from generation to critique, from critique to editing, and from editing to release.

That is the part people miss when they talk about AI and creativity.

The interesting question is not whether AI can make a song. It can.

The better question is whether AI can help you become more precise, more disciplined, and more prolific without outsourcing your taste.

For me, that is the whole point.

AI did not make the art for me. It made me a better operator of my own creative process, and it made producing music feel like something I could finally do with speed, structure, and control.

---