Dynamic Input Builder Pattern
A single skill adapts to variable input schemas at runtime by fetching the schema definition before building the payload — eliminating one skill per ticket category or form type.
Why This Pattern
The alternative is N skills, one per form or category variant — which doesn't scale and rots the moment a category is added or a field changes upstream. The reasoning for paying the upfront cost of a schema-resolution step is that it converts an ever-growing maintenance problem into a fixed one: resolve the schema once at runtime, and one skill handles every variant.
This is a targeted answer to schema variability, not a default. If the schema never actually varies, the schema-resolution step is complexity you paid for and didn't need — that's Deterministic Flow.
When to Use It
- Fields vary by request type, category, or prior answers, and a static schema would require one skill per variant.
- The schema can be resolved at runtime from an external application, file storage, a data table, or pre-processed JSON metadata.
When NOT to Use It
- The input schema is stable and doesn't vary by category — a static schema and a single fixed skill is simpler and cheaper.
- The raw API metadata is small enough to model directly — the schema-resolution step adds complexity that isn't justified for simple forms.
How It Works in Workato
- Identify the correct request type or category from the user's request.
- Call a schema-resolution skill or recipe to retrieve the relevant dynamic form fields.
- Return the simplified schema to the genie as JSON — question labels, field types, required fields, allowed values, conditional visibility rules.
- The genie asks only the applicable questions, validates responses, and constructs the final payload.
Source: Agentic Design Cookbook V2.0, pp. 14–17 (BMC and JSM use cases)