Orchestration & Protocols

These packages give you a complete TypeScript implementation of the Agent-to-Agent (A2A) protocol — server framework, client SDK, CLI scaffolding, and a bidirectional A2A ↔ MCP bridge — so you can build AI agents that discover each other, exchange messages, and manage task lifecycles. You would adopt them to avoid writing protocol boilerplate and to get production-ready infrastructure for authentication (OAuth2, JWT, API key, mTLS), persistence (in-memory, filesystem, Redis, PostgreSQL), push notifications, rate limiting, and OpenTelemetry observability out of the box. The most distinctive thing is that every package shares canonical Zod schemas from the core package, so types, validation, and error handling are consistent across server, client, auth, persistence, and the MCP bridge — and you can swap server adapters (Express 5 or Hono) and task stores without changing your agent logic.

These packages give you a complete lifecycle for transferring a conversation from one AI agent to another mid-session, including compressing the conversation history, scoring and selecting the best target agent, validating payload compatibility, delivering the handoff via MCP or A2A transport, and handling rejection with fallback alternatives. You would adopt them to solve the problem of routing a live multi-turn conversation between specialized agents without losing context or requiring the user to repeat themselves. The most distinctive thing is that every stage—compression, routing, validation, transport, and rejection handling—is a separate, pluggable package with zero runtime dependencies, so you can compose only the pieces you need and inject your own implementations for any stage.

These packages give you a complete multi-agent orchestrator that routes user requests to the right agent based on intent confidence, manages multi-turn sessions, and isolates failing agents with circuit breakers. You would adopt them to build a production system where multiple specialized AI agents handle different tasks (like password resets, HR queries, or IT support) behind a single API endpoint, with automatic fallback and clarification when the intent is unclear. The most distinctive thing is how the packages compose around a confidence-gated decision tree—Gemini Flash classifies intent, a 5-rule engine decides whether to route, clarify, or fall back, and per-agent circuit breakers with Firestore persistence prevent cascading failures across Cloud Run instances.

This repository is a reference catalog of architectural patterns for building AI agent systems, covering coordination, reliability, state management, quality, security, performance, and observability. You would adopt it to avoid designing and debugging these patterns from scratch when constructing production agent workflows. Each pattern is documented with a consistent structure—problem, forces, solution diagram, runnable TypeScript implementation, failure modes, and when not to use it—making the collection a design handbook rather than a library you install.

These packages give you a decision engine that turns classifier confidence scores into one of three actions: route to a handler, ask the user for clarification, or fall back to a default. You'd adopt them to handle ambiguous or low-confidence predictions in a conversational or routing system without hard-coding every edge case. The most distinctive thing is the threshold-based triage model—you set two confidence boundaries and the engine automatically decides whether to proceed, ask, or bail, with pluggable classifiers (keyword, embedding, LLM) that chain in priority order.

These packages give you a config-driven LLM routing engine that selects models based on cost, latency, capability, or a two-tier judgment strategy, with automatic fallback chains and circuit breakers when models fail. You would adopt them to manage multi-provider LLM costs, enforce daily budgets, and add structured degradation paths without writing provider-specific orchestration code. The system is built as a set of independent packages—core types, engine, strategies, fallback, telemetry, MCP server, and CLI—that compose through a shared config schema and a single `executeModel` callback, keeping provider SDKs out of the router itself.