Book companion · Edition 1

Developing in Agentic AI Systems GH-600 Exam Study Guide

A Six-Domain Study Guide with 58 Diagrams, 19 Cheat Sheets, and Exam Reasoning

An unofficial study guide by Nex Arc Learning. Not affiliated with, endorsed by, or sponsored by GitHub or any exam provider. GH-600, GitHub and related names are trademarks of their respective owners.

About the book

This is the reader companion for Developing in Agentic AI Systems GH-600 Exam Study Guide, edition 1, published by Nex Arc Learning as a Kindle ebook. The book prepares you for the GH-600 Developing in Agentic AI Systems exam and follows the GH-600 exam guide, May 2026. It has one chapter for each of the six exam domains, in the order of the online study guide.

Buying the book does not unlock the premium practice exams or the online study guide.

What the book covers

  1. Chapter 1 Prepare agent architecture and SDLC processes Integrate agents into the software development lifecycle · Separate planning and reasoning from agent action · Configure observability and control for autonomous agents
  2. Chapter 2 Perform evaluation, error analysis, and tuning Define agent success criteria and evaluation signals · Analyze agent failures and identify their root causes · Tune agent behavior from evaluation results
  3. Chapter 3 Implement guardrails and accountability Define autonomy levels for agent tasks · Implement guardrails and human-in-the-loop workflows
  4. Chapter 4 Manage memory, state, and execution Implement agent memory strategies · Persist agent state and manage context drift · Maintain agent memory and state across tools and environments
  5. Chapter 5 Orchestrate multi-agent coordination Operate and manage multi-agent workflows · Configure observability for multi-agent behavior · Detect and respond to multi-agent failures · Manage agent lifecycles within workflows
  6. Chapter 6 Implement tool use and environment interaction Select and configure agent tools · Configure MCP servers · Integrate agents within development environments · Operate agents with safe execution paths and robust error handling

Each chapter title links to the free overview of that domain in our online study guide.

Free practice questions

Check yourself with the free GH-600 sample questions. Pick an answer and select Check answer to see why each option is right or wrong. No account needed, nothing is stored.

Loading the practice questions…

Prefer exam conditions? Take the same questions in the free GH-600 practice exam.

Colour figures

On black-and-white Kindle e-readers the book's decision trees appear in greyscale. Here are all 25 overview decision trees in full colour, numbered as in the book. Follow a tree from the top question to the answer that fits your scenario.

Chapter 1: Prepare agent architecture and SDLC processes

Figure 1.1 Decision tree: Prepare agent architecture and SDLC processes
Does it ask whether an agent takes the work, what it gets, or what it hands back? Yes Contract Integrate agents into the software development lifecycle No Does it ask whether the agent must wait until a person accepts its plan? Yes Gate Separate planning and reasoning from agent action No Does it ask about a running agent's permissions, job approval, merge rules, or evidence? Yes Controls Configure observability and control for autonomous agents No Another domain covers it
Read this topic in the online study guide
Figure 1.2 Decision tree: Integrate agents into the software development lifecycle
no yes no yes no yes Is it production-critical or incident response, or does it touch security, authentication, or personally identifiable information? Are the requirements still open-ended or the outcome still undecided? Does it need deep cross-repository or design context, or do you want to learn it hands-on? Keep it developer-led (a strong default, not a ban) Define the change and its acceptance criteria first Keep it developer-led; the context or learning goal decides Delegate it: bounded issue, complete acceptance criteria, outputs to hand back
Read this topic in the online study guide
Figure 1.5 Decision tree: Separate planning and reasoning from agent action
Where must actionwait for review?VS Code custom agent?Planning agent: read-only tools without the agent tool, plan sections in bodyImplementation agent: disable-model-invocation: true, unless coordinator-listedHandoff with send: false pre-fills the prompt and waitsVS Code built-in Plan agent?Iterate until summary, implementation and verification steps fitStart Implementation carries the plan and context to your agentIts automatic plan.md is session memory, cleared when chat endsGitHub Copilot CLI?/plan or plan mode: questions, then plan.md in the session folderReview with /session plan or Ctrl+y; the workflow waits for approval--plan --mode autopilot proceeds without that approvalGitHub Copilot upgrade?Guided mode pauses at each stage boundary for reviewassessment.md, upgrade-options.md, plan.md, then tasks.mdUnresolved problems stop and ask for your help
Read this topic in the online study guide
Figure 1.9 Decision tree: Configure observability and control for autonomous agents
What does therequirement concern?During the run: whatmay the agent do? (runtime)Inventory: --available-tools, --excluded-toolsAllow or refuse: --allow-tool, --deny-toolJudge arguments: preToolUse returns denyWhether a job runs, or whatan acting job may reach? (job)Workflow-run approval on agent PRsProtected environment: required reviewersPrevent self-review; admin bypass offWhat may be merged?(acceptance)Ruleset with required status checksCODEOWNERS + required code-owner reviewRequester cannot approve the agent's PRWhat must a reviewerinspect later? (evidence)Artifacts tied to the run and the commitSession record: /share or --share=PATHLogs: --log-dir place, --log-level detail
Read this topic in the online study guide

Chapter 2: Perform evaluation, error analysis, and tuning

Figure 2.1 Decision tree: Perform evaluation, error analysis, and tuning
Is success written down as acceptancecriteria plus a signal that measures it?Define: state acceptance criteriain the task and pick the signalthat measures each requirementnoyesDoes that signal show the work fallingshort of its acceptance criteria?Proposed change: still goes tohuman review; Copilot cloud agentcannot approve or merge itnoyesHas evidence named the failure layer,not just the outcome?Diagnose: configuration gate,tool availability, tool call,context, or reasoningnoyesTune: change the surface that ownsthe cause, then rerun against thesame acceptance criteriarerun
Read this topic in the online study guide
Figure 2.2 Decision tree: Define agent success criteria and evaluation signals
What is the question about?Name the subject before picking an instrument The change the agent producedcode, packages, secrets, tests, UI How the run behavedtools, model, tokens, connections Whether the work may mergegates and human approval Read the matching resultVulnerable code pattern: CodeQLNew package: dependency analysisCredential in output: secret scanningSecret stopped at push: push protectionCode quality: Copilot code reviewDid tests pass: the executed runHow much was reached: coverage artifactRendered behavior: browser observations Read the metric for that componentWhich tool fails: tool call countTool latency: tool call durationLLM/agent latency: operation durationContext in and out: token usageServer reachable: MCP connection countA count is not a durationConnection outcome is not tool logic Check the gate, not the reportIs the check selected as required?Required: success, skipped or neutralbefore the branch can changeDependency review blocks only whenthe repository requires that checkThe agent cannot approve its ownpull request; a human must approve For the change: did the evidence come from running the thing?Generated test source and a written summary are claims, not results Yes: record it as the evidenceExecuted test output, coverage artifact,and browser observations (evidence now);keep repeatable tests in the repository No: run it, or state what is missingA claim is not evidence untilsomething has run and reported Research and planning tasks are judged on the plan; a pull request is created only when the task asks for one.Among the work GitHub suggests delegating more cautiously: broad, ambiguous, deep business-logic and production-critical tasks.
Read this topic in the online study guide
Figure 2.3 Decision tree: Analyze agent failures and identify their root causes
Did a configuration gate stopthe action or input by design? Configuration gate: approval, trigger filter,write access, closed or merged pull request,firewall, secret scope, content exclusion yes no Was the expected tool actuallyavailable and invoked? Tool availability: in VS Code, check theChat Debug system prompt, then selection no yes Did the call carry the intended argumentsand return a conforming result? Tool call: misuse or service failure;for MCP, reported via isError or JSON-RPC no yes Did the intended context actuallyreach the model, and only that? Context: indexing, stale records,or injected instructions no yes Does the response misread arequirement present in its inputs? Reasoning: correct inputs,wrong interpretation or plan yes no No layer confirmed: narrow the causesand name the evidence that settles them
Read this topic in the online study guide
Figure 2.5 Decision tree: Tune agent behavior from evaluation results
Must it be prevented, not discouraged?YesEnforcement control--deny-tool rule or agentStop hookNoUnreliable environment?YesSetup stepscopilot-setup-steps.ymlNoMissing capability?YesTools listsingle MCP tool or execute aliasNoNoisy or stale context?YesSession controlsfresh conversation, @file and #numberNoUnwanted persistent knowledge?YesMemory curationdelete the Copilot Memory preferenceNoRole-specific behavior problem?YesCustom agent's Markdown promptspecialist role's behaviorNoInstructionsrepository-wide or path-specific
Read this topic in the online study guide

Chapter 3: Implement guardrails and accountability

Figure 3.1 Decision tree: Implement guardrails and accountability
Which control does this requirement need?Step 1 sets the autonomy level; step 2 names the job the guardrail must do.Does it set an autonomy level: how muchthe agent may do before a person looks?yesnoMust no developer be ableto widen that level?Which job must the guardrail do?Name the job before naming a featureyesnoOrganizationalpolicyremoves thedeveloper's choiceDeveloper orsession settingnarrowest one forthis task: plan mode,session-scoped grantLimitagent never getsthe capability:tools list, Agentssecrets, firewallBlockforbidden actionis refused: ruleset,--deny-tool,preToolUse denyGatea person decidesfirst: requiredreview, protectedenvironmentRecordexplains afterwards:session logs,Verified agentcommits(prevents nothing)Define autonomy levelsfor agent tasksImplement guardrails andhuman-in-the-loop workflows
Read this topic in the online study guide
Figure 3.2 Decision tree: Define autonomy levels for agent tasks
Choosing an autonomy levelClassify the task by its three classes (stop at the first yes), check blast radius, then decide who the control binds.Task to delegateWhat could go wrong: production-critical or incident-response work, orsecurity, personal data or authentication repercussions, however small?yeshandlepersonallynoWhat understanding does it need: cross-repository refactoring, substantialbusiness logic, deep domain knowledge, or a large design-consistent change?yeshandlepersonallynoHow well is it defined: is the request ambiguous, open-ended or poorlydefined, so the approach must be agreed before any code is written?yesplan andapprovenoThen, for the work you delegate:Blast radius: can the action cause effects beyond the edit itself - remotepushes or deploy APIs, workspace watch tasks, or context sent to models or tools?yesreserveapprovalnoSession-scoped grant for this task: the VS Code session permission level,or in Copilot CLI, session approvals plus a --max-autopilot-continues capThen, separately, for whichever control you chose:Must the limit hold for every developer, so that none of themcan opt back in to a broader level?yesorganizationalpolicynoA developer or session setting is enoughWhat each outcome is NOThandle personally (consequence) - the size of the change does not lift this class back into delegation.handle personally (understanding) - judge it by the understanding it needs, not as maintenance that happens to be large.plan and approve (Copilot CLI plan mode) - protects project files; not an absolute ban on external or MCP tool effects.reserve approval - narrows which calls need a human; it does not stop the agent running everything else.session-scoped grant - expires with the session; a CLI This location approval is saved to disk and survives it.organizational policy - binds the developer; it does not classify which tasks are safe to delegate.
Read this topic in the online study guide
Figure 3.4 Decision tree: Implement guardrails and human-in-the-loop workflows
What must this control achieve?Name the outcome before naming a feature Make it impossiblelimit or block Require a human decisiongate Explain it afterwardsrecord Where does the action happen?match the surface, not the wording Is a human present in-session?cloud agent turns ask into deny Session logs, verified commits,and telemetry records A change that lands in the repoRuleset requiring code scanningor Code Quality results A tool call during a runRemove it from the tools list,or deny it (deny beats allow) Data leaving the boundaryFirewall URL rule, network filter,Agents vs Actions secret store no (cloud) yes (e.g. VS Code) Required review (CODEOWNERS +owner review) or a protectedenvironment with reviewers andPrevent self-review; disallowadministrator bypass Tool confirmation: edit theparameters before Allow; gatesensitive edits before they apply WarningA record prevents nothing; neveranswer a prevention need with it Then check the scope of whatever you choseFirewall misses MCP servers and setup steps. Sandbox misses built-in file tools.Content exclusion misses editor Edit and Agent modes. Hook timeouts fail open.A false auto-approve entry asks; it does not forbid. Prefer the narrowest fitone MCP tool over a server,a URL rule over a domain rule,read-only over read/write
Read this topic in the online study guide

Chapter 4: Manage memory, state, and execution

Figure 4.1 Decision tree: Manage memory, state, and execution
Is the question how state reaches the nextjob, device, tool or person?YesCarry it across:a carrier and its readerNoIs it what a long task decided,finished or lost?YesKeep the task record:plan and progress files,compaction checkpoints, /resumeNoChoose the home:context window, or a durablestore by lifetime, audience, reach
Read this topic in the online study guide
Figure 4.2 Decision tree: Implement agent memory strategies
no yes no yes yes no yes no yes no Lifetime: must it outlivethis conversation? Audience: should otherpeople reuse it? Only needed inthis workspace? Curated project context,not a learned fact? Reach: is a note localto this machine enough? Active context window orsession notes(/memories/session/);attach sources, splitconversations, check /context Repo notes(/memories/repo/);local to the machine,not shared by commit Copilot Space:synced sources, sharedwith teammates; eachsees only sources theycan already access Copilot Memoryrepository fact;usable only in thatrepository VS Code user memory(/memories/): acrossworkspaces, local tothis machine Copilot Memoryuser preference:follows the user acrossrepositories (Copilot CLI)
Read this topic in the online study guide
Figure 4.4 Decision tree: Persist agent state and manage context drift
What has to berecovered or fixed?Copilot CLI agent contradictsan earlier decision?/session checkpoints NUMBER: what was keptCompare with the decision's own evidenceCorrect course, then re-check files and testsNeed a detail the CopilotCLI summary dropped?A finished compaction cannot be reversedRecover it from original evidenceFull CLI history: events.jsonlContinue earlierCLI work?/resume: pick from a list or session ID--continue: this directory's latest first/fork (/branch): new session, not a Git branchReturn to anearlier point?/rewind: Conversation only, or + filesVS Code: editing a request reverts onwardGit, not chat checkpoints, is permanentResume an interrupted.NET upgrade?tasks.md: step status and validationprogress-details.md: one task's resultsupgrade-options.md: confirmed decisions
Read this topic in the online study guide
Figure 4.7 Decision tree: Maintain agent memory and state across tools and environments
no yes no yes no yes Must the state move between jobs of one run, or come from an earlier run? Must the work resume in another session, editor, or environment? Is it a standing rule, or a repository fact that later sessions may reuse? upload-artifact plus a named download, ordered by needs; across runs: a token and run identifier Conversation: hand off, open, or sync the session Upgrade task state: commit its state folder Rules: instruction files Repository facts: Copilot Memory (re-checked before use) Someone else only needs to see it: share the synced session for viewing, or export it (Export Chat JSON, /share file)
Read this topic in the online study guide

Chapter 5: Orchestrate multi-agent coordination

Figure 5.1 Decision tree: Orchestrate multi-agent coordination
A multi-agent scenarioCoordinate: is the open point how workis divided, isolated, or reconciled?Operate and managemulti-agent workflowsObserve: is it which record shows whatan agent received, did, or returned?Configure observabilityfor multi-agent behaviorRecover: did a run fail, stop short,or only wait at a gate?Detect and respond tomulti-agent failuresManage the lifecycle: Manage agentlifecycles within workflowsyesnoyesnoyesno
Read this topic in the online study guide
Figure 5.2 Decision tree: Operate and manage multi-agent workflows
Ordering GitHub Actions jobs?YesGitHub Actions job orderingneeds / workflow_runnot a fourth patternNoParallel code changes must nottouch the same working files?YesParallel sessions(worktree-isolated)NoNext specialist must continuethe same task?YesHandoffcarries the conversation historyNoSubagent delegationcoordinator keeps ownershipAlways: isolation separates files, not authority or timing
Read this topic in the online study guide
Figure 5.5 Decision tree: Configure observability for multi-agent behavior
What must you answer?Start from the question,not from the tool.What did a worker produce?Run artifacts, selected by nameWho ran, and what came back?Subagent hooks, or SDK eventsWhat happened along the way?In VS Code: Copy All, Chat DebugElse: postToolUse, agent-task logWhy did the job fail?gh run view: log-failed, job, attemptOn any branch: artifact gone?Check expires_at, then the runSDK stream, several at once?Correlate by toolCallId; attributeby the envelope agentId.Before you conclude:Deleting the run deletes itsartifacts, whatever retention said.
Read this topic in the online study guide
Figure 5.7 Decision tree: Detect and respond to multi-agent failures
Recovering a multi-agent workflow: the order to askRecovering a multi-agent workflow: the order to askWork down the left column. Leave at the first question whose answer is yes.1. Does it match a documented look-alike?No checks, an ignored @copilot, or UNKNOWN STEP,with no error payload, failed job or tool error?yesCheck first. No checks → inspect changes, then Approveand run workflows. Ignored @copilot → write access, openPR, assignee if assigned. UNKNOWN STEP → a log limit.If still stuck, retry through the original trigger.no2. Is the session still running?A live cloud-agent session, or an executionthat has already ended?yesSteer it from the session log (Copilot only), or stop it:Stop session / gh run cancel. Stopping ends execution;commits already pushed are preserved.no3. Does the same defect recur across sessions?One bad run, or every worker returning thesame class of result?yesRepair upstream. Mis-scoped work → acceptance criteriaand files. CI failures → .github/copilot-instructions.md.Lost setup time → copilot-setup-steps.yml.no4. Must an editor or merge change be rolled back?Workspace edits or an in-progress merge thatmust return to a prior state?yesRoll back at the boundary the change reached: RestoreCheckpoint in VS Code, or Git: Abort Merge. Commitsalready pushed need a separate recovery action.noOtherwise: retry the smallest failed unit. gh run rerun --failed, adding --debug when the first attempt's records are too thin;unassign and reassign the issue for issue-started work, or submit the same comment again for comment-started work. Then confirmdelivery from the changed files and the test results — never from a completion message or a sessionEnd reason.
Read this topic in the online study guide
Figure 5.10 Decision tree: Manage agent lifecycles within workflows
What are you doing to the worker? Adding one.Who must be able to use it? add One workspace: commit a .agent.mdprofile under .github/agents One person, every workspace: theAgent Host user folder ~/.copilot/agents A whole organization: define itcentrally, then enable organizationagent discovery Everyone with the extension: anagent contributed by an installedVS Code extension One session: an SDK customAgentsdefinition passed when theapplication creates the session Updating or replacing one.Which case are you in? change Only new work must change: publish tothe branch the tasks select; a new tasktakes the latest profile Work in an open pull request: it keepsthe version that opened it, so assignthat work as a new task It loaded and changed nothing: find thewinning level, the repository MCPsettings, or the calling prompt file Retiring one.The agent, a session, or a missing record? retire The agent: remove it through the sourcethat supplies it. Hiding it in the agentpicker is not removing it A local worktree session: archive it(commits, keeps the branch). To delete,commit first: deletion is final A cloud-agent session: archive it.Cloud sessions can be archivedbut not deleted You cannot find it: check the filter,Archived in the Chat view or Donein the Agents window
Read this topic in the online study guide

Chapter 6: Implement tool use and environment interaction

Figure 6.1 Decision tree: Implement tool use and environment interaction
An agent tool-use requirementTools that exist, are offered, or may run,or the credential a program reads?Tool capabilityDeclaring, connecting, orallowing an MCP server?MCP server setupThe machine, where configuration is read,or the surface that issued a grant?Execution contextClassify, retry, roll back,escalate, or record a failure?Safe operationyesnoyesnoyesnoyes
Read this topic in the online study guide
Figure 6.2 Decision tree: Select and configure agent tools
Is the needed capability missingfrom the environment entirely? Provider: use a built-in tool, or add anMCP server or extension-contributed tool yes no Must the model never be offeredthis tool at all? Visibility: the profile tools list,or --available-tools / --excluded-tools yes no Must a visible tool be refused,or run without a prompt? Permission: CLI --allow-tool / --deny-tooland URL rules, where deny beats allow;cloud agent: each MCP server's tools array yes no Is the problem which custom agentgets chosen, and by whom? Invocation: disable-model-invocationor user-invocable, not the tools list yes no Otherwise, if a tool that is provided, visible and permitted fails to authenticate,check where the program that reads its credential looks, such as a COPILOT_MCP_ Agents secretfor cloud agent MCP servers, or the COPILOT_GITHUB_TOKEN, GH_TOKEN, GITHUB_TOKENorder for Copilot CLI.
Read this topic in the online study guide
Figure 6.4 Decision tree: Configure MCP servers
Should the server belong to onecustom agent only?That custom agent profile: servers forthat agent; repository settings apply lateryesnoMust an autonomous cloud agent or codereview session use the server?Repository Settings > Copilot > MCP servers:an mcpServers entry, with a tools allowlistyesnoShould everyone who opens this projectget the server with the clone?Editor file, workspace scope: .vscode/mcp.json,committed, secrets kept out (or declared indevcontainer.json customizations.vscode.mcp)yesnoEditor file, user-profile scope: followsone developer across every workspaceA gate, not a place to declare: policy decides which servers a managed device may install or run.Copilot managed settings: allowedMcpServers, deniedMcpServers, allowManagedMcpServersOnlyVS Code enterprise policy: ChatMCP (source) and McpGalleryServiceUrl (catalog)The allow and deny lists can also arrive as VS Code enterprise policy;where both set the same list, the Copilot managed value applies.In the editor: trust and enable the server,restart after changes, then read its output log.In a cloud agent session: check theStart MCP Servers step in the session log.
Read this topic in the online study guide
Figure 6.8 Decision tree: Integrate agents within development environments
Does the task need tools, files orcredentials that exist only on the laptop? Run locally. Keep MCP servers in user-profilescope; choose how to isolate the session. yes no Must a workflow step drive the agentand then return control to the job? Copilot CLI in prompt mode (-p),plus an authentication route. yes no Does the cloud agent need toolchainsor dependencies before it starts? Prepare it in copilot-setup-steps on thedefault branch; keep to supported settings. yes no Does a hook have to reach a serviceoutside GitHub during the session? Default-branch hook; where the integratedfirewall is in use, allow the destination. yes no Is the ask about what the agent maywrite rather than what it can run? That is the working-branch scope and branchprotection, never the setup job's permissions. yes no: none of these surfaces needs changing
Read this topic in the online study guide
Figure 6.11 Decision tree: Operate agents with safe execution paths and robust error handling
A failure signal: which layer failed?Was the request itself rejectedwith a JSON-RPC error?YesFix the request or the tool choiceunknown tool or malformed requestNoDid the tool run and returna result with isError: true?YesReturn the error to the modelso it can correct its argumentsNoDid a resumable stream dropbefore the response finished?YesWait any retry delay, then resumeGET + Last-Event-ID; never re-send tools/call(legacy 2025-11-25 transport)NoDid a request carrying MCP-Session-Idget HTTP 404?YesStart a new sessionnew InitializeRequest (legacy 2025-11-25 transport)NoDid the request time outwhile you waited for it?YesCancel the request, stop waitingsend cancellation for that requestNoA command, job, or API call failed:could its side effect already exist?YesInspect state first, then act oncePR URL, run statusNoRetry only the failed part, bounded--failed, --job databaseId, retry-after, backoffUnsafe or blocked at any step: stop, then escalate through a channel that exists theredeny + interrupt in the CLI, gh run cancel, approval gates and required checks
Read this topic in the online study guide

Errata for edition 1

No known errata for this edition.

Found a mistake in the book? Report it and quote the chapter and figure or section number.

Get the book

  • Kindle ebook Kindle edition on Amazon. The store link appears here once the Amazon listing is live.

Keep studying

How this book was made

The book's text was generated using AI and reviewed through Nex Arc Learning's editorial and fact-checking process. Nex Arc Learning assumes editorial responsibility for the published content. Exam objectives change over time; check the official exam page for the current objectives. More on our methods: About Nex Arc Learning.