What makes an agent internal?
An agent is internal when it does a company’s own work with the company’s own context and tools.
A model alone doesn’t know the codebase, follow the processes, or reach the tools. The organization supplies those, and shapes how the agent works.
This guide explains the terms the map uses. The map itself records what each system does, how the team built or adapted it, and what public evidence says about its use.
The agent comparisons below exclude shared infrastructure. Explore platforms and components separately.
What is an internal agent?
An internal agent works with company context and tools to carry out the organization’s own work.
It might investigate a failed deployment, open a pull request, or help an employee resolve an IT issue. “Internal” describes the work it serves. The organization can build the system itself or adapt an existing product.
An agent answering customers directly serves a customer-facing role. One system can support both kinds of work.
What makes it an agent?
For this guide, an agent uses a model to choose and carry out steps toward a task, using tools and feedback as it works.
Real systems often combine model-directed steps with programmed automation. A coding agent might decide how to fix a problem while a fixed pipeline runs tests and prepares the result for review.
The map separates task-performing Agents from the reusable Infrastructure that enables them. Lessons draw on both collections.
From a model to an internal workflow
Consider Stripe’s Minions. An engineer can ask a Minion to fix a flaky test. It works with Stripe’s code and development tools, makes a change, runs checks, and prepares a pull request for human review.
What makes this internal is its role in Stripe’s engineering work. Its cloud execution and unattended operation describe other aspects of the same system.
Explore Minions in the catalogHow agents fit the organization
Two questions separate the approaches in the map.
How broad is the work? (horizontal axis)
Focused agents follow one defined workflow. Broader agents perform many kinds of work. Shared platforms have a separate infrastructure index.
How company-specific is it? (vertical axis)
Standard products arrive with common capabilities. Internal systems add company knowledge, tools, conventions, and processes.
Specialized internal agents
General internal agents
Ready-made focused agents
General-purpose assistants
- CursorSupport investigation workflow
- DoorDashAI Code Review Agent
- GitHubQubot
- MetaRanking Engineer Agent (REA)
- PostHogStampHog
- RampInspect
- SalesforceSlackbot
- SentryJunior
- SierraPinecone
- SpotifyHonk
- StripeMinions
- Deep research agentResearch workflow
- Codex / Claude Code / CopilotSoftware engineering agents
- ChatGPT / ClaudeDefault setup · reference products
The markers represent named systems and their documented scope. A company may operate several systems in different regions.
Broader scope and greater adaptation are not measures of quality. A focused agent may be exactly what a workflow needs.
Why these systems are placed here
Spacing within a region is for readability.
- Cursor · Support investigation workflow
Cursor’s own product, configured for support investigations with workspaces over the product repositories and MCP servers for support systems. The team configured a standard product and did not build a new one, so it sits low, but above the default setup.
- DoorDash · AI Code Review Agent
One code-review workflow, grounded in repository evidence and domain rules.
- GitHub · Qubot
One data-analytics workflow on the GitHub Copilot cloud agent, grounded in a context layer that teams contribute to and in the company data warehouse. The arrow shows a coding agent moved upward into work that is not coding.
- Meta · Ranking Engineer Agent (REA)
One machine learning experimentation workflow for the ads ranking models, grounded in a database of past experiments and connected to Meta’s job schedulers and experiment tracking.
- PostHog · StampHog
One pull-request approval workflow, grounded in repository-specific safety gates, review state, ownership, and prior human approvals.
- Ramp · Inspect
A background coding agent that verifies work with tests, telemetry, feature flags, and the rendered frontend; it later expanded into production monitoring and a host for other internal agents.
- Salesforce · Slackbot
An employee agent that finds company context, drafts work, and joins Slack context with Salesforce data. It is also a front door to other agents.
- Sentry · Junior
A general internal agent that takes varied tasks across company systems, with persistent context and tools discovered through MCP.
- Sierra · Pinecone
A shared interface for employee work that routes each request to a model, harness, and environment, and reaches 45 company systems through an MCP gateway.
- Spotify · Honk
A background coding agent on the Claude Agent SDK, adapted with Spotify’s own harness, trusted CI tools, and component ownership from Backstage. The arrow shows a standard coding agent moved upward.
- Stripe · Minions
Several engineering tasks within a coding workflow, connected to Stripe’s development tools and repository rules. Placed toward the middle of workflow breadth.
- Reference · Deep research agent
A ready-made agent for one research workflow: finding sources, reasoning across them, and producing a documented report. OpenAI, Google, and Perplexity offer examples.
- Reference · Codex / Claude Code / Copilot
Ready-made agents that cover several software engineering workflows. Repository instructions, internal development tools, and company processes can move a deployment upward.
- Reference · ChatGPT / Claude
General-purpose assistants that span many kinds of work. Company knowledge, connected apps, and custom tools can move a deployment upward.
What the team built or adapted
An organization can adapt an existing product deeply, or build a small custom agent for a narrow task. Building software in-house does not by itself tell us how broadly the system works or how closely it fits the organization.
Each catalog entry looks at the concrete choices: context, tools, execution environment, workflow, and the parts the team built or configured.
Supervision: when does a person look?
A supervision level describes whether and when a person must take part in a named workflow. Some successful runs need no routine human review.
The levels follow Dan Shapiro’s five levels of AI-assisted software development. Levels 0 and 1 cover manual work and autocomplete, so the catalog starts at level 2.
| Boundary | Level | Human attention | Interpretation |
|---|---|---|---|
| Continuous steering | 2 | A person pairs with the agent throughout execution. | The person repeatedly guides the work as it proceeds. |
| Work-product review | 3 | A person reviews the draft or implementation. | The named workflow requires a person to inspect the work product. Publication permissions are recorded separately. |
| Outcome review | 4 | A person evaluates tests, behavior, or outcomes. | The normal review boundary is the result rather than routine implementation inspection. |
| Exception-only | 5 | A person returns when the system raises an exception. | A normal successful run does not require routine human review. |
| Unknown | — | The catalog has not established a classification. | Review states distinguish missing evidence from unfinished assessment. A question that does not fit the system is not applicable; unknown does not mean no human supervision. |
Attention is not authority. A background run can still lack permission to publish, merge, spend money, or act in production. A level also says nothing about how long the system runs unattended.
A level describes the named workflow and evidence date. It does not rank a company, maturity, autonomy, or output quality. One system can therefore have several scoped levels.
Work domains
Work domain describes the kind of work an entry supports, such as coding, code review, support, or finance operations. One entry can cover several domains. This differs from workflow breadth, which describes how narrowly or broadly the system works.
Approach types
Approach type answers what kind of system the entry describes. It is independent of how work starts.
| Type | What it means |
|---|---|
| Agent | One system that carries out tasks. |
| Agent family | Several agents that each do useful work on their own and ship as one family. |
| Platform | Shared infrastructure that several agents or workflows run on. |
| Orchestration | A system whose primary role is coordinating agents. |
| Component | One component, such as a sandbox or a context layer, that agents depend on. |
Work modes
Work modes describe how work starts or proceeds. Interactive (foreground) and background describe participation; scheduled and event-driven describe triggers. One system can support several modes, such as event-driven background work.
| Mode | What it means |
|---|---|
| Interactive | A person starts and exchanges messages with the system. This is foreground participation while those exchanges continue. |
| Background | Work continues without continuous interaction after it starts. |
| Scheduled | A time rule starts the work. |
| Event-driven | A system event starts the work. |
| Unknown | The collected evidence does not establish how work starts or proceeds. |
Four more questions about the same system
Each term answers a different question. They apply together.
Cloud and local: where does the work run?
Local and cloud describe where the agent runs.
A cloud agent executes on hosted infrastructure, independently of the user’s device.
A local agent executes on the user’s device. It may still call a model hosted in the cloud: model hosting and agent execution can happen in different places.
Stripe’s Minions run on AWS EC2 development machines, making them an example of cloud execution.
Foreground and background: how do people interact with it?
Foreground and background describe how you participate while it works.
Foreground work involves active interaction with a person: discussing the task, giving instructions, or steering the next steps.
Background work proceeds without continuous interaction. A person can start it and return later, or a schedule or event can trigger it.
These are modes of work. The same agent can move between them. An engineer might give a Minion instructions, leave it to work, then return to discuss the result.
Autonomy: what can it do without approval?
Autonomy describes the decisions and actions an agent can take without human approval.
Describe that authority concretely: “A Minion can write code and run checks on its own. Production pull requests require human review.” Working without someone’s continuous attention does not imply permission to take every action.
The catalog records the authority a source describes. When an article explains a workflow but not its permissions, the entry says so instead of guessing.
Common questions
Does “internal” mean built in-house?
No. A company can configure an existing product around its own workflows. The relevant question is what work the system serves and how it uses company context and tools.
Does “internal” mean private or self-hosted?
No. An internal agent can use hosted services. Each entry describes hosting, data handling, and access controls on their own terms.
Is a shared agent platform itself an agent?
A platform can provide the context, tools, execution environments, and controls used by multiple agents. The Infrastructure collection preserves this architecture research without counting platforms as agents. The default Agents collection covers the systems that perform identifiable work.
Is every automated workflow an agent?
For this guide, the distinction is whether a model chooses steps or actions as the task unfolds. A fixed sequence of programmed steps is automation; a system can combine both.
Why are some details unknown?
Public descriptions vary in depth. An article may explain a workflow without documenting its permissions or execution environment. The map leaves those details unknown rather than inferring them from a product name.
Are these official definitions?
These are working definitions for reading the map. Product terminology varies. A concrete description of the work, context, tools, and behavior tells you more than any label.
Send a public write-up, talk, or post about a company's internal agent, or tell us what to fix in an entry. Pull requests are welcome.