GH-600 Developing in Agentic AI Systems Questions and Answers

Target

Selection

Dropdown 1

' search '

Dropdown 2

' read '

The visible configuration describes an implementation planner. Providing search and read supports the information-gathering work needed to produce a technically grounded plan: locating relevant code and inspecting its contents. The listed documentation tools supplement repository context with external technical reference material.

This tool selection also establishes a practical boundary between planning and implementation. A planner can explain proposed changes and produce Markdown in its response without needing permission to modify repository files. Granting editing or command-execution capabilities would expand its authority beyond the visible planning role.

The distinction between generating Markdown and saving a Markdown file is important. The selected tools support producing a plan in conversation. If the requirements instead demanded that the planner write that plan directly into the repository, an appropriate file-writing capability or a separate persistence step would be necessary.

Tool names must also resolve to capabilities available in the configured environment. Merely listing a documentation tool does not install or authenticate its MCP server.

Study-guide topics: tool selection, least-privilege planning, and environment capabilities. Reference: VS Code—Use tools with agents .

Repository custom agent profiles belong in .github/agents/ and use Markdown files with agent configuration and instructions. When the intended changes concern the agents’ roles, available tools, or operating guidance, these profiles are the appropriate implementation point.

An agent profile provides a durable definition that can be shared with other repository contributors. Keeping that definition under version control makes changes reviewable and enables the team to associate a particular agent configuration with the code revision used during evaluation. This is useful when diagnosing why an agent’s behavior changed after its instructions or capabilities were modified.

Editor settings and MCP connection settings address different concerns. They can affect the environment in which an agent operates, but they do not replace the agent’s own profile. Changing a server connection is appropriate for transport or authentication requirements; changing an agent profile is appropriate for agent behavior and capability selection.

The source selects C. Its applicability depends on the omitted planned changes actually concerning custom agent configuration.

Study-guide topics: agent profiles, configuration management, and SDLC traceability. Reference: GitHub—Creating custom agents .

===============

Copilot memory is an organization-level capability. Configuring it through the organization’s Copilot settings establishes the governance boundary, availability, and policy controls consistently for the developers and repositories covered by that organization.

Personal settings are unsuitable because they create inconsistent behavior between developers and do not provide centralized administration. A repository-level configuration can supply repository instructions and scoped context, but it does not replace the organization-level control that enables and governs the memory capability. An individual agent profile defines role behavior, tool access, prompts, and delegation settings; it is not the tenant-level location for enabling Copilot memory.

Organization configuration is particularly important when agents must retain approved context, recurring preferences, and workflow guidance across sessions without each developer configuring behavior independently. Central governance also allows administrators to maintain predictable controls over which organizational information is available to Copilot.

Study-guide topics: organizational governance, persistent context, and centralized agent configuration.

The tasks.md file is the execution-tracking document for the upgrade scenario. It records individual tasks, their validation criteria, and their completion status. Microsoft’s upgrade walkthrough specifically directs users to review this file when checking the status of every upgrade step.

A task can include several concrete verification activities, such as restoring dependencies, building the solution, correcting compilation errors, running the test suite, and rerunning tests after fixes. Reviewing these entries reveals whether implementation has merely been attempted or has satisfied the defined checks.

The assessment identifies upgrade issues and scope; it does not serve as the live record of completed work. A plan describes intended actions and ordering, which also differs from evidence that execution and testing succeeded.

The phrase “before App1 is upgraded” requires temporal care. Before execution, tasks.md identifies the steps and checks that must be performed. It cannot prove that future tests have already passed. Completion and test results become available as the agent executes and updates the tasks.

Study-guide topics: execution validation, task status, and acceptance criteria. Reference: Microsoft Learn—Execute and verify a Copilot upgrade .

===============

Yes, Yes, Yes

Comprehensive and Detailed 150 to 250 words of Explanation From Agentic AI Developer/Course Guide/topics:

All three statements are supported by explicit operational signals in the supplied logs.

The first statement is Yes . Each relevant session records Passing 1 MCP server(s) to SDK: [github] followed by github: type=http. These entries show that the GitHub MCP server is being supplied to the agent session as an available remote MCP integration. The CLIMCPServerEnabled=false entry concerns the separate CLI MCP configuration flag and does not negate the subsequently logged GitHub server passed to the SDK.

The second statement is Yes . The logs explicitly state workspace isolation mode selected for session and indicate that worktree creation is skipped. Therefore, the selected session isolation mechanism is workspace isolation rather than a separate Git worktree.

The third statement is Yes . Two distinct entries identify new Copilot CLI sessions with isNewSession: true: one beginning with session ID de04f0fe... and another with 6852c5dc.... Later MCP/configuration events do not contain another isNewSession: true record, so the evidence shows exactly two newly started sessions.

This type of log interpretation directly maps to the GH-600 requirement to identify failures and execution characteristics by analyzing logs, traces, outputs, and workflow artifacts , and to use operational signals when evaluating multi-agent behavior.

Study Guide Reference Topics: Perform Evaluation, Error Analysis, and Tuning; log and trace analysis; execution-context evaluation; MCP observability; multi-agent session analysis.

The agent session log is the appropriate starting point when the reported problem concerns an agent’s interaction, execution sequence, or tool activity within the development environment. It provides information closer to the failing behavior than repository-level workflow usage statistics.

A useful investigation establishes what the agent was asked to do, which operations it attempted, what responses those operations returned, and where progress stopped or diverged from the intended result. Session diagnostics can help distinguish an instruction problem from an unavailable tool, a rejected operation, or an execution error. VS Code also provides detailed chat debugging facilities for inspecting interactions and diagnosing failures.

GitHub Actions usage metrics primarily describe workflow consumption. Runner logs are relevant when evidence points to a hosted workflow or runner problem. The token permissions block becomes relevant when the failure concerns authorization to a GitHub resource. None should be assumed to be the root cause before examining the reported execution.

The PDF selects B; the underlying Dev1 incident description is not included, so this selection assumes a session-level agent issue.

Study-guide topics: diagnostic evidence, tool-call inspection, and failure localization. Reference: VS Code—Debug chat interactions .

The filter action:artifact.destroy selects the audit event associated with manual deletion of a workflow artifact. It directly targets the activity described in the scenario, allowing the investigator to examine the recorded actor and associated event details.

A repository filter narrows the search to a particular repository but does not distinguish artifact deletion from other recorded operations. It can usefully accompany the action filter when investigating a specific project. A workflow-run action concerns workflow execution rather than the manual removal of its stored artifacts. The generic operation:remove option does not select the documented artifact deletion event.

The investigation should correlate the deletion event with its timestamp and repository information, then inspect the actor recorded for that event. This identifies the account associated with the action; additional context may be needed when an application or automated identity performed it.

Artifact retention and audit logging serve separate purposes. Retention controls how long outputs are normally preserved, while the audit log records relevant administrative and user activity. Searching the audit log does not restore deleted content.

Study-guide topics: accountability, evidence preservation, actor attribution, and audit trails. Reference: GitHub—Organization audit log events .

Yes, Yes, No

The first statement is Yes . --autopilot permits Copilot CLI to continue autonomously through successive task steps, while --max-autopilot-continues 10 imposes a finite continuation boundary. GitHub specifically recommends this option for programmatic autopilot execution to prevent an agent from continuing indefinitely or entering a runaway loop.

The second statement is also Yes . --yolo is an alias for --allow-all. It grants permission for all available tools, paths, and URLs, encompassing activities such as file modifications and shell execution without individual approval prompts.

The third statement is No . This command is intentionally configured for hands-off autonomous execution . Autopilot continues through multiple reasoning/action cycles, and --yolo removes normal per-action permission checkpoints. Therefore, the configuration does not provide targeted human approval at key decision points. A workflow requiring such intervention should instead retain interactive controls or separate planning/approval from execution.

This distinction directly maps to GH-600 objectives covering autonomy levels, execution controls, guardrails, and configuring human intervention without unnecessarily disrupting delivery.

Study Guide Reference Topics: Manage Memory, State, and Execution; autonomous execution boundaries; continuation controls; guardrails; human-in-the-loop intervention.

tools: [ ' search ' , ' read ' , ' fetch ' ]

send: false

The completed configuration is:

name: planner-agent

description: Planning

tools: [ ' search ' , ' read ' , ' fetch ' ]

handoffs:

- label: Start Implementation

agent: implementer

prompt: Now implement the plan outlined above.

send: false

The planner must be restricted to read-only capabilities, so [ ' search ' , ' read ' , ' fetch ' ] is the correct tool set. search locates repository information, read inspects file contents, and fetch retrieves supporting information without modifying source files. The other available tool combinations contain write-capable operations such as edit, commit, push, merge, or publish, which would violate the requirem ent that the planner must not alter the repository before approval. VS Code custom agents explicitly support scoping tools so that planning agents can be constrained to research and analysis capabilities.

The send property must be false. A handoff appears as an interactive transition after the planner produces its response. With send: false, selecting the handoff switches to the implementation agent and pre-fills the implementation prompt, but the prompt is not automatically submitted. This provides the necessary human approval gate: the plan can be reviewed before implementation begins. By contrast, send: true immediately submits the handoff prompt after the transition.

Study Guide Reference Topics: agent role separation, least-privilege tool assignment, planning versus execution, multi-agent handoffs, and human approval gates.

===============

Target

Value

Top-level property

concurrency

Concurrency-group property

group

Cancellation property

cancel-in-progress

Result:

concurrency:

group: production

cancel-in-progress: true

The concurrency block defines a shared execution group. Assigning group: production places all production deployment runs into the same group, preventing simultaneous deployments to that target.

Setting cancel-in-progress: true changes the default behavior by cancelling an active deployment when a newer workflow run enters the group. This ensures that only the latest production deployment continues rather than allowing an outdated deployment to finish after a newer version has been requested.

The concurrency block is normally placed at the workflow level when the policy applies to the full deployment workflow. It can also be scoped to a job when only a specific deployment job needs coordination. The environment name identifies the production target, but environment configuration alone does not impose the required single-active-run and cancellation behavior.

A production concurrency group should be reserved for operations that genuinely target the same deployment resource. Reusing it for unrelated jobs would unintentionally serialize unrelated work.

Study-guide topics: deployment coordination, concurrency groups, cancellation policy, and safe production execution. Reference: GitHub Actions—Control concurrency .

Automatic compaction occurs when the conversation approaches the context-window threshold. The system summarizes or compresses earlier context so that the session can continue without exceeding the model’s available context capacity.

Compaction is driven by conversational context volume, not by the size of a local state file or elapsed session duration. It also does not mean that the agent switched models. The purpose is to retain the most relevant working information while reducing the amount of prior detail that must remain in the active context.

For long implementation sessions, developers should preserve important decisions in durable artifacts such as repository files, task lists, plans, issues, and commits. This reduces reliance on the conversation retaining every implementation detail verbatim. After compaction, the developer should verify the current plan, changed files, and pending tasks before authorizing consequential operations.

Study-guide topics: context-window management, compaction, durable state, and long-running agent sessions.

In plan mode, Copilot creates a plan before implementation and saves that plan to plan.md. This makes the proposed approach available for review, refinement, and continuation rather than immediately executing repository changes.

The plan file creates a durable handoff point between planning and implementation. A developer can inspect the proposed work, assess dependencies and risk, adjust tasks, and decide whether implementation should proceed. This separation is essential for workflows that require approval before modification.

Plan mode does not automatically open a pull request or create a branch. It also does not begin implementation simply because a plan was generated. Those actions require a subsequent transition to an implementation workflow or a direct instruction from the user.

Study-guide topics: planning mode, durable plans, state persistence, and staged agent execution.

===============

A fine-grained PAT restricted to product-api provides an enforceable repository-level authorization boundary for agent1. GitHub fine-grained personal access tokens can be limited to selected repositories and assigned only the repository permissions required by the workload. Consequently, even if agent1 attempts to access billing-service or infra-terraform, the credential does not authorize access to those repositories. GitHub specifically recommends fine-grained PATs when repository access must be restricted to particular repositories.

This directly aligns with the GH-600 objective to configure an agent ' s scope to a specific repository and define execution boundaries through repository context and permissions. Microsoft Learn defines execution context as including the repository an agent can access and emphasizes that repository scope is the first boundary limiting agent behavior.

Option A provides behavioral guidance but is not a security authorization boundary. Option B controls the permissions available to the workflow token but does not, by itself, establish the required cross-repository credential restriction. Option D only prevents certain push operations; it does not stop agent1 from reading or otherwise accessing the other repositories.

Study Guide Reference Topics: Implement Tool Use and Environment Interaction → execution context and boundaries; repository-specific agent scope; tool permissions; least-privilege authentication.

Separate branches isolate each agent’s proposed changes and allow the team to inspect them independently. Adding a required status check for file-level overlap detects conflicting modifications before either pull request is merged, preventing one agent’s work from silently overwriting another’s changes.

A read-only tool configuration prevents both agents from making required changes, so it avoids conflict by eliminating implementation capability rather than controlling it. CODEOWNERS approval adds review accountability for a specific file but does not automatically detect overlap between independent agent outputs. A single concurrency group serializes entire workflows and reduces throughput even where the agents work on unrelated files.

The selected solution maintains parallel development while creating a merge-time control for the actual risk: overlapping file changes. It also produces reviewable evidence of the overlap check in pull request status results.

Branch isolation does not eliminate semantic conflicts, such as incompatible API assumptions. Teams should therefore combine overlap detection with normal pull request review and integration testing.

Study-guide topics: parallel agent coordination, branch isolation, merge controls, and conflict detection.

The API key should be stored as a secret in the Copilot environment and referenced by name from the MCP configuration. This keeps the secret value out of repository files, agent prompts, pull requests, and ordinary workflow output while allowing the MCP server to receive the required credential at runtime.

A plaintext key in a configuration file is unacceptable because repository history, forks, logs, and code review systems can expose it. A Codespaces user secret is scoped to a user development environment and does not provide the intended runtime secret for the Copilot agent environment. A GitHub Actions secret is useful for workflow expressions, but the scenario requires the key to be available to the MCP server configuration itself.

The prefixed environment-secret approach creates a clear boundary: the configuration references an identifier, while the secret value is resolved only in the authorized execution environment. This supports rotation without changing tracked configuration content.

Study-guide topics: MCP authentication, secrets management, secure environment configuration, and credential isolation.

The first statement is Yes . When an MCP server is configured for a repository, GitHub Copilot cloud agents can use the enabled MCP tools autonomously during assigned tasks. GitHub specifically notes that Copilot does not request interactive approval before invoking configured MCP tools, making careful tool allowlisting and credential protection important.

The second statement is No . For repository-level MCP integration, Copilot cloud agent currently supports MCP tools , but it does not support MCP resources or MCP prompts exposed by the server. Resources and prompts are available in other MCP-capable Copilot experiences, such as IDE chat, but they are not consumed by the cloud coding agent in this configuration.

The third statement is Yes under the planned configuration. Litware requires agent1 to access all available tools . GitHub custom-agent configuration supports this by omitting the tools property or specifying tools: [ " * " ]. Likewise, an MCP server can use " * " to expose all of its tools. Consequently, newly introduced MCP1 tools fall within that wildcard authorization and become available without individually adding each tool name.

Study Guide Reference Topics: MCP tool integration, custom-agent tool configuration, autonomous tool invocation, MCP capability boundaries, and least-privilege agent execution.

The mcp-servers property connects a custom agent to the Model Context Protocol servers required for its planned work. MCP configuration makes defined external tools and services available to the agent in a controlled, declarative manner.

Adding a broad natural-language instruction such as “Use all available tools” does not configure a server connection, authenticate a tool, or define which external capabilities are available. It is also poor least-privilege design because it encourages unrestricted tool use without establishing a technical permission boundary.

Setting tools: [] removes all configured tools and would prevent the agent from using required capabilities. Deleting the tools line could cause the agent to inherit or expose a broader default tool set than intended. Repository-wide instructions can guide behavior, but they do not replace the agent-specific configuration needed to associate MCP servers with that agent.

A well-designed configuration identifies only the MCP servers necessary for the role, supplies secrets through approved environment mechanisms, and limits the resulting tools to the agent’s defined task.

Study-guide topics: MCP integration, agent tool configuration, and least-privilege environment access.

===============