Pull request review assistant

Blocking a contributor is a high-cost action, while an inline suggestion is cheap to ignore. So I gate the request_changes tool, not every comment. In LangChain v1 I pass HumanInTheLoopMiddleware to create_agent with interrupt_on for that tool and allowed decisions approve, edit and reject. The agent needs a checkpointer, because the interrupt pauses the LangGraph run and persists state on the thread. My worker surfaces the draft to a maintainer, then resumes the same thread_id with their decision. Edit lets them fix wording or drop findings before posting. This keeps humans focused on judgement calls, and the reject rate becomes a direct quality signal for the checklist and prompt.

Sourced from Docs by LangChain (MCP)

A GitHub App webhook receives pull request events, verifies the HMAC signature and enqueues a job keyed by repo, PR number and head SHA. A worker picks up the job and builds a create_agent agent. It uses a model from init_chat_model, GitHub tools adapted from an MCP server via MultiServerMCPClient, a sandboxed run_linters tool, and middleware that includes HumanInTheLoopMiddleware on request_changes. The agent loads the repo checklist from the LangGraph store, reads the diff, runs linters and returns findings through response_format. Non-blocking comments are posted directly. Blocking reviews pause, the checkpointer persists the state, and the review waits for a maintainer decision in a dashboard or Slack. On approval, the review is submitted against the head SHA and written to the audit log.

Sourced from Docs by LangChain (MCP)

Webhooks are delivered at least once, and developers push in bursts, so the key does two jobs. The same repo, PR and SHA means the same code, so a redelivered event is a duplicate and is dropped. A newer SHA on the same repo and PR makes older jobs obsolete. The queue marks those jobs superseded, and running workers check that flag before posting anything. This keeps cost proportional to distinct commits rather than to events. It also stops a review of stale code from landing after the developer has already pushed a fix. I would enforce the key with a unique constraint in the job store, not only with in-memory checks, so it survives worker restarts and multiple webhook replicas.

Sourced from Docs by LangChain (MCP)

A worker can crash after GitHub accepts a comment but before we record it, so a retry might post twice. I compute deterministic keys: - per finding, from repo, PR, SHA, file, line and checklist item - per review, from repo, PR, SHA and thread Before posting, the tool checks the audit store for the key. After posting, it records the ID GitHub returns. If the record is missing after a crash, the tool lists existing review comments on the PR and matches a hidden marker embedded in each comment body. This makes the post tool safe under at-least-once execution. That matters because tool retries and resumes from checkpoints can re-run calls.

Sourced from Docs by LangChain (MCP)

The paused review targets an old SHA. Approving it could block the PR over code that has already been fixed. When the newer SHA arrives, the webhook enqueues a new job and marks the old thread superseded. The dashboard or Slack message is updated to show the draft as stale, and the server refuses approve actions for superseded threads. As a final guard, the post tool checks the PR's current head before submitting and refuses if the head has moved. Reviews are also submitted with commit_id set to the reviewed SHA. The new commit gets its own review from scratch, which may re-raise issues that still apply.

Sourced from Docs by LangChain (MCP)

Offline, I build a set of historical PRs with known issues and real maintainer comments. I measure precision and recall per checklist item and severity, watching false blocking findings most closely. Online, I track: - approve, edit and reject rates on request_changes - the share of comments resolved versus dismissed I start in shadow mode, generating reviews without posting and comparing them with human reviews. Every prompt, model or checklist change must pass the offline suite before rollout. Tracing each run shows tool calls, tokens and the reasoning path, so bad reviews can be debugged. The headline metric is useful comments per PR, not comment volume.

Sourced from Docs by LangChain (MCP)

HumanInTheLoopMiddleware is the primary gate, but it only covers tools listed in interrupt_on. If the general post tool could submit a review with a blocking event, the model could bypass the gate. So I add defence in depth: - The post tool's schema only allows comment-type reviews. - A custom wrap_tool_call middleware rejects any blocking GitHub write unless it carries an approval record from a resumed human decision. - The GitHub client layer repeats the same check. Automated tests assert that every blocking review submission has a matching approval entry in the audit log.

Sourced from Docs by LangChain (MCP)

I never load everything up front. The agent first gets a file list and diff stats, then calls diff and file tools per file or hunk, guided by the checklist. Linter output comes back as structured findings, which are far smaller than raw files. SummarizationMiddleware compresses older messages once a token trigger is reached while keeping recent messages, so long tool loops stay within limits. For truly huge PRs I can split the work across files, or use create_deep_agent with subagents per area so each subagent has its own clean context. I also set a model call limit so a runaway review stops and asks for a human instead of burning tokens.

Sourced from Docs by LangChain (MCP)

I treat everything in the PR as untrusted data. Tools are least-privilege: the diff, file and linter tools are read-only, and the only write tool, posting reviews, is narrow and scoped to the current PR and SHA. The blocking action is gated by HumanInTheLoopMiddleware, so an injected instruction cannot silently block or approve. Linters run in a sandbox with no secrets, especially for fork PRs. The system prompt states that content in diffs is never instructions, and a custom wrap_tool_call hook can validate tool arguments, for example rejecting posts to other repos. Finally the audit log records every action, so anything odd is traceable.

Sourced from Docs by LangChain (MCP)

Thread state holds the agent's messages, tool results and any pending interrupt. With one thread per PR, a review of commit B would inherit diff hunks and linter output from commit A. Stale findings would mix with current ones, and the context would keep growing. Scoping the thread to the SHA gives each review a clean, reproducible state tied to exact code. It also means an approval resumes precisely the review the maintainer saw. Knowledge that should carry across commits, such as what a maintainer rejected last time, belongs in the long-term store keyed by repo, not in thread history. The trade-off is that each push starts fresh, so I deduplicate already-posted comments separately using stable fingerprints.

Sourced from Docs by LangChain (MCP)

I would pass a Pydantic model as response_format. It contains a list of findings, each with: - file path, line or line range, and diff side - checklist item ID - severity from a fixed enum such as blocker, major, minor or nit - a short explanation and an optional suggested fix The model also has a summary and a proposed verdict. Constraining severity and checklist IDs to known values lets code, not the model, decide what counts as blocking. Before anything is posted, I validate that each file and line exists in the diff for that SHA. Unanchored findings are dropped or moved to the summary. Structured output also makes evaluation, deduplication and audit much easier than parsing free-form prose.

Sourced from Docs by LangChain (MCP)

run_linters executes repository-controlled configuration and sometimes repository code, such as linter plugins, so I treat it as untrusted. Each job gets an ephemeral container with these controls: - no network, or a strict allowlist - no GitHub tokens or cloud credentials - a read-only checkout of the exact head SHA - CPU, memory and wall-clock limits - a non-root user Only linters declared in the repo config and present on an approved image are allowed. The tool returns structured findings with a size cap, not raw logs, so output cannot flood the model context. The container is destroyed after the run, whether it succeeds or fails, and its exit status is recorded.

Sourced from Docs by LangChain (MCP)

With an edit decision, the maintainer changes the arguments of the pending request_changes call, and the tool then runs with those edited arguments. Typical edits are rewording a comment, dropping a finding or lowering a severity. I present the draft as editable fields rather than raw JSON. The edited payload is validated against the same schema before resuming: files and lines must exist in the diff, text lengths are capped, and disallowed mentions are stripped. The audit log stores both the original model proposal and the edited version, with the editor's identity. That difference is valuable feedback for tuning prompts and checklists. Invalid edits are rejected in the UI, and the thread is not resumed until they are fixed.

Sourced from Docs by LangChain (MCP)

I would work from stated assumptions and then measure. Say an organisation produces a few thousand distinct PR commits a day after deduplication, with peaks several times the average during working hours. Each review is a handful of model calls plus one linter container run. Linting is often the slowest step, so worker concurrency is sized by available sandbox containers rather than by LLM calls. Token cost scales with diff size, so I would measure the distribution of changed lines per PR and set per-review budgets. The key metrics are queue depth, time to first comment and cost per review. Checkpointer and store load is modest, roughly a few writes per agent step per thread.

Sourced from Docs by LangChain (MCP)

I configure model fallback middleware with an ordered list of alternative models created via init_chat_model. If the primary model fails, the next one is tried. Because output goes through response_format, every fallback must support structured output reliably. Each must also be evaluated on the same review benchmark, because a weaker model raising false blockers is worse than a delayed review. If all models fail, the queue retries the job with backoff. The checkpointer has saved progress, so the job resumes from the last completed step instead of rerunning linters. If it still fails, the worker posts a neutral status note so developers aren't left waiting silently.

Sourced from Docs by LangChain (MCP)

Tool retry middleware handles transient failures such as timeouts and 5xx responses, using exponential backoff with jitter and a capped number of attempts. Rate limits need more than retries: - The GitHub client respects rate-limit headers and retry-after values. - Workers share a per-installation token bucket, so one busy organisation cannot starve others. Retries are safe only for reads or idempotent writes, which is why posting uses idempotency keys. Non-retryable errors, such as a 404 for a deleted branch or a 422 for an invalid comment position, either go back to the agent as a tool error or fail the job cleanly. They should never be retried blindly.

Sourced from Docs by LangChain (MCP)

I apply least privilege. The app needs: - read access to contents and pull requests - write access to pull request reviews and comments - pull request webhook events It gets no admin, workflow or settings permissions. Installation tokens are short-lived, minted per job and scoped to the target repository where possible. Tokens live only in the worker process. They never appear in the model context, prompts, traces or the linter sandbox. The webhook secret and the app's private key are kept in a secrets manager and rotated. The agent reaches GitHub only through its tools, and each tool enforces which operations it may perform, regardless of what the model asks.

Sourced from Docs by LangChain (MCP)

Diffs sometimes contain leaked credentials or personal data. Sending them to an external model or echoing them in a comment is a real exposure. I run a secret scanner over the diff before the model sees it. Matches are replaced with placeholders, and the leak is raised as its own finding routed to the security team. PIIMiddleware can redact or mask emails, phone numbers and similar patterns in model inputs, and block outputs that would post them. Repositories whose policy forbids external model providers can be routed to an approved provider or excluded. Logs and traces get the same redaction, and diff content is kept only for a short retention period.

Sourced from Docs by LangChain (MCP)

Models often get line numbers wrong, and GitHub inline comments must anchor to lines present in the diff for that commit. I give the model hunks annotated with explicit new-file line numbers and require file and line in the structured output. Then code validates each finding deterministically against the parsed diff. If a line falls outside every hunk, I try snapping it to the nearest changed line in the same hunk. Otherwise the finding moves into the review summary. Comments are submitted with the reviewed SHA as the commit ID and the correct diff side, so they stay attached properly as the PR evolves.

Sourced from Docs by LangChain (MCP)

Developers ignore a noisy bot, so I use several controls: - a per-repo severity threshold for inline comments - merging duplicate instances of an issue into one comment - capping inline comments per review and summarising the rest - suppressing issues linters already report, unless the agent adds real context Across pushes, new findings are compared with those already posted on earlier SHAs using a stable fingerprint, and unchanged issues are not reposted. Checklist items that maintainers consistently dismiss are down-weighted through long-term memory. I track the dismissed-comment rate per checklist item and tune the checklist before touching the prompt.

Sourced from Docs by LangChain (MCP)

Resuming with a decision is a privileged action. The dashboard authenticates users. Slack interactions are verified with Slack's request signing, and Slack users are mapped to GitHub identities. At the moment of decision, the server checks that the person has maintainer or write rights on that repository, using GitHub permissions as the source of truth. The decision is bound to the thread ID and SHA, created server-side and single-use, so it cannot be replayed onto another PR. Organisations can also forbid PR authors from deciding on reviews of their own changes. Every decision records the verified identity in the audit log.

Sourced from Docs by LangChain (MCP)

I roll out in stages: 1. Shadow mode on a few volunteer repositories. The agent runs fully but writes only to the dashboard, and maintainers rate the findings. 2. Non-blocking comments enabled. 3. The request_changes path enabled, behind human approval. Each stage is controlled by a per-repo feature flag. New models, prompts or checklists go through an offline regression suite, then a canary on a subset of repositories, comparing approve and reject rates. A kill switch disables all posting instantly. Integration tests run against a test GitHub organisation, so production repositories are never used for experiments.

Sourced from Docs by LangChain (MCP)

Fork PRs are untrusted code and untrusted text. The linter sandbox already assumes hostile code, but for forks I tighten it further: no network, no repo-specific secrets and possibly a reduced linter set. The checklist and agent configuration are loaded from the store or the base branch, never from the fork, so a PR cannot rewrite its own review rules. Posting always uses our app's installation token. Nothing supplied by the fork is used as a credential. To limit abuse and cost, maintainers can require a label or approval before the assistant reviews a first-time contributor's PR.

Sourced from Docs by LangChain (MCP)

A GitHub MCP server accessed through MultiServerMCPClient gives the agent ready-made tools for diffs, file contents and comments. These are exposed as ordinary LangChain tools, so middleware such as tool retry and human-in-the-loop applies to them unchanged, and other teams can reuse the same server. The trade-off is less control. MCP servers can expose far more tools than you need, including write operations. I would filter the loaded tools to a small read-only allowlist. Write actions like posting comments and request_changes stay as my own wrapped tools, so I control idempotency and policy. I would also pin the server version so tool schemas don't drift.

Sourced from Docs by LangChain (MCP)

On reject, request_changes does not run. The agent receives the rejection, optionally with the maintainer's reason, as feedback. I set the follow-up in policy rather than leaving it to the model. Usually the agent may either post the findings as non-blocking comments or a summary, or end with no review. It must not try another blocking path. A model call limit stops it looping on alternatives. The rejection and reason are written to the audit log. Repeated rejections of the same checklist item are recorded in the long-term store, so future reviews treat that item more cautiously.

Sourced from Docs by LangChain (MCP)

Agent loops can run away. The model may keep requesting files, re-running linters or retrying after a rejection. The model call limit middleware caps model calls per run or thread, which puts a hard ceiling on cost and latency per review. When the cap is hit, I end gracefully: the agent posts whatever validated findings exist as a partial summary, clearly marked incomplete, instead of discarding the work. I pair the cap with tool-level rules, such as running run_linters once per SHA, and a token budget scaled to diff size. Tracking how often reviews hit the cap shows whether the limit or the prompts need adjusting.

Sourced from Docs by LangChain (MCP)

Each record captures: - repo, PR number, head SHA and thread ID - checklist version and the model actually used, including any fallback - the proposed review payload and the human decision type - the edited payload, if any, and the decider's identity and timestamp - the review ID GitHub returns Records are append-only and stored with restricted write access, so nobody can quietly rewrite an approval. I index by repo and PR for investigations and by reviewer for accountability. Keeping the proposal and the final version separately makes edit and rejection rates easy to measure. Personal data is minimised, and retention follows the organisation's policy.

Sourced from Docs by LangChain (MCP)

The LangGraph store persists across threads. Alongside checklists under ("checklists", repo), I would keep a namespace such as ("review_feedback", repo). Its documents capture rejected or edited findings: the checklist item, the code pattern and the maintainer's reason. When a review starts, the worker loads relevant feedback, optionally using the store's semantic search, and adds it to the system prompt. Writes are controlled. Feedback is recorded only from explicit maintainer decisions, never from the model's self-assessment. It also stays visible and reviewable, so one hasty rejection cannot silently disable a checklist item for the whole repository.

Sourced from Docs by LangChain (MCP)

create_deep_agent pre-assembles filesystem access, summarization, subagents and prompt caching, which suits long, multi-step tasks. For most PRs, create_agent with a few tools and explicitly chosen middleware is simpler, cheaper and easier to audit, because I know exactly what runs. I would consider a deep agent for very large or cross-cutting PRs. There, delegating modules to subagents and keeping working notes in a filesystem genuinely helps. Whichever I choose, the human approval gate on request_changes must be configured and tested explicitly. I would not assume any preset provides it.

Sourced from Docs by LangChain (MCP)

Checklists change, and a paused review might be resumed after someone edits one. I store checklists in the LangGraph store with a version field. When a review starts, the version used is recorded in thread state and in the audit log. A resumed review keeps the version it started with, so the maintainer approves exactly what was checked. Checklist changes go through review, ideally sourced from a file in the repository that is synced to the store, which gives history and ownership. When evaluation shows a regression, it can be traced to a specific checklist version.

Sourced from Docs by LangChain (MCP)

Isolation comes from these measures: - Store namespaces include organisation and repo, and thread IDs include the repo. - Store reads are scoped by the installation the job came from, never by values the model supplies. - Installation tokens only cover that installation's repositories. - Linter sandboxes are per job, with no shared volumes. - Queues use fair scheduling per installation, so one large monorepo cannot starve others. - Model provider choice can differ per tenant where data-handling rules require it. Dashboards and audit views filter results by the viewer's own GitHub permissions.

Sourced from Docs by LangChain (MCP)

Interrupted threads can wait forever. I set a per-repo response window: the system sends a Slack reminder, then expires the review. On expiry, the worker resumes the thread with a reject decision, recorded as expired rather than as a human choice. The agent then posts the findings as non-blocking comments instead. Supersession by a newer SHA also expires a review. The dashboard shows how long each review has been pending, so maintainers can triage. Checkpoint data for expired threads is cleaned up according to the retention policy. The system must never auto-approve on timeout, because that would break the human approval rule.

Sourced from Docs by LangChain (MCP)

The main levers are: - Send only relevant hunks and the surrounding files actually needed. - Use SummarizationMiddleware to compress older messages once history passes a token threshold. - Use the LLM tool selector so the model sees only relevant tools. - Cap model calls per review. - Route docs-only or trivial PRs to a cheaper model, or rely on linters alone. - Drop superseded SHAs before any model call. Prompt caching helps where the provider supports it, because the system prompt and checklist are stable across reviews. I track cost per review and per repository so expensive outliers show up quickly.

Sourced from Docs by LangChain (MCP)

1. APIIMiddleware
2. BLLM tool selector middleware
3. CSummarizationMiddleware
4. DHumanInTheLoopMiddleware with interrupt_onCorrect answer

Why: HumanInTheLoopMiddleware interrupts on configured tools and offers approve, edit and reject decisions before the tool executes.

Sourced from Docs by LangChain (MCP)

1. AAsk the model whether the payload looks genuine
2. BCheck that the User-Agent header starts with GitHub
3. CCompute an HMAC-SHA256 of the raw body with the webhook secret and compare it, in constant time, to the X-Hub-Signature-256 headerCorrect answer
4. DAccept the event if the repository name exists in the database

Why: GitHub signs webhook payloads with the shared secret. Verifying the HMAC over the raw body is the reliable authenticity check, and headers or names can be spoofed.

Sourced from Docs by LangChain (MCP)

1. AParsing markdown from the final message with regular expressions
2. BAsking the model to write the findings to a temporary file
3. CStoring them in the checkpointer only
4. DSetting response_format on create_agent with a schemaCorrect answer

Why: response_format gives structured output that matches a defined schema, so downstream code can validate and post the findings reliably.

Sourced from Docs by LangChain (MCP)

1. Amerge, close and reopen
2. Ballow and deny only
3. Capprove, edit and rejectCorrect answer
4. Dretry, skip and escalate

Why: interrupt_on is configured per tool, with allowed decisions chosen from approve, edit and reject.

Sourced from Docs by LangChain (MCP)

1. AA model fallback list
2. BA response_format schema
3. CA vector store retriever
4. DA checkpointer with a stable thread_idCorrect answer

Why: Short-term state is thread-scoped through the checkpointer, which persists the interrupted run so it can resume with the human's decision.

Sourced from Docs by LangChain (MCP)

1. Ainitialize_agent
2. BAgentExecutor
3. Ccreate_agentCorrect answer
4. DLLMChain

Why: LangChain v1 builds agents with create_agent (createAgent in JS) from a model, tools and an optional system prompt, running on LangGraph.

Sourced from Docs by LangChain (MCP)

1. AIt verifies webhook signatures
2. BIt adapts tools from the GitHub MCP server into LangChain tools the agent can callCorrect answer
3. CIt persists paused threads
4. DIt runs linters inside containers

Why: The LangChain MCP adapters, including MultiServerMCPClient, expose MCP server tools as LangChain tools.

Sourced from Docs by LangChain (MCP)

1. AThe PR title
2. BThe developer's username
3. CThe same repo, PR number and head SHACorrect answer
4. DThe webhook delivery timestamp

Why: Jobs are keyed by repo, PR number and head SHA, so redelivered events for the same code are dropped.

Sourced from Docs by LangChain (MCP)

1. AIt is superseded and should not post a reviewCorrect answer
2. BIt runs first so reviews stay in push order
3. CIt is merged with the new job into a single thread
4. DIt is retried with a higher priority

Why: Newer SHAs supersede older ones, which prevents stale reviews of code that has already changed.

Sourced from Docs by LangChain (MCP)

1. ALLM tool selector
2. BSummarizationMiddleware
3. CModel fallback middlewareCorrect answer
4. DPIIMiddleware

Why: Model fallback middleware tries the configured fallback models in order when a model call fails.

Sourced from Docs by LangChain (MCP)

1. Aafter_model
2. Bwrap_model_call
3. Cwrap_tool_callCorrect answer
4. Dbefore_model

Why: wrap_tool_call wraps tool execution, so it can inspect a tool call's arguments and refuse it before it runs.

Sourced from Docs by LangChain (MCP)

1. ARedact, mask or blockCorrect answer
2. BLog, alert or ignore
3. CEncrypt, sign or hash
4. DTranslate, paraphrase or drop

Why: PIIMiddleware can redact, mask or block detected PII such as emails and phone numbers.

Sourced from Docs by LangChain (MCP)

1. AGitHub rejects reviews without a SHA on public repositories
2. BIt lets GitHub merge the PR automatically
3. CIt removes the need for human approval
4. DIt ties the review and its comments to the exact code that was reviewed, not to whatever the head becomes laterCorrect answer

Why: Pinning the review to the reviewed commit stops feedback from being attached to newer code the agent never saw.

Sourced from Docs by LangChain (MCP)

1. AIn the webhook handler process
2. BIn a sandboxed container on the checked-out head SHACorrect answer
3. CInside the model provider's servers
4. DOn the developer's laptop

Why: Linters run in a sandbox on the exact SHA, which isolates untrusted repository code and keeps results reproducible.

Sourced from Docs by LangChain (MCP)

1. AClosing the pull request
2. BNon-blocking review commentsCorrect answer
3. CA request changes review
4. DBranch protection changes

Why: Only non-blocking comments are posted directly. request_changes is paused for maintainer approval.

Sourced from Docs by LangChain (MCP)

1. ANo checkpointer, relying on the queue only
2. BLocal files on the webhook server
3. CA durable, database-backed checkpointer shared by all workersCorrect answer
4. DAn in-memory checkpointer on each worker

Why: Paused state must survive restarts and be resumable from any worker, which needs durable shared persistence.

Sourced from Docs by LangChain (MCP)

1. ARunning the linters again
2. BUsing a larger context window
3. CLowering the model temperature
4. DA deterministic idempotency key checked against recorded posts or a hidden marker in existing commentsCorrect answer

Why: Idempotency keys make the post tool safe under at-least-once execution, because existing posts can be detected before posting again.

Sourced from Docs by LangChain (MCP)

1. AIn a LangGraph store namespaced by repoCorrect answer
2. BIn SummarizationMiddleware's kept messages
3. CIn the checkpointer's thread state
4. DIn the system prompt hard-coded per deploy

Why: LangGraph stores hold long-term JSON documents by namespace and key, shared across threads, unlike thread-scoped checkpointer state.

Sourced from Docs by LangChain (MCP)

1. AThe API key followed by the model name
2. BA URL to the model's weights
3. C"provider:model"Correct answer
4. DA JSON schema of the response

Why: init_chat_model takes an identifier like "provider:model", which makes it easy to switch providers or add fallbacks.

Sourced from Docs by LangChain (MCP)

1. AAll pushes to a PR share one growing conversation
2. BThe checklist is stored per SHA
3. CInterrupts cannot be persisted
4. DEach new push starts a fresh thread with its own short-term stateCorrect answer

Why: Short-term memory is thread-scoped through the checkpointer, so a new SHA means a new thread and a clean state.

Sourced from Docs by LangChain (MCP)

1. Atrigger ("tokens", 4000) and keep ("messages", 20)Correct answer
2. Binterrupt_on {"request_changes": True}
3. Cfallback ["provider:model"]
4. Dnamespace ("checklists", repo)

Why: SummarizationMiddleware takes a trigger such as a token threshold and a keep setting such as the number of recent messages to retain.

Sourced from Docs by LangChain (MCP)

1. AModel call limit middlewareCorrect answer
2. BSummarizationMiddleware
3. CHumanInTheLoopMiddleware
4. DPIIMiddleware

Why: A model call limit caps how many model calls a run can make, which bounds cost and latency.

Sourced from Docs by LangChain (MCP)

1. AIt lets the maintainer modify the tool call's arguments, which then run with the edited valuesCorrect answer
2. BIt deletes the thread's checkpoint
3. CIt restarts the whole review from scratch
4. DIt converts the review into an approval

Why: Edit means the human changes the pending tool call's arguments before it executes.

Sourced from Docs by LangChain (MCP)

1. AThe agent switches to a fallback model
2. BThe tool does not run, and the agent receives the rejection as feedbackCorrect answer
3. CThe tool runs anyway but is logged as rejected
4. DThe PR is closed automatically

Why: Reject stops the tool call from executing and returns feedback to the agent, which then follows the configured policy.

Sourced from Docs by LangChain (MCP)

1. AThe review, the decision and the reviewerCorrect answer
2. BThe model's API key
3. CThe full container image
4. DOnly the PR title

Why: Step 8 writes the review, the decision and the reviewer to the audit log for accountability.

Sourced from Docs by LangChain (MCP)

1. AThe model proposing an incorrect finding
2. BA maintainer rejecting a review
3. CA transient timeout or 5xx from the GitHub API on a read callCorrect answer
4. DA failed webhook signature check

Why: Tool retry handles transient tool errors. Logic, policy and security failures should not be retried.

Sourced from Docs by LangChain (MCP)

1. AAs messages inside each thread
2. BAs files in the Git repository
3. CAs JSON documents under a namespace and key, with optional semantic searchCorrect answer
4. DAs rows in a fixed SQL table per agent

Why: LangGraph stores hold JSON documents addressed by namespace and key and can support semantic search.

Sourced from Docs by LangChain (MCP)

1. AAuto-approve so the PR isn't stalled
2. BSubmit request changes without a reviewer
3. CDelete the audit log entry
4. DExpire it as a non-human rejection and never auto-approveCorrect answer

Why: Blocking reviews require human approval, so a timeout must not approve. It should expire safely and be logged as such.

Sourced from Docs by LangChain (MCP)

1. Ainterrupt_on
2. Bwrap_tool_call
3. Cbefore_modelCorrect answer
4. Dresponse_format

Why: before_model runs ahead of each model invocation and can adjust the state or messages the model will see.

Sourced from Docs by LangChain (MCP)

1. ALLM tool selectorCorrect answer
2. BSummarizationMiddleware
3. CTool retry middleware
4. DModel fallback middleware

Why: The LLM tool selector chooses the relevant subset of tools, which reduces prompt size and the chance of misuse.

Sourced from Docs by LangChain (MCP)

1. AbuildReactAgent
2. BcreateAgentCorrect answer
3. Cnew AgentExecutor
4. DmakeAgent

Why: LangChain v1 exposes create_agent in Python and createAgent in JS.

Sourced from Docs by LangChain (MCP)

1. AFilesystem, summarization, subagents and prompt cachingCorrect answer
2. BGitHub App authentication
3. CLinter sandboxing
4. DWebhook verification and job queues

Why: Deep Agents pre-assemble filesystem tools, summarization, subagents and prompt caching for long tasks.

Sourced from Docs by LangChain (MCP)

1. APIIMiddleware and model fallback
2. BWebhooks, queues and cron jobs
3. CCheckpointer, thread_id and interrupts
4. DDocument loaders, text splitters, embeddings, a vector store and a retrieverCorrect answer

Why: RAG in LangChain is built from document loaders, text splitters, embeddings, vector stores and retrievers.

Sourced from Docs by LangChain (MCP)