An agent tasked with generating GitHub Actions workflows is failing in production. Investigation reveals that users submit requests like 'set up CI for my project' without specifying the language, test framework, or deployment target. The agent silently assumes defaults — often incorrectly — and generates workflows that fail immediately. What is the root cause of this failure?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A custom home builder who starts pouring concrete before asking what size house you want is going to have a very bad day. Your agent accepted an underspecified request and started guessing. Defining a clear input schema — language, framework, deployment target, environment — forces users to provide what the agent actually needs before it starts working.
Full explanation below image
Full Explanation
Defining inputs is a foundational Domain 1 requirement: an agent must know exactly what information it needs before beginning a task, and ambiguous or missing inputs must be resolved before execution starts. This is implemented through an input schema — a defined contract that specifies required fields, optional fields, allowed values, and validation rules.
The correct answer is B. The agent has no defined input schema, so it accepts underspecified requests and proceeds with assumptions. The fix is to define a structured input schema that requires: programming language, test framework, runtime environment, and deployment target. The agent's entry point should validate incoming requests against this schema and reject or prompt for completion any request that doesn't supply required fields. This eliminates the silent-assumption anti-pattern.
Why the other options are wrong:
Option A — model size — is not the issue. No model, regardless of size, can reliably infer the correct test framework for a project it has never seen. The problem is architectural: the agent accepts incomplete inputs rather than requiring complete ones. A larger model would still guess incorrectly.
Option C — YAML syntax errors due to fine-tuning gaps — is a different type of failure. The scenario specifically says the workflows fail immediately, which is consistent with wrong configuration (wrong language or framework), not malformed syntax. If the issue were syntax, the YAML parser would catch it before the workflow ran.
Option D — lack of repository access — is a plausible workaround that might reduce the need for explicit inputs, but it is not the root cause. The root cause is that the agent doesn't require inputs and makes silent assumptions. Even with repository access, the agent still needs a well-defined input contract for parameters that can't be auto-detected.
For the exam: 'agent makes assumptions,' 'silently guesses,' 'underspecified requests proceed without error,' and 'inputs are not validated' all describe a missing or undefined input schema — a core Domain 1 anti-pattern.