๐—ข๐—ฟ๐—ฐ๐—ต๐—ฒ๐˜€๐˜๐—ฟ๐—ฎ๐˜๐—ถ๐—ป๐—ด ๐——๐—ฒ๐˜€๐—ถ๐—ด๐—ป ๐˜๐—ผ ๐—–๐—ผ๐—ป๐—ณ๐—ถ๐—ด ๐—ถ๐—ป ๐˜๐—ต๐—ฒ ๐—ฆ๐——๐—Ÿ๐—–: ๐—” ๐—ฃ๐—ฟ๐—ฎ๐—ฐ๐˜๐—ถ๐—ฐ๐—ฎ๐—น ๐—˜๐˜…๐—ฎ๐—บ๐—ฝ๐—น๐—ฒ

Most delivery teams still spend too much time translating and rewriting what already exists. This post walks through a practical โ€œdesign to configโ€ approach, where inputs are orchestrated through a set of agents to produce structured, build-ready outputs. Itโ€™s not about replacing peopleโ€”itโ€™s about shifting effort from creating artefacts to reviewing and governing them. The result is cleaner handoffs, earlier visibility of gaps, and a more controlled path from requirements to build. The real shift isnโ€™t automation. Itโ€™s moving work leftโ€”so design, validation, and alignment happen before the build even starts.

Dawn Thiart

4/5/20261 min read

(creating artefacts โ†’ orchestrating outcomes)

Think of it as a small agentic delivery system โ€” not a single agent.

๐Ÿญ. ๐—œ๐—ป๐—ฝ๐˜‚๐˜๐˜€ ๐—ฐ๐—ผ๐—บ๐—ฒ ๐—ถ๐—ป

โ€ข approved requirements
โ€ข workshop transcripts
โ€ข templates and design patterns
โ€ข data models and integration standards

These already exist โ€” but are spread across documents and notes.

๐Ÿฎ. ๐—ข๐—ฟ๐—ฐ๐—ต๐—ฒ๐˜€๐˜๐—ฟ๐—ฎ๐˜๐—ผ๐—ฟ ๐—”๐—ด๐—ฒ๐—ป๐˜ (๐—ฐ๐—ผ๐—ป๐˜๐—ฟ๐—ผ๐—น ๐—น๐—ฎ๐˜†๐—ฒ๐—ฟ)

Its role is to:

โ€ข understand the request
โ€ข select the right agents
โ€ข sequence the work
โ€ข consolidate outputs
โ€ข route exceptions to human review

๐Ÿฏ. ๐—ฆ๐—ฝ๐—ฒ๐—ฐ๐—ถ๐—ฎ๐—น๐—ถ๐˜€๐˜ ๐—ฎ๐—ด๐—ฒ๐—ป๐˜๐˜€

๐—ฅ๐—ฒ๐—พ๐˜‚๐—ถ๐—ฟ๐—ฒ๐—บ๐—ฒ๐—ป๐˜๐˜€ ๐—”๐—ด๐—ฒ๐—ป๐˜
โ†’ converts requirements into config intent

๐—ฃ๐—ฎ๐˜๐˜๐—ฒ๐—ฟ๐—ป ๐—”๐—ด๐—ฒ๐—ป๐˜
โ†’ maps to standard patterns:
โ€ข Outlook integration
โ€ข account/contact/opportunity model
โ€ข business rules
โ€ข F&O field integration
โ€ข approval workflows

๐—–๐—ผ๐—ป๐—ณ๐—ถ๐—ด ๐—”๐—ด๐—ฒ๐—ป๐˜
โ†’ generates draft config items:
โ€ข integration field mapping
โ€ข business rules
โ€ข security roles
โ€ข approval flows
โ€ข BPF stage logic
โ€ข Outlook/email config

๐—ฉ๐—ฎ๐—น๐—ถ๐—ฑ๐—ฎ๐˜๐—ถ๐—ผ๐—ป ๐—”๐—ด๐—ฒ๐—ป๐˜
โ†’ identifies gaps, conflicts, assumptions, dependencies

๐——๐—ฒ๐—น๐—ถ๐˜ƒ๐—ฒ๐—ฟ๐˜† ๐—”๐—ด๐—ฒ๐—ป๐˜
โ†’ produces build-ready config tickets

๐Ÿฐ. ๐—›๐˜‚๐—บ๐—ฎ๐—ป ๐—ฟ๐—ฒ๐˜ƒ๐—ถ๐—ฒ๐˜„

โ€ข Solution Architect โ†’ design integrity
โ€ข Functional Lead โ†’ business accuracy
โ€ข Technical Lead (if required)

This step ensures control โ€” not uncontrolled automation.

๐Ÿฑ. ๐—ข๐˜‚๐˜๐—ฝ๐˜‚๐˜๐˜€

โ€ข standard + custom config items
โ€ข open questions and assumptions
โ€ข dependencies and actions
โ€ข build-ready tickets
โ€ข traceability to requirements

๐—ช๐—ต๐—ฎ๐˜ ๐˜€๐—ต๐—ถ๐—ณ๐˜-๐—น๐—ฒ๐—ณ๐˜ ๐—น๐—ผ๐—ผ๐—ธ๐˜€ ๐—น๐—ถ๐—ธ๐—ฒ

๐—ง๐—ผ๐—ฑ๐—ฎ๐˜†
โ€ข interpret requirements
โ€ข map patterns manually
โ€ข write config from scratch
โ€ข resolve gaps late

๐—ช๐—ถ๐˜๐—ต ๐˜๐—ต๐—ถ๐˜€ ๐—บ๐—ผ๐—ฑ๐—ฒ๐—น
โ€ข orchestrated flow
โ€ข generated draft outputs
โ€ข review replaces creation

The shift

๐—ฆ๐—ผ๐—น๐˜‚๐˜๐—ถ๐—ผ๐—ป ๐—”๐—ฟ๐—ฐ๐—ต๐—ถ๐˜๐—ฒ๐—ฐ๐˜
write design โ†’ govern outputs

๐—™๐˜‚๐—ป๐—ฐ๐˜๐—ถ๐—ผ๐—ป๐—ฎ๐—น ๐—Ÿ๐—ฒ๐—ฎ๐—ฑ
translate requirements โ†’ validate structure

๐—ง๐—ฒ๐—ฐ๐—ต๐—ป๐—ถ๐—ฐ๐—ฎ๐—น ๐—ง๐—ฒ๐—ฎ๐—บ
interpret design โ†’ build from standardised config