The most expensive mistake in report building is the premature one: clicking visuals before the data model and the goal are clear. Our orchestrator cannot do that — it is bound to a fixed flow.
The chain
Every goal runs through the same phases:
Intake → Assessment → Specification → Build → Verification → Completion
Think first: intake, assessment, specification
- Intake. The orchestrator clarifies only what is necessary: scope, ambiguous terms, real forks. If the goal is unambiguous, it does not ask.
- Assessment. It determines the domain, the artifact type (semantic model? report? both?) and detects from existing files what is already there. Using a declarative routing ruleset it decides: Power BI work goes to the Power BI specialist, data engineering to the data-engineering worker.
- Specification. Here the acceptance criteria are born — checkable conditions for "done". For a report, e.g.: "opens 100% clean", "no secrets/IDs in the artifact", "report structure validates cleanly", "follows the corporate template", "visual review passed".
Then act: build, verification, completion
- Build. Only now is anything built. The Power BI specialist loads the relevant skills (semantic-model authoring, report authoring, report design) and produces the TMDL model, DAX measures, and report visuals.
- Verification. Every criterion is checked — preferably with executable checks (see Article 6). Only proof counts, not the agent's opinion.
- Completion. Reachable only when all criteria are provably green. Otherwise it goes back into the work.
Why slow is fast here
In each round the agent works only on the current phase, reads the state beforehand, and writes it back afterward. No jumping ahead, no skipping. This is exactly what prevents the "looks finished but crashes on opening" effect.
Structure is not a brake. Structure is why you don't have to build the report twice.
Where in your report process does "clicking" start too early? 👇
