Internal Agents Map

Airbnb's internal agentic-coding harness, built by its Dev AI team. Airchat is a wrapper over Claude Code with a unified gateway for cost and metrics, an internal plugin marketplace, AirDev Workspaces for parallel sessions, and more than a dozen internal MCP servers that connect agents to internal systems. The team abandoned an earlier from-scratch orchestrator and shipped a thin shim over Airchat instead.

About 64% of pull requests materialized through agentic coding

About 64% of pull requests materialized through agentic coding

Wrapper over Claude Code with a unified gateway, an internal plugin marketplace, and AirDev parallel workspaces

Claude Code (a vendor agent), wrapped by Airbnb

More than a dozen internal MCP servers connect agents to internal systems

Level 3 for coding task → reviewed pull request; human attention boundary: work-product-review.

Atlassian's internal coding agent, built on the HULA (Human-in-the-loop software development agents) framework. Rovo Dev works inside Jira and runs a four-step cycle (set context, generate a plan, generate code, and raise a pull request). Atlassian dogfooded it across all Jira sites for more than a year across 1,900+ repositories. It reached general availability in October 2025.

Dogfooded across 1,900+ repositories with a 50,000+ comment internal dataset

Dogfooded across 1,900+ repositories over more than a year

Trained on a proprietary internal dogfooding dataset of 50,000+ Rovo Dev comments

Built on the HULA framework, which runs set context, generate plan, generate code, and raise PR

jira

Level 3 for Jira issue → reviewed pull request; human attention boundary: work-product-review.

A multi-agent orchestration layer built on goose + MCP that coordinates agents across Block's entire codebase, invoked in Slack to take a ticket end-to-end to a reviewed PR.

~1,500 PRs merged per week (~15% of all production code changes at Block)

200,000+ operations per day

~1,500 pull requests merged per week (~15% of all production code changes at Block)

unknown

Multi-agent orchestration built on goose (open-source agent framework) + MCP; multi-player, real-time, operating inside Slack threads

goose framework; model not specified

slack, linear, jira, github

MCP connects agents to internal tools and data; picks up Linear/Jira tickets, creates the branch, writes code, opens the PR, watches CI

Company-wide code context across hundreds of millions of lines and hundreds of services; Block also frames Builderbot as an 'agentic protector' around its software world model

Coordinates multiple agents over one codebase instead of running a single loop

Linear/Jira ticket -> branch -> code -> PR -> CI watch, end to end

"What used to take months now takes days"

Concentrate investment on orchestration, context, and the environment; let engineers focus on the problems worth solving

Meet people in Slack: tag @builderbot with a short description and it works in the thread

Multi-player real-time collaboration lets humans steer research, planning, and implementation rather than only reviewing after the fact

Level 3 for ticket → reviewed pull request; human attention boundary: work-product-review.

Retool-based internal platform where employees build, test, and deploy agents for KYC, disputes, QA, collections, and operations.

Dispute processing time fell from three hours to three seconds

50%+ of customer-support cases resolved by chatbot as first touch

Dispute processing: 3 hours → 3 seconds

QA covers every support interaction; one person using AI instead of five QA specialists

KYC adverse-media accuracy 85% → 88%

Retool-hosted runtime (no bespoke execution env described)

Retool-based builder with prompt management and multi-model testing/evaluation; built by a ~25-person systems-engineering team

Multi-model

slack, internal-ui

An MCP server exposes external product features to the internal platform; new product tools become internally available immediately; invoked via Slack /c1

Standard operating procedures uploaded as a knowledge base, such as 100-page dispute guides; customer account data

SSO via internal Retool proxies (no per-user accounts); ConductorOne access management; Okta auth; data classified by risk; ≤30-day retention, no training on inputs

Non-technical ops staff design prompts, test across models, deploy with QA oversight

Product features exposed to internal agents through one MCP server

Target 40% automation, not 100%; the last mile drives investments that often yield zero value

Brex reports that it manages the internal platform with practices used for an external product

Don't skip the human in the middle; end-to-end automation fails on accuracy

Map workflows to the discrete steps a human would take, then translate each to LLM instructions

Architecture beats vendor; legal/data approvals should follow data-handling characteristics, not the tool name

Level 2 for internal operations request → completed operation; human attention boundary: continuous-steering.

One generalized agent in Slack that writes PRs, investigates sessions, queries the warehouse, logs feature requests, and runs browser agents across engineering, ops, sales, and support.

Feature-request pipeline at 100% coverage with zero human effort

Feature-request pipeline at 100% coverage, zero human effort

99% of first-response times < 24 hrs

Session investigation: 30–60 min of log-diving → one Slack message

Ephemeral Linux VM; pre-warmed snapshot rebuilt every 30 min; idles out after 30 min

OpenCode core loop with 6 tools (read/write/edit/exec/safebash/skill)

Frontier models

slack, web, webhook

exec routes through a serverless integration proxy (Snowflake, HubSpot, Pylon, Grafana); the sandbox never sees real secrets

Key repos cloned into /knowledge/; skills (markdown) loaded on demand

Credential brokering; the sandbox boots with references + rotating session tokens only; the proxy holds real creds; egress injection for a few hosts

Markdown playbooks lazy-loaded per task so the general agent stays small

Scoped permissions per session limit the actions available to the agent

The sandbox runs arbitrary code yet never touches a secret

One agent with good abstractions beats a fleet of narrow bots

Separate capabilities from the core loop; domain logic lives in skills + service packages

Don't trust the model, remove its ability to do wrong: scope tools and services per invocation source

Meet people where they are; Slack is the highest-leverage surface because that's where work already happens

Level 3 for coding request → reviewed pull request; human attention boundary: work-product-review.

An internal platform of MCP servers, an access layer, and AI tooling (incl. an AI code reviewer) that makes agents useful inside Cloudflare.

47.95 million AI requests in 30 days across the internal AI engineering system

3,683 internal users (60% of company, 93% of R&D)

47.95M AI requests and 241.37B tokens via AI Gateway in the preceding 30 days

10,952 merge requests in the week of March 23, 2026, nearly double the Q4 baseline; four-week average above 8,700

295 teams using agentic AI tools

Dynamic Workers for sandboxed code execution; Sandbox SDK to clone/build/test

OpenCode + Windsurf clients; Agents SDK (McpAgent + Durable Objects) for stateful sessions

Workers AI (open-weight, on-platform) + frontier models (Opus, GPT), routed by task

cli, ci, web

MCP Server Portal; one OAuth point aggregating 182+ tools from 13 servers; AI Gateway for routing, cost, BYOK, ZDR

Backstage catalog (2,055 services) + AGENTS.md generated across ~3,900 repos

Zero API keys on client machines; a Worker injects keys server-side; Cloudflare Access (Zero Trust) auth

Code Mode collapses upstream tool schemas into search + execute, holding token overhead constant at scale

One OAuth aggregation point for all MCP tools

Collapse N tool schemas into 2 calls to hold token overhead constant at scale

Structured, generated repo context (runtime, nav, conventions, boundaries, deps)

Multi-agent CI review: risk tiering, specialist agents, Codex-rule citations

Centralize through a proxy early; direct-to-gateway looks simpler but blocks per-user attribution, model cataloging, and policy later

Without structured data, agents are working blind; they read code but can't see the system around it (Backstage / AGENTS.md)

Tool schemas eat context (34 GitLab tools ≈ 7.5% of a 200K window); collapse them at the portal

Frontier + open-source hybrid: route a growing share of workloads to cheaper self-hosted models

Level 3 for pull request → AI review findings; human attention boundary: work-product-review.

Forge turns a Slack/GitHub/Linear discussion into a Linear issue, fix, PR, and one-off build; Mux lets employees run many coding agents concurrently.

Mux: 600+ users including engineers, PMs, and designers (335 active, 197 power users)

Mux: 600+ users including engineers, PMs, and designers (335 active, 197 power users)

Mux gives each concurrent agent its own git worktree, branch, and terminal

Portfolio approach; Claude Code, OpenCode, Cursor, and Copilot rather than one harness; Forge is a custom harness invokable from Slack, GitHub, and Linear

Portfolio across multiple providers

slack, github, linear

Linear treated as the structured product context / source of truth

Linear as the durable structured-context layer for product work

Custom harness: Slack bug discussion → Linear issue → fix → PR → one-off build

Concurrency layer; one human coordinates many isolated coding agents, each in its own worktree/branch/terminal

Support a portfolio of harnesses (Claude Code, OpenCode, Cursor, Copilot) rather than standardizing on one

Keep the system of record (Linear) as the agent's structured context; conversation can be the input, Linear stays durable

Simple per-agent worktree/branch/terminal isolation is a pragmatic alternative to full sandboxing for concurrent coding

Level 3 for Slack, GitHub, or Linear request → reviewed pull request and build; human attention boundary: work-product-review.

Databricks' internal engineering agents and the coSTAR framework that ships and tests them. Databricks uses internal agents as daily coding drivers on its own codebase, including code-review and on-call support work. coSTAR tests agents on a private benchmark built from Databricks' multi-million line codebase before they ship. Omnigent is a separate shipping open-source product and is excluded from this record.

coSTAR framework for shipping and testing internal agents

Private benchmark built from the Databricks multi-million line codebase

Internal agents serve as daily coding drivers on the Databricks codebase

Private benchmark built from a multi-million line codebase

Unclassified for internal engineering workflows → agent-produced changes; human attention boundary: unknown.

A general-purpose 'AI colleague' spanning sales, finance, client ops, engineering, and recruitment, later split into a reusable toolkit plus Slack and desktop surfaces.

~35 integrations organized into skills

~35 integrations organized into skills

Claude/Anthropic SDK wrapper; a reusable tool/skill/memory layer separated from the Slack and desktop interfaces

Claude (Anthropic SDK)

slack, desktop

~35 integrations organized into skills; specialist delegates per domain

Four memory layers: conversation context, persistent facts, knowledge RAG, and live system state

Customer-impacting actions gated behind team-visible Slack approvals

Four-layer memory separation; prompt size dropped substantially after splitting capabilities from the Slack layer

Transient conversation, persistent facts, knowledge RAG, and live system state; kept separate

Capabilities separated from the interface layer so they power multiple surfaces

Separate reusable capabilities (tools/skills/memory) from the interface layer; prompt size drops while capability is preserved

Model memory explicitly: conversation context, persistent facts, RAG, and live state have different lifecycles

Gate customer-impacting actions behind human approvals rather than trusting the model

Level 3 for employee request → approved customer-impacting action; human attention boundary: work-product-review.

A specialized agent that automatically reviews 10,000+ PRs a week across 56 repositories, emphasizing grounded high-confidence findings over noisy comments.

10,000+ pull requests reviewed per week across 56 repositories

10,000+ PRs reviewed in a typical week across 56 repositories

60.2% action rate on settled high/critical findings (measured sample)

Three architecture versions; emphasis on attention and grounded, high-confidence findings rather than commenting everywhere

Not specified

github

Reviews Go, iOS, Android, web, infrastructure, and data code

Grounded findings tied to evidence

High-confidence, evidence-backed comments rather than blanket commentary

Optimize for attention; minimize noisy comments; comment only with grounded, high-confidence findings

Measure whether engineers actually act on findings (action rate), not comment volume

Level 3 for pull request → AI review comments; human attention boundary: work-product-review.

DoorDash's internal agentic AI platform; a unified cognitive layer over company data and operations, with an AI Marketplace of specialized agents and the Flux cloud-agent runtime for engineering tasks.

130,000 engineering tasks automated in one month

130,000 engineering tasks automated in one month

25,000+ automated code reviews per week

300+ playbooks; 10,000+ invocations per week

Firecracker microVMs; <5s p95 end-to-end setup (boot, clone repos, install tools, configure harness)

Maturity model: deterministic workflows -> ReAct agents -> hierarchical deep agents -> experimental swarms

Model-agnostic platform primitives support third-party or in-house agent components

slack, github, scheduled, cli, skill, cursor

In-house MCP gateway ('Agent Gateway'); LangGraph orchestration; prospective A2A; tools declared per playbook with scoped, logged permissions

AI Marketplace of specialized agents; DataExplorer for grounded analytics; DoorDash-specific context in playbooks

Scoped per playbook; brokered through the gateway, never on the laptop; provenance on every action

Hybrid retrieval: BM25 + dense semantic + reciprocal-rank fusion -> RAG; schema-aware SQL with EXPLAIN validation

Isolated Firecracker microVM with repos, tools, secrets, runtime deps

Governed, audited access to CI, observability, issue trackers, deploy, code search

YAML unit of agentic work: task, inputs, skills, tools, permissions, validation, outputs

Identifies schemas, generates grounded SQL, validates via EXPLAIN before execution

Workflows -> agents -> deep-agent hierarchies -> swarms; governance hardens as control decentralizes

Start narrow to earn trust; began with automated code review before CI triage, on-call, maintenance, ticket-driven dev

Make the work visible; public Slack threads drove adoption; private per-run channels did not build team habits

Playbooks need enablement; workshops and hackathons turn repeated operational work into reusable playbooks

Earn complexity by exhausting simpler primitives first; keep swarms at the research frontier until governance catches up

Deterministic verification before probabilistic judgment; SQL linting and EXPLAIN before deeper validation; LLM-as-judge + DeepEval

Log provenance so any answer traces back to source queries, documents, and inter-agent activity

Level 3 for engineering task → reviewed agent output; human attention boundary: work-product-review.

An internal platform for coding agents: engineers launch parallel sessions and internal systems invoke agents inside automated SDLC workflows.

Dozens of agents can run in parallel from one runbook

Flaky-test remediation (Deflaker): 100+ validation runs

Predecessor Goose-based migrator used across thousands of migration entries before workflows moved onto Nova

Dozens of agents launchable from one runbook

Isolated env with a codebase snapshot at a specific commit; full Dropbox monorepo via Bazel; hermetic remote execution + caching

Validation loop (propose → validate → feed back) with continue_on_validation_failure and max_iterations (~5); branch management kept outside the agent

Platform-agnostic; multiple coding agents behind one interface; swap models without rebuilding infra; prompt-eval tooling

web, cli, api, slack

Skills/plugins to gather evidence, read logs, inspect failures; MCP integrations; Bazel-aware selectivity tools

Localized AGENTS.md per service; Dash (Dropbox context engineering); passing + failing test logs

Operates within Dropbox's existing infra and validation paths; same auth/authz as engineers

Session history (notes/logs) carried across retry attempts

Bounded iteration with feedback on failure; deterministic systems control test execution

Dropbox context-engineering system feeding agents across the SDLC

Platform value exceeds code generation; validation, guardrails, and context matter as much

Context, validation, and guardrails reinforce each other to make background work trustworthy

Not every step belongs in the agent loop; deterministic systems should control test execution and timing

Integrate with existing engineering infrastructure rather than building separate AI-specific workflows

Unclassified for agent-assisted SDLC workflow → accepted change; human attention boundary: unknown.

A Slack agent for HSA/FSA payment operations that traces a payment end-to-end and, when it finds a software bug, prepares a PR with a proposed fix.

unknown

Investigation-to-fix loop; underlying runtime not documented

Not specified

slack

Traces a payment end-to-end across payment systems; can open a PR with a proposed fix when a bug is found

Payment trace → root-cause hypothesis → proposed code fix as a PR

Start where correctness is observable; payment investigation produces artifacts (a trace, a hypothesis, a diff) that can be checked

An ops agent that can prepare a fix (not just a report) closes the loop from investigation to code

Level 3 for payment investigation → proposed code fix; human attention boundary: work-product-review.

GitHub's internal data-analytics agent, powered by GitHub Copilot. Any GitHub employee can ask a question about the company data warehouse in plain language and get an answer within seconds.

Hundreds of users run thousands of queries; data questions in internal Slack channels dropped

Hundreds of users run thousands of queries

Powered by GitHub Copilot

Queries GitHub's data warehouse

Volume of data questions in internal data and analytics Slack channels dropped

Unclassified for data question → warehouse answer; human attention boundary: unknown.

Harvey's internal collaborative cloud agent platform; reacts to incidents, bug reports, and Slack messages and produces reviewable diffs, branches, and PRs.

Isolated ephemeral execution environments; durable runs

Collaborative cloud agent platform with explicit boundaries around GitHub, Datadog, Linear, and other connected systems

Not specified

slack, web, automation

Explicit tool boundaries; reacts to incidents, bug reports, customer feedback, and Slack messages

Explicit tool boundaries; outputs are reviewable

Durable runs over disposable execution environments

Long-lived run state over throwaway compute

Outputs are summaries, diffs, branches, PRs; not silent actions

Make outputs reviewable (diffs, branches, PRs) rather than letting the agent act silently

Implementation speed shifts the bottleneck toward review, prioritization, and coordination

Harvey keeps its product-agent and security-agent platforms on separate substrates because they have different trust boundaries

Level 3 for incident or request → reviewable diff or pull request; human attention boundary: work-product-review.

HubSpot's internal AI code-review agent. Sidekick reviews every pull request and uses a multi-model Judge Agent to filter comments before posting. Its review implementation moved from Claude Code on Crucible Kubernetes workloads to Aviator, HubSpot's internal Java agent framework; the later report does not specify Aviator's execution isolation.

Reviews every pull request and cut engineer feedback time by 90%

Reviews every pull request

Engineer feedback time cut by 90%

Over 80% thumbs-up reaction rate on review feedback during the preceding couple of months

Aviator, an internal Java agent framework; replaced the earlier Claude Code review implementation on Crucible

unknown

Aviator framework for precise tool control

github

Level 3 for pull request → AI review comments; human attention boundary: work-product-review.

A native agent that synthesizes workspace context, triages, creates follow-up work, runs coding sessions, and executes scheduled/event-driven 'Loops'; used by Linear's own CX, Product, and Engineering teams.

unknown

Separate planning agent (triage/issue creation) and coding agent (code generation); Code Intelligence for codebase knowledge; scheduled/event-driven 'Loops'

Codex was used for internal pull-request review; other model choices are not detailed in the preserved sources

slack, intercom, linear, github

Triage Intelligence (auto-route, dedup, label); GitHub; testing Code Intelligence + custom MCP servers

Semantic/vector search evolved into agentic context acquisition across the workspace; Datadog/Sentry customer context

The Agent SDK gives agents explicit identities, scoped OAuth tokens, assignable/mentionable handles, and visible human delegation; issues stay assigned to a human; 'an agent cannot be held accountable'

Auto-routes issues, flags duplicates, suggests labels

Agents get identities, scoped team access, and visible delegation alongside humans

Scheduled or event-driven agent runs that execute recurring work

Keep the agent close to the source of work (Intercom, Slack, Linear); the best workflows live where work already happens

Gradual autonomy; start by asking for suggestions, observe, add guidance, only automate once proven reliable

Break work into small steps to keep coding agents focused and successful

One Linear engineer reports that agent mistakes reveal possible failure modes during review

Close the loop; auto-notify the customer when their request ships

Level 3 for assigned coding work → agent-created change; human attention boundary: work-product-review.

Microsoft's internal AI code-review agent, built by the Developer Division Data and AI team. When an engineer creates a pull request, PRAssistant joins as a reviewer and leaves comments like a human reviewer. It is a distinct internal build that predates and later informed GitHub Copilot Pull Request Reviews.

Supports more than 90% of Microsoft PRs, impacting over 600,000 pull requests per month

More than 90% of pull requests across the company

More than 600,000 pull requests impacted per month

About 5,000 repositories in early onboarding

github

Level 3 for pull request → AI review comments; human attention boundary: work-product-review.

An internal agent system on Amazon Bedrock where agents have identities, managers, scopes, and performance scores; Atlas ships features, Morphex ships PRs autonomously.

Morphex: 19 of 20 PRs merge without human review

Morphex: 19 of 20 PRs merge automatically without human review

90% of Builders use AI coding tools monthly; adoption nearly doubled year over year

Per-engineer PR throughput increased by more than 50%

Guardrails catches ~25% of agent PRs before human review; low single-digit revert rate

Amazon EKS, one pod per active session; a remote sandbox tests each PR before review; EFS workspace mount

Claude Agent SDK behind a thin monday-agent-sdk wrapper (provider neutrality, cold-start optimization, custom harness opinions)

Amazon Bedrock; Application Inference Profiles for routing; cross-region failover; PrivateLink (traffic stays in VPC)

slack, monday, github

Triggers via Slack @mention, monday item assignment, or GitHub PR review → SNS → per-team SQS → consumers; monday MCP servers underpin the Guardrails

File-based memory: MEMORY.md (cross-session) + diary/YYYY-MM-DD.md; sessions/repos/secrets on EFS; durable records on S3

Per-session secrets in AWS Secrets Manager; same RBAC as humans; real Slack/GitHub/monday accounts

Live state in ElastiCache (sub-ms); monday boards (Builders CoWORK) as shared state for tasks, status, handoffs

Stable identity + assigned human manager + scope + performance score

Automated review against monday standards (metrics, feature flags, security)

MEMORY.md + daily diary instead of vector retrieval

monday boards as the shared-state layer for human/agent collaboration

Evals from day one; should have been day one, not month nine

Skip the vector store; file-based memory (MEMORY.md) was the right answer

Remote-sandbox every PR before human review, with production-traffic replay

The existing auth/identity/deploy pipeline applies to agents; reuse it

AI engineering is building the feedback loops that let imperfect agents be trusted safely

Level 4 for Atlas or Morphex feature task → tested and merged pull request; human attention boundary: outcome-review.

Notion's Custom Agents platform, dogfooded internally across non-engineering teams such as IT ticketing, supply chain, procurement, and recruiting. By the end of alpha testing, Notion had more than 3,000 internal Custom Agents. Notion's own security team is one of the most active internal users. Notion rebuilt the agent harness three to five times as frontier models improved.

More than 3,000 internal Custom Agents by end of alpha testing

More than 3,000 internal Custom Agents by end of alpha testing

Agent harness rebuilt three to five times as models improved

Notion's security team is one of the most active internal users

Unclassified for cross-team internal tasks → Custom Agents output; human attention boundary: unknown.

Plaid's internal labeling agent for its own model training. AI Annotator automates large-scale labeling of anonymized transaction data, with human oversight on the labeled output. Plaid reports greater than 95% human alignment at a lower cost and time than manual labeling.

Greater than 95% human alignment at lower cost and time than manual labeling

Greater than 95% human alignment with labeled data

Lower cost and time than manual labeling

Anonymized Plaid transaction data

Level 3 for raw transactions → labeled training data; human attention boundary: work-product-review.

Plaid's internal agent for bank-integration reliability. Fix My Connection proactively detects bank-integration failures and generates repair scripts automatically. Plaid reports more than 2 million successful user-permissioned logins and a 90% reduction in the average time to fix a degradation.

More than 2 million successful logins and 90% faster average repair

More than 2 million successful user-permissioned logins

Average time to fix a degradation reduced by 90%

Plaid bank-integration infrastructure

Level 4 for integration degradation → repaired connection; human attention boundary: outcome-review.

Plaid's central internal Model Context Protocol server. Plaid built it because third-party MCP servers could not reach its internal data. The server integrates more than 20 tools and several internal services such as Jira, application logs, and data schemas, behind Plaid's identity-aware proxy and centralized authorization. Plaid reports thousands of tool calls and dozens of agents built on the server. Separately, Claude Code and Cursor are used by more than 80% of Plaid engineers; server adoption is not quantified.

Dozens of agents rely on the internal MCP server; Claude Code and Cursor are used by over 80% of engineers

Claude Code and Cursor are used by over 80% of Plaid engineers; the source does not report internal MCP server adoption share

Thousands of tool calls and dozens of agents built on it

Central internal MCP server that fronts vendor AI clients

More than 20 tools and several internal services (Jira, logs, schemas)

Behind Plaid's identity-aware proxy and centralized authorization

Unclassified for engineer request → internal tool access; human attention boundary: unknown.

A GitHub-label-triggered PR approval agent that applies fail-closed deterministic safety gates, asks an LLM to check for showstoppers, autonomously approves eligible changes, and refuses or escalates the rest.

Handled 1,600 PRs in the previous month, as reported on July 9, 2026; roughly one in three merged main-repository PRs received its final approval during the reported quarter

1,600 PRs handled autonomously in the previous month, as reported on July 9, 2026

Roughly one in three PRs merged into PostHog's main repository received StampHog's final approval during the reported quarter

20% of PRs approved by StampHog in the July 28, 2026 report, at approximately $300 per month in tokens

A GitHub Action invokes a Python pipeline that fetches and classifies a PR, applies hard gates, waits for in-flight reviewer bots, runs an LLM review, and posts a verdict

Claude through the Claude Agent SDK, with Read, Grep, and Glob tools

github, ci

Reads the diff and repository files plus trusted review-state, discussion, ownership, and reviewer signals

Repository-specific deny categories, size and risk tiers calibrated from prior human approvals, review guidance, and ownership data

A dedicated Anthropic organization secret and a StampHog GitHub App token whose approvals satisfy branch protection

Each run emits a versioned JSON evidence bundle retained as a CI artifact for 30 days; a sticky GitHub comment carries non-approval verdict history and labels preserve retry state

Draft state, conflicts, requested changes, sensitive paths, size ceilings, and risk tiers can block AI approval; the LLM may tighten but never loosen a gate

Eligible changes can be approved while risky, ambiguous, or insufficiently assured changes are refused or escalated to a suitable human reviewer

Each run records PR metadata, classification, gate results, reviewer output, and the final verdict

Use deterministic controls for known risks and allow the LLM to make approval stricter, never more permissive

Calibrate thresholds and deny categories from repository history rather than treating small diffs as inherently safe

Fail closed and preserve retry state when dependencies, credentials, or concurrent reviewer bots are unavailable

Level 5 for eligible pull request → approval decision; human attention boundary: exception-only.

A background coding agent that closes the loop on verifying its own work; runs tests, reviews telemetry, queries feature flags, visually verifies the frontend; now also monitoring production and proposing fixes; also a platform that hosts many internal agents.

75% of Ramp's merged PRs raised by Inspect sessions (May 2026)

Around 60% of Ramp PRs authored by Inspect by January 2026

75% of merged PRs raised by Inspect sessions (May 2026)

Around 30% of merged frontend and backend PRs in the earlier first-party report, after a couple of months of adoption