Set it once.
Prove it landed.
Seven steps, two people
Changing the seed is a short loop between you, working in Power BI Desktop, and the agent, working on the files. Each step has a reason, and each one exists because skipping it once caused a problem.
Predict first: you've saved a new setting in the seed. What's the agent's first job?
"The seed hasn't changed"
The most common hiccup. The agent reads the seed and finds nothing new. Pick what you see to find the cause.
Why the seed gets its own commit
The seed change is committed before the report change, with a message like "Seed gains card padding". When someone later asks where a block came from, the history answers: this example, saved on this day, then copied into these cards. It also means a failed build can be undone without losing the example.
The value in the seed doesn't have to match the report. The seed can show 4 px spacing while the report uses 0 px, as long as that's written down. The seed proves the format; the real project decides the value.
The rule, in one breath
Set it by hand, prove the save landed, let the agent show what it read, and commit the seed before anything else.
The agent proposes and stops. It builds, validates and stops. You look before anything is saved. Nothing moves on without a go-ahead.
Next: when to estimate and when to test.