feat(use-cases): add GPU music production agent sample

02-use-cases/02-workflow-automation-agents/README.md

@@ -31,6 +31,7 @@ Agents that run without a user in the loop. They are triggered by system events
 | [enterprise-web-intelligence-agent](./enterprise-web-intelligence-agent/) | Market Intelligence | Intermediate | Runtime, Browser; automated web scraping pipeline implemented twice (LangGraph and Strands) for comparison |
 | [intelligent-event-agent](./intelligent-event-agent/) | General | Beginner | Runtime, Memory, Gateway *(in development, no README yet)* |
 | [multi-isv-orchestration](./multi-isv-orchestration/) | Enterprise CRM + ERP | Intermediate | Gateway (multi-target), Identity (Cognito inbound + CustomOauth2 outbound); Salesforce + SAP MCP Server through one Gateway for cross-system queries |
+| [gpu-music-production-agent](./gpu-music-production-agent/) | Media & Entertainment | Advanced | Runtime (EC2 capacity provider, GPU), Memory; a generative audio model runs on the instance GPU and three collocated agents hand files to each other over a shared EBS volume, with a computed verdict that escalates to human review |
 
 
 ## See also

02-use-cases/02-workflow-automation-agents/gpu-music-production-agent/.dockerignore

@@ -0,0 +1,23 @@
+# Keep the build context to the agent and what it needs.
+#
+# build/agentdeps is NOT excluded: deploy.py vendors the agent wheels there for
+# linux/amd64 and the Dockerfiles COPY them in, which is what lets the images
+# build with no RUN steps and therefore without QEMU emulation on an arm64 host.
+build/compliance/
+build/*.zip
+verify/
+scripts/
+dist/
+runs/
+*.md
+!requirements.txt
+.git/
+.gitignore
+.venv/
+venv/
+__pycache__/
+*.pyc
+*.pyo
+.pytest_cache/
+.DS_Store
+deployment_state.json

02-use-cases/02-workflow-automation-agents/gpu-music-production-agent/.gitignore

@@ -0,0 +1,8 @@
+.venv/
+build/
+__pycache__/
+*.pyc
+deployment_state.json
+*.zip
+.DS_Store
+runs/

02-use-cases/02-workflow-automation-agents/gpu-music-production-agent/Dockerfile.composition

@@ -0,0 +1,53 @@
+# Composition agent image.
+#
+# Deliberately has NO RUN steps. Every dependency is vendored on the build host
+# with `uv --python-platform x86_64-manylinux2014` and copied in, so this builds
+# for linux/amd64 from an arm64 Mac in seconds. A single `pip install` here would
+# execute under QEMU emulation instead.
+#
+# GPU families on AgentCore capacity providers are all x86_64, so the platform is
+# pinned rather than inherited.
+#
+# Measured: 180 MB, against the 2 GB hard cap on an AgentCore Runtime image. The
+# generative stack (torch + CUDA + ACE-Step, about 6.3 GB installed) does not fit
+# in any image and lives on the capacity provider's `models` volume instead;
+# model_stack/prepare.py builds it there on first use.
+FROM --platform=linux/amd64 public.ecr.aws/docker/library/python:3.12-slim
+
+WORKDIR /app
+
+# Vendored wheels, unpacked by deploy.py into build/agentdeps.
+COPY build/agentdeps /app/deps
+ENV PYTHONPATH=/app/deps
+ENV PYTHONUNBUFFERED=1
+
+# AgentCore injects the NVIDIA driver into /usr/lib64 at run time. This base image
+# is Debian, whose dynamic linker searches /usr/lib/x86_64-linux-gnu and /usr/lib
+# but NOT /usr/lib64 -- there is no entry for it in /etc/ld.so.conf.d, and
+# ldconfig cannot help because the driver appears after the image is built.
+#
+# Without this, libcuda.so.1 is present on disk and still unloadable, so torch
+# reports cuda_available=False and silently runs on the CPU. Measured on a live
+# g6.xlarge: `ctypes.CDLL("libcuda.so.1")` raises "cannot open shared object
+# file", and the same call with LD_LIBRARY_PATH=/usr/lib64 succeeds and torch then
+# reports one NVIDIA L4.
+#
+# An Amazon Linux based image would not need this, because /usr/lib64 is a
+# standard library path there.
+ENV LD_LIBRARY_PATH=/usr/lib64
+
+COPY audio_dsp.py composition_agent.py /app/
+COPY model_stack /app/model_stack
+
+# Runs as root so the agent can write to the capacity provider volume. The mount
+# is 2775 root:agentcore-runtime-user and the agent process holds that
+# supplementary group; a command shell in the same runtime does not, which is why
+# only the agent can populate the volume. Drop privileges only if you move the
+# workspace to an EFS or S3 Files access point where you set the POSIX UID/GID.
+
+EXPOSE 8080
+
+HEALTHCHECK --interval=30s --timeout=5s --start-period=20s \
+    CMD python -c "import urllib.request;urllib.request.urlopen('http://127.0.0.1:8080/ping',timeout=3)"
+
+CMD ["python", "composition_agent.py"]

02-use-cases/02-workflow-automation-agents/gpu-music-production-agent/Dockerfile.mastering

@@ -0,0 +1,24 @@
+# Mastering agent image. No RUN steps, for the same reason as
+# Dockerfile.composition: dependencies are vendored for linux/amd64 on the build
+# host so this builds without QEMU emulation.
+#
+# This agent does no GPU work. It runs on the same GPU instance as the composition
+# agent because collocation is what gives it access to the rendered audio, but
+# mastering is filters and gain, so keeping it on the CPU leaves the GPU free for
+# generation and avoids two processes competing for VRAM.
+FROM --platform=linux/amd64 public.ecr.aws/docker/library/python:3.12-slim
+
+WORKDIR /app
+
+COPY build/agentdeps /app/deps
+ENV PYTHONPATH=/app/deps
+ENV PYTHONUNBUFFERED=1
+
+COPY audio_dsp.py mastering_agent.py /app/
+
+EXPOSE 8080
+
+HEALTHCHECK --interval=30s --timeout=5s --start-period=20s \
+    CMD python -c "import urllib.request;urllib.request.urlopen('http://127.0.0.1:8080/ping',timeout=3)"
+
+CMD ["python", "mastering_agent.py"]