Understanding the map
What makes an agent internal?
How organizations turn general-purpose models into agents for their own work.
A model alone doesn’t know a company’s codebase, follow its processes, or have access to its tools. Organizations supply that context and access, and shape how the agent carries out work.
Internal Agents Map documents these systems: what they do, how teams build or adapt them, and what public evidence tells us about their use.
01 / The scope of the map
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, prepare a code change, 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 includes these agents alongside the platforms and supporting systems that enable them.
02 / From a model to a workflow
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.
03 / Different approaches
How agents fit the organization
Two questions help explain the different approaches in the map:
How broad is the work?
Focused agents follow one defined workflow. Broader agents support many kinds of work or provide a shared platform.
How specific is it to the organization?
Standard products arrive with common capabilities. Internal systems add company knowledge, tools, conventions, and processes.
Company-specific · focusedSpecialized internal agents
Company-specific · broadGeneral internal agents & shared platforms
Standard · focusedReady-made task agents
- RetoolRetoolGPT
- Deep research agentResearch workflow
- Codex / Claude Code / DevinSoftware engineering agents
Standard · broadGeneral-purpose assistants
- 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
- Brex · Internal Agent Platform
A Retool-based platform for multiple operations workflows, with company procedures, account data, and product tools. Described in a First Round case study.
- DoorDash · AI Code Review Agent
One code-review workflow, grounded in repository evidence and domain rules.
- 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.
- Retool · RetoolGPT
One internal question-and-answer workflow built on ChatGPT, adapted with Retool’s Confluence documents, product documentation, and Linear tickets. Placed above the default product reference because it uses company knowledge.
- Sentry · Junior
A general internal agent that takes varied tasks across company systems, with persistent context and tools discovered through MCP.
- Shopify · Aquifer / River
A shared platform that powers coding, research, migration, and application-security agents using Shopify’s monorepo context and internal tools.
- 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 / Devin
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.
04 / Other terms you’ll encounter
Different questions about the same system
These terms answer different questions about a system. They can 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.
05 / Common questions
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. Hosting, data handling, and access controls need to be described separately.
Is a shared agent platform itself an agent?
A platform can provide the context, tools, execution environments, and controls used by multiple agents. The map includes platforms because they help explain how organizations make agents available across teams.
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. Concrete descriptions of the work, context, tools, and behavior are more useful than a label alone.