Methodology

What we include

Each case identifies an organization, the internal work its system serves, and what the team built or materially adapted. Public evidence must describe the implementation or its use.

Adaptation can mean connecting internal tools, supplying company context, or adding workflow logic or controls. Buying licenses or announcing adoption alone does not qualify. Systems can qualify without a product name or a minimum amount of custom code.

Agents perform identifiable work. The Infrastructure collection covers implemented platforms and components that support agent workflows. Prototypes and research implementations can qualify; each entry states its deployment stage. Commercial and open-source systems follow the same evidence requirements.

How we review cases

We read the sources, check for an existing record, and assess the case against our inclusion rules. We add a case, update its existing entry, record what evidence is missing, or explain why it is out of scope. New evidence can reopen a decision.

Agents help prepare changes and check claims against source passages. Maintainers publish accepted changes by merging pull requests. Automated checks catch structural errors, damaged source files, and broken links. They cannot confirm an interpretation or reported result. Agreement between reviewing agents is not independent evidence.

How we use sources

We prefer original accounts. Attributed outside reporting can also support a case. We record each publisher’s relationship to the work and link claims to sources that support, contradict, or provide context for them. Passage locators identify the evidence where available. An article repeating a company’s result is not independent verification.

We preserve source pages with Steel. Citations retain the publisher’s URL and link to the saved copy when one is available. Entries that cite the same source version at the same URL can share a capture. Its date tells you when we saved that copy. Preservation does not verify the claims it contains.

We distinguish reported facts, attributed opinions, and our own inferences. Company results remain self-reported unless separately verified. For metrics, we retain the reported scope, dates, denominator, and measurement method when available. Conflicting reports stay visible with their qualifications.

What confidence means

We assess confidence for each claim, with a reason that identifies its evidence and any unresolved step. Publisher identity alone never supplies a rating. Evidence strength describes source type and detail.

A source can clearly support “the company reports a reduction” without independently verifying the reduction. Read the attribution and qualifications alongside the rating.

When an answer is missing

Unknown means the catalog has not established a classification. A capability or human supervision may still be present. Review states explain why a question has no answer.

What In depth means

In depth identifies records with detailed primary evidence about their purpose and implementation. Every claim has a supporting source. All sources have preserved copies and have been reviewed, along with the reader questions and implementation fields. A shared capture counts for every entry that cites that source version.

A completed review can leave a question unanswered or mark it not applicable. Records can qualify with low-confidence claims or conflicting evidence. In depth describes documentation coverage. It does not certify performance or reported results.

By default, your bookmarks come first, then the entries we feature, followed by other In depth entries. Alphabetical sorting ignores these distinctions.

How we assign levels

For each named workflow, we assess whether and when human attention is required. The levels distinguish continuous participation, review of the work product, review of the outcome, and intervention only on exceptions. Each assessment cites evidence and a date.

One system can have different levels for different workflows. A single review boundary may not apply to shared infrastructure. Permissions to publish, merge, or act in production are recorded separately. The levels do not rank companies or output quality. See the supervision definitions for the terms and framework.

How we write lessons

We compare design choices across cases. Each lesson links to its sources and separates what teams report from our observations.

We state the limits of each comparison. A repeated choice does not prove that it works better. Our illustrations explain the ideas and identify simplifications.

Corrections and review dates

We apply corrections and new evidence to the existing record. We keep conflicting accounts and label historical implementations so an older design is not attributed to its replacement. You can submit a source or correction through the contribution link below.

An entry’s review date records editorial work on the catalog. A source’s verification date records its last successful check at the original URL. Rereading a saved copy does not advance that date. Capture dates record when we saved the evidence. A metric’s observation date and measurement period come from the source.

Scheduled link checks test availability. They do not establish that a described system is still operating or that its reported results remain current.

What the map cannot tell you

Many documented cases concern coding and code review. Failed projects and unpublished systems may be missing, and companies decide which details and results to disclose.

Counts describe catalog records, including agent families, and do not measure independent deployments. Several entries can share infrastructure or cite the same account. Results from different tasks or measurement methods may not be comparable.

• Data schema
• Lesson writing rules
• Contribution guide

Company logos

Logos identify organizations and remain their owners’ trademarks. They imply no endorsement, partnership, or quality judgment. If an owner requests removal, we replace the logo with a monogram and keep the entry.