GitHub GH-600: Manage memory, state, and execution Practice Questions

Options A, B, and F are correct. Option B (external semantic search with on-demand retrieval) addresses the context window constraint by keeping historical data outside active context and pulling only relevant information — this is the 'external memory' pattern that prevents context overflow. Option A (compressing completed batches into durable archived artifacts) directly maps to 'capturing task progress and decisions as durable artifacts' and ensures older findings do not passively linger in context. Option F (staleness thresholds requiring explicit confirmation) directly addresses 'preventing stale context from influencing agent decisions' — findings older than the threshold are not ignored but must be deliberately retrieved and confirmed, giving the agent control over historical influence. Option D is wrong because a simple rolling window discards older findings entirely rather than archiving them — this causes loss of important audit history that may need to be retrieved deliberately. Option E is wrong because upgrading to a larger context model does not solve the architectural problem of stale context influence; even with a larger window, six-month-old findings would silently affect decisions. Option C is wrong because replicating the full context to all tool endpoints introduces massive redundancy, amplifies stale context problems across every integration, and contradicts the principle of scoping context to task-relevant information.

Option B is correct because persisting only task-relevant, user-approved artifacts (document structure and headings) as long-term memory satisfies the requirement to remember decisions without retaining unnecessary rejected content — this is scoping agent memory to task-relevant information. Option C is wrong because storing all rejected drafts in short-term memory wastes context and violates the principle of scoping memory; short-term memory does not persist across sessions anyway. Option A is wrong because embedding every message — including rejected drafts — in an external store contradicts the goal of discarding non-relevant content and would cause stale, unwanted context to influence future decisions. Option D is wrong because re-injecting the full prior transcript each session bloats the context window and makes the agent process information the user explicitly rejected, risking context drift.

Options A and C are correct. Option A (locking) is the classical concurrency control mechanism — preventing simultaneous writes to shared state eliminates the race condition directly. Option C (isolated namespaces with a conflict-resolution merge layer) is the modern agent-design pattern that lets each session operate independently and then reconciles changes safely before committing, directly addressing the 'preventing conflicting context between concurrent agent sessions' skill. Option D is wrong because increasing polling intervals only reduces collision probability and does not eliminate conflicts; under load, the race condition will still occur. Option B is wrong because putting shared deployment config in each agent's short-term in-context memory does NOT eliminate shared state — it duplicates it, making conflicts worse and losing cross-session visibility. Option E is wrong because a shared system prompt aligns intent but does nothing to coordinate writes to external state; both agents could make independent, well-intentioned but conflicting changes with identical system prompts.

Option A is correct because the described symptom — the agent acting as if approval was not yet granted when it clearly was — is a classic cross-tool context inconsistency. When each tool integration maintains its own siloed view of state, later tool calls read stale snapshots. The fix is a shared canonical state object (a centralized state record) that is updated atomically after each tool action and passed into every subsequent invocation, directly addressing the 'sharing agent state across tools and environments' and 'preventing stale context from influencing agent decisions' skills. Option B is wrong because the scenario explicitly states the approval was posted to Slack successfully — the problem is not delivery but the agent's subsequent context when calling GitHub. Option C is wrong because API propagation delay would affect whether GitHub sees the PR, not whether the agent knows approval was granted; the agent's own state tracking is the broken link. Option D is wrong because the system prompt governs the agent's general behavior and goals — it does not resolve runtime state synchronization across tool invocations.

Option D is correct because capturing task progress and decisions as durable, externally persisted artifacts (a progress ledger or checkpoint file) allows a new agent instance to read the ledger, determine what has already been completed, and resume from the correct point — directly addressing the 'capturing task progress as durable artifacts' and 'resuming without repeating steps' competencies. Option A is wrong because re-running from the start wastes time and can cause unintended side effects even with idempotency; it does not represent a resume strategy. Option B is wrong because in-context memory is volatile and does not survive process termination; there is no 'context allocation' that persists across restarts. Option C is wrong because requiring manual re-entry introduces human error, breaks automation, and is not a scalable or reliable pattern for agent continuity.