When developers first use GitHub Copilot, they use it as an autocomplete tool. The model suggests; the human accepts or rejects. The human is always in control. The agent’s role is narrow.
The GH-600 certification covers a more expansive vision: agents that operate across the entire software development lifecycle (SDLC), taking on planning, implementation, testing, review, and deployment tasks with minimal moment-to-moment supervision.
This is a qualitative shift. It changes how teams think about code ownership, how workflows are designed, and how risk is managed. Domain 1 of the GH-600 (18% of the exam) tests whether you understand these changes.
The Bounded Agent Model
The key insight in Domain 1 is bounded agency: agents are most useful and least dangerous when they have:
- A defined entry point — they activate on a specific trigger (label, event, schedule)
- A scoped file system access — they can touch specific directories, not the entire repo
- A clear exit condition — they know when they are done (and what done looks like)
- An observable trace — every action is logged with enough context to understand what happened
The classic failure mode for early agentic SDLC designs is the agent that “does too much” — it’s given write access to the full repository, no structured success criteria, and no logging. When it fails (or produces unintended results), there’s no way to understand why.
Planning vs. Action: The Two-Phase Pattern
One of the most important patterns for Domain 1 is the plan-then-execute workflow:
- Phase 1 (Plan): Agent reads the task, analyzes the codebase, and produces a written plan. No file changes. No execution. Just a document.
- Phase 2 (Execute): After human approval of the plan, the agent implements what it planned.
This pattern is implemented in GitHub Actions using separate jobs with an environment: gate between them. The environment requires human approval before the execution job is allowed to run.
Why does this matter for the exam? Because Domain 1 sub-skill 1.2 explicitly tests your understanding of the planning phase and the action phase as distinct, separated concerns.
Observability in Agentic Workflows
Domain 1 also covers observability (sub-skill 1.3). An observable agent workflow:
- Emits structured log entries (JSON preferred) for every significant action
- Records both the input state and the output state of each step
- Reports whether it succeeded or failed — and why — in a way that a human can inspect without re-running the workflow
In the Agentic Codex arc, this is implemented using workflow step summaries and structured JSONL log files committed back to the repository.
Domain 1 Quests
| Quest | Skill | Link |
|---|---|---|
| Q1 | SDLC Integration | Agentic SDLC Integration |
| Q2 | Plan vs Action | Plan vs Action Boundaries |
| Q3 | Observability | Observability & Control |
The quests cover the practical implementation of each concept with GitHub Actions workflows, scripts, and validation exercises.