263 Ultimate TypeScript Real-World AI Projects

263 blueprint-grade workflows, agents, and multi-agent systems — TypeScript-first. The Project catalog is documentation you can build from; only selected paths also have runnable reference code under reference-implementations/.

Most AI repos stop at call an API and hope it works. Plenty of content teaches SDK calls; far less shows how to ship systems that hold up in production. This repo goes further: real system design — not chatbot demos.

If you are trying to level up:

• Prompts → systems
• Demos → production

How This Repository Is Organized

This repository has two layers:

• Blueprint catalog — 263 AI system blueprints under projects/, each with README.md and architecture.md.
• Production reference layer — reusable TypeScript packages under packages/, runnable code under reference-implementations/, the benchmarks/ harness, and CI quality gates (.github/workflows/production-reference-ci.yml).

Most projects are blueprints only (documentation you implement in your own codebase). Selected catalog ideas become runnable reference implementations that share @repo/* packages and tests — not a promise that all 263 rows ship as code in this repo.

flowchart TD
    A[README Project Catalog] --> B[Blueprint Projects]
    A --> C[Learning Docs]
    A --> D[Top Projects]

    B --> B1[projects/domain/project/README.md]
    B --> B2[projects/domain/project/architecture.md]

    C --> C1[Learning Path]
    C --> C2[Production Patterns]
    C --> C3[Contribution Guides]

    D --> E[Reference Implementations]
    E --> E1[AI Cost Monitoring Engine]
    E --> E2[Future: Multi-Agent Incident Response]
    E --> E3[Future: Enterprise RAG Platform]

    E --> F[Shared Packages]
    F --> F1["@repo/core"]
    F --> F2["@repo/governance"]
    F --> F3["@repo/evals"]

    E --> G[Benchmarks]
    G --> G1[Methodology]
    G --> G2[Benchmark Suites]
    G --> G3[Local Results]

    E --> H[CI / Quality Gates]

Production Reference Architecture Layer

This repository remains catalog-first. The Project catalog (263 blueprint rows) is the main learning resource: every entry points at projects/<domain>/<slug>/ with README.md (problem, stack, evaluation, failure modes) and architecture.md (diagrams and engineering depth). Nothing here replaces that contract with a second registry.

Alongside the catalog, an additive production reference architecture layer helps you go from “what to build” to “how it can look in TypeScript” without pretending every blueprint is shipping code:

• Selected runnable references — a small, growing set of clone-and-run slices under reference-implementations/ that mirror specific catalog paths. They demonstrate ingestion, rollups, governance hooks, and similar patterns you can adapt; they are not a completeness matrix for all 263 ideas.
• Shared packages — reusable libraries under packages/ (@repo/core, @repo/governance, @repo/evals) for runtime and governance primitives. These are building blocks and documentation-backed patterns — not compliance certifications (see each package README).
• Benchmarks — a transparent harness in benchmarks/ with explicit methodology (benchmarks/methodology.md): local timings, environment metadata, and no implied SLAs or competitive “wins” without controlled reproduction.

Roadmap and boundaries: docs/PRODUCTION_REFERENCE_ARCHITECTURE_PLAN.md.

First flagship (runnable): reference-implementations/ai-cost-monitoring-engine — companion to the blueprint projects/devtools/ai-cost-monitoring-engine.

Blueprint Catalog

263 project ideas, each with README.md + architecture.md under projects/. The catalog tables below are the authoritative registry.

Reference Implementations

Selected runnable systems that exercise shared packages and show production-shaped wiring (observability seams, governance integration, honest limitations). They link back to catalog paths for context; they do not renumber or replace catalog rows.

Shared Packages

Reusable TypeScript modules (@repo/core, @repo/governance, @repo/evals) shared by reference apps and future flagships — narrow APIs, strict typing, tests where code exists. Prefer extending these over copy-pasting patterns into every new implementation.

CI and local checks (production layer)

GitHub Actions: .github/workflows/production-reference-ci.yml runs on push and pull_request to main: install pnpm, install dependencies, pnpm run typecheck, pnpm test, and a benchmark smoke (@repo/benchmarks cost-monitoring suite with mock-only data — no API keys, no external LLM calls).

Run tests locally (repository root):

pnpm install
pnpm run typecheck
pnpm test

Run benchmarks locally

• Shared harness (benchmarks/) — cost monitoring suite (writes timestamped artifacts under benchmarks/results/ unless gitignored):

cd benchmarks
pnpm suite:cost-monitoring
# optional: faster smoke
BENCHMARK_ITERATIONS=5 COST_MONITORING_EVENT_SCALE=20 pnpm suite:cost-monitoring

• Reference-local micro-benchmark (optional, in-package):

cd reference-implementations/ai-cost-monitoring-engine
pnpm benchmark

Interpret timings using benchmarks/methodology.md (local reference only).

Why this repo exists

After building and reviewing real AI products, one wall kept showing up: “We have prompts… now what?” Teams stall at prompt + API call while the product still needs:

• Orchestration — durable pipelines, handoffs, and control flow
• Decision-making — agents that choose under constraints, not just generate text
• Memory — what to retain, retrieve, and forget
• Failure handling — retries, fallbacks, guardrails, human-in-the-loop
• Cost vs latency tradeoffs — explicit budgets, not accidental bills

This collection bridges that gap with practical blueprints you can actually build: problems, architecture, TypeScript-friendly stacks, evaluation, failure modes, and scaling — systems thinking applied to AI.

What is inside

Summary counts match the Project catalog below. Each catalog entry is a blueprint: problem, architecture, TypeScript-oriented stack, evaluation, failure modes, and scaling — not a vague idea list.

How to explore (important)

This repo is catalog-driven (one registry in the README project catalog).

1. Start with the registry — the Project catalog lists every project once, with system type, complexity (L1–L5), capabilities, and path.
2. Browse by domain — open projects/ and pick a domain folder (for example projects/devtools/, projects/healthcare/, projects/fintech/, projects/enterprise-ai/, projects/security/, projects/travel/, and many more). Each project slug folder contains README.md and architecture.md.
3. Slice by system type or level — use the tables in the project catalog (columns System Type and Complexity). There are no separate by-system-type/ or by-complexity/ trees; the catalog is the filter.

Authoring rules for new catalog entries are described in CONTRIBUTING.md.

What you will learn

• System design for AI — when a durable workflow is enough, when an agent fits, when multiple agents collaborate, and how to structure decision loops safely.
• Production thinking — cost, latency, observability, guardrails, human-in-the-loop, and regression-style evaluation.
• Real tradeoffs — accuracy vs cost, autonomy vs control, reasoning depth vs time-to-answer.

Example projects (high signal)