Prepare Agent Architecture and SDLC Processes
This domain tests your ability to design, configure, and govern autonomous agents operating within the software development lifecycle. It covers how agents are structured across planning, reasoning, and execution phases; how human oversight is configured; and how observability and control are maintained without blocking delivery. At 18% of the exam, it is one of the heaviest-weighted domains and consistently tests architectural decisions, anti-pattern recognition, and approval-gate configuration.
Identifying Steps for Agents to Perform Within the SDLC
Agents in an SDLC context are assigned to discrete, bounded phases. The exam tests whether you can identify which phases are appropriate for agent involvement and which require human ownership.
Agent-appropriate SDLC steps:
| SDLC Phase | Agent Role | Human Role |
|---|---|---|
| Requirements analysis | Parse tickets, extract acceptance criteria, flag ambiguity | Confirm and resolve ambiguity |
| Design | Propose architecture, generate diagrams, identify dependencies | Approve or reject proposals |
| Implementation | Generate code, write tests, open pull requests | Review and merge |
| Testing | Run test suites, report failures, suggest fixes | Approve coverage thresholds |
| Review | Annotate diffs, flag regressions, suggest improvements | Make final merge decision |
| Deployment | Run pipelines, validate health checks, rollback on failure | Approve production gate |
| Monitoring | Alert on anomalies, summarize logs, escalate | Triage and resolve |
Key principle: Agents should own automation-safe tasks — tasks that are deterministic, reversible, or low-risk when wrong. Agents should not own final approval at production gates, legal/compliance sign-off, or architectural decisions without a configured human-in-the-loop step.
Common traps:
- The exam may present agents as performing "all testing and deployment" without any gate. This is an anti-pattern.
- Confusing "agent-assisted" (agent recommends) with "agent-autonomous" (agent acts). The exam distinguishes these.
- Placing an agent in the requirements phase without a feedback loop to a human is flagged as a boundary violation.
Worked scenario: A team wants an agent to handle issue triage, code generation, and pull request creation, but wants humans to merge. The correct boundary: agent owns pre-merge steps; merge action is blocked until a human approves the PR.
Identifying and Mitigating Common Agent Anti-Patterns
The exam tests recognition of specific named anti-patterns and their mitigations.
| Anti-Pattern | Description | Mitigation |
|---|---|---|
| God agent | Single agent handles all SDLC tasks with no specialization | Decompose into specialized sub-agents with defined scopes |
| Prompt stuffing | Injecting entire codebase or unfiltered context into agent prompt | Use retrieval-augmented generation (RAG) with scoped context windows |
| Action sprawl | Agent is granted more tool permissions than it needs for its task | Apply least-privilege tool configuration per agent role |
| Silent failure | Agent fails internally and returns a partial or empty result without raising an error | Require structured outputs with explicit status fields |
| Runaway autonomy | Agent continues taking actions after a stopping condition is met | Define explicit halt conditions and register them before execution |
| Plan-execution conflation | Agent plans and acts in the same step with no separation | Enforce a plan-then-execute architecture with a validation gate |
| Sycophantic reasoning | Agent confirms user assumptions rather than reasoning independently | Use adversarial prompting or critic agents in the pipeline |
| Tool call looping | Agent retries the same tool call indefinitely on failure | Set maximum retry limits and fallback handlers |
Common traps:
- The exam presents "god agent" as efficient because it reduces latency. Efficiency is not a valid reason to collapse agent boundaries.
- "Prompt stuffing" is often disguised as "giving the agent full context" — always filter to relevant context.
- "Runaway autonomy" is tested by asking what happens when an agent's stopping condition is not registered. The answer is always: configure explicit halt conditions before execution begins.
Worked scenario: An agent is configured to fix failing tests by rewriting code. It enters a loop where each fix breaks another test. The correct mitigation: set a maximum iteration limit and a divergence detector that halts the agent if failure count increases across iterations.
Sign in free to read the full guide
11 more sections (about 2,997 words) continue below. The first domain's study guide is free for every GH-600 learner with a free account.