Build a use case with an agent

You describe a model in a sentence. Claude Code learns the environment through Pipewright’s tools, drafts the use case, checks it, and opens a pull request. You review, merge and approve. The prompts below are the ones used in testing, end to end, on a live project.

Before you start

• An environment from the quickstart with agent_identity = true for your team and, if the data team has them, its feature_datasets. See the agent’s identity.
• An entity table in your team’s dataset: one row per entity and cut-off date, with the label. In this tutorial, retail_entities (customer_id, snapshot_date, churned).
• Features in the catalogue: here, the data team’s feature group customer_activity (recency_days, orders_90d, spend_90d).
• Claude Code installed, and your MLOps repository with pipewright ci init workflows.

1. Set up the repository (once)

pip install "pipewright-mlops[gcp,mcp]==1.3.0"
pipewright context build --env test
pipewright mcp --env test --tenant retail --print-config     # put the printed settings in .mcp.json
git add -A && git commit -m "Context pack and tool server for coding agents"
git switch -c agent/churn-weekly
claude

In Claude Code, type /mcp: pipewright should show as connected. With Pipewright Enterprise, use pipewright agent-config write instead of the second and third lines (see Enterprise), and trust the folder when Claude Code asks.

2. What can the agent see?

Start by asking. It is the quickest way to check the identity and the tools, and to see a refusal for yourself.

Before we build anything: using only the pipewright tools, tell me what you can see
in test. List the feature catalogue, describe pw_retail.retail_entities, and then
try to sample five rows from it. Tell me plainly what was refused.

You should see list_features (the feature group and its three features), inspect_table (three columns, the row count, partitioned by snapshot_date) and sample_rows refused: rows are never sent to an AI agent. If the agent offers to run bq query instead, let it try: the agent identity gets Access Denied.

3. Build the use case

Read APP_CONTEXT.md and follow .pipewright/playbooks/onboard-a-use-case.md.

Onboard a new use case called churn-weekly for the retail team: train a churn model
every Monday at 06:00 London time from pw_retail.retail_entities, using features from
our feature catalogue, and email ml-team@example.com when a run fails.

Use only the Pipewright tools for anything about data. Never ask for rows. When the
files are written, run pipewright validate --env test and pipewright doctor --env test
--usecase churn-weekly, fix anything they report, and rebuild the context pack.
Finish with pipewright review --env test --base main, and write your judgement calls
in the review.

What happens, in about five minutes:

1. bootstrap_usecase drafts the folder with features_from the feature group, as of each row’s snapshot_date, and landing: null: runs read the entity table.
2. The agent sets a time split, gates, a schedule and the alert email, then runs validate. In testing it failed once (drift monitoring with no scoring pipeline), and the agent fixed it.
3. doctor passes, the context pack is rebuilt, and the review bundle ends with the agent’s judgement calls.

4. The pull request

Commit the new use case and the rebuilt context pack on this branch, push it, and open
a pull request against main titled "churn-weekly: weekly churn model from the feature
catalogue", with the review bundle and your judgement calls as its description.
Do not merge it.

Claude Code asks before git commit, git push and gh pr create: approve each. On GitHub, the check and review jobs run; the review job’s summary has the bundle and says the context pack is current.

5. A person decides

Read the pull request and merge it yourself. The release workflow releases churn-weekly with its tables; sync its schedule the way your team does (pipewright schedules sync, or the operations workflow). Then train it:

pipewright run --env test --usecase churn-weekly \
  --source-uri bq://<project>.pw_retail.retail_entities

When it finishes, ask the agent how it went:

Using the runs tool, how did the latest churn-weekly training run go, and is there a
model waiting for approval?

If a run fails, runs returns its failed steps and their first error line, and the debug-a-failed-run playbook takes it from there. Approving the model stays yours:

pipewright model list --env test --usecase churn-weekly
pipewright model approve --env test --usecase churn-weekly --version 1

6. Check the record

In the Logs Explorer, filter on the agent account as principal. Each call shows your account as the delegate, the pipewright-mcp/1.3.0 agent=claude-code user agent, and any attempt at table data as denied. On your machine, .pipewright/mcp-log.jsonl lists the same calls.