GitHub - steel-experiments/internal-agents-map: A map and learning exchange for companies building proprietary internal AI agents — catalog, patterns, and adoption lessons.

Definition

Internal agents are AI systems organizations build or adapt to do work for their own teams.

They operate through the organization's knowledge, tools, workflows, and controls. Some work alongside a person. Others start from an event and run in the background. Human supervision varies by workflow.

Organizations publish these systems under many names. Internal Agents Map groups their implementations under one definition so their designs and operating boundaries can be compared.

The map also covers platforms, orchestration systems, and implemented supporting patterns. These support internal agents but are not agents themselves.

Claims link to public sources. Company reports stay separate from catalog interpretation, and undocumented details stay unknown.

Browse the catalog · Architecture patterns · Adoption observations · Use the data · Contribute

Current map: 39 approaches across 35 organizations, backed by 88 sources and 558 evidence-linked claims.

Overview

Reading the levels: Adapted from Dan Shapiro's framework, L2 means continuous steering, L3 work-product review, L4 outcome review, and L5 exception-only supervision. Levels describe a specific workflow, not company maturity. Methodology →

What the current map shows

Human review is still the norm. 23 of the 39 approaches produce a draft or implementation for review. 8 keep a person involved throughout the work. 3 report autonomous action within a scoped workflow; 2 are assistive and 3 remain unknown.

Different systems keep solving similar infrastructure problems: company context, scoped tools, execution environments, verification, and integration with systems of record.

Some internal agents are durable: their identity or state persists across runs and restarts. Others start fresh. Durability is a design choice, not an inclusion requirement. State duration is undocumented for 34 approaches. Review cost, failure rates, and retired systems are rarely reported.

What belongs in the map

An entry needs a named organization, an agent or enabling approach built or materially adapted for that organization's own work, and public evidence describing its implementation or use.

The map includes agents, agent systems, platforms, orchestration systems, and implemented supporting patterns. These are separate approach types. Prototypes and systems that later became open source or commercial products can qualify.

Generic vendor products without a documented internal adaptation are not entries. General opinion pieces and unattributed claims may appear as context, not as catalog approaches.

Evidence standard

Every authored claim points to one or more structured sources. Each source records its relationship to the organization. Reported statements stay separate from catalog judgments, and company metrics remain self-reported unless independently verified.

Accepted sources are preserved while they are live. The publisher URL remains the citation; verified snapshots provide an audit trail if it is later removed.

unknown means undocumented, not absent. Conflicting evidence remains visible. See the data schema for the complete methodology.

Contributing

Found a missing approach or better evidence for one already here? Start with the record template and follow the contribution guide.

License

Code and tooling are licensed under MIT. Content and data are licensed under CC BY-SA 4.0. Preserved third-party source material under archive/ retains its original ownership and is not relicensed under those terms.