TL;DR

The essential AI agent repository list in 2026 is no longer just a collection of frameworks and tutorials. A credible engineering stack now includes protocol specifications, official SDKs, server discovery, agent-to-agent interoperability, durable orchestration, evaluation, OpenTelemetry-compatible tracing, red teaming, and operational security guidance.

This refresh identifies 20 repositories that help architects and engineers build the complete system. The list is grouped by role rather than ranked by popularity: MCP foundations, A2A interoperability, agent frameworks, evaluation and observability, and agent security. It was validated on July 20, 2026. That date matters because the MCP Python and TypeScript v2 lines were still prerelease at the time, with the next MCP specification scheduled for July 28, 2026.

Introduction

The first version of this article was useful because it gave readers a practical starting point for learning AI agents and Model Context Protocol integration. The ecosystem has since changed enough that simply adding five repositories would produce the wrong update.

In 2025, many repository lists were dominated by courses, examples, framework comparisons, and community-curated directories. Those resources still have value, but enterprise agent engineering in 2026 has moved toward a layered architecture. Teams must now choose how agents access tools, how independent agents communicate, how workflows resume after failure, how tool calls are traced, how behavior is evaluated, and how the entire system is attacked before it reaches production.

That changes what “essential” means.

A high-star repository can still be the wrong dependency. A smaller official SDK may be more important because it defines compatibility. A security playbook may create more production value than another orchestration framework. A registry can improve discovery while simultaneously expanding supply-chain and trust risks.

This article is therefore not a popularity ranking. It is a validated architecture-oriented shortlist for people building, reviewing, or operating AI agent systems in 2026.

Why the 2026 Repository Stack Looks Different

The agent ecosystem is separating into distinct layers. MCP standardizes how an AI application accesses tools, resources, and contextual data. A2A focuses on communication between independent agentic applications. Frameworks implement control flow, state, handoffs, memory, and human approvals. Evaluation and observability repositories provide evidence about behavior. Security repositories help teams test abuse paths and translate threats into controls.

The important change is that none of those layers replaces the others.

An agent framework does not remove the need for a protocol. MCP does not provide durable workflow orchestration. A2A does not automatically secure delegated work. Tracing does not prove that an agent is safe. A vulnerability scanner does not establish ownership, approval gates, or incident response.

A production design requires deliberate composition.

Validation Baseline for This Refresh

This list was validated on July 20, 2026 against official project repositories and current project notices. Repository activity, stewardship, current migration guidance, protocol status, and operational scope were considered.

One timing caveat is especially important. On that date, the MCP Python SDK documented v2 as a prerelease line and recommended v1.x for production. The TypeScript SDK also described v2 as beta and kept v1.x as the supported production line. Both projects were preparing for the scheduled July 28, 2026 specification release. Production teams should verify those status notices again before upgrading because the release boundary was still in the future when this article was prepared.

The Agent Stack You Are Actually Building

The diagram below shows why a useful repository shortlist must cover more than agent frameworks. Notice that MCP and A2A sit on different interaction paths, while evaluation, telemetry, identity, and security cut across the entire system.

The architecture implication is straightforward: select repositories by responsibility. Do not ask one framework to become your protocol layer, telemetry standard, evaluation harness, and security program.

How These Repositories Were Selected

The shortlist uses six practical criteria.

Authoritative role: Official specifications, SDKs, and project repositories receive priority when compatibility depends on them.

Current stewardship: The project should show active ownership, current documentation, or an explicit maintenance and migration position. A famous repository with an unclear future is not automatically a safe new dependency.

Distinct architectural value: Every repository should solve a meaningful layer of the system. The list avoids filling multiple positions with projects that provide nearly identical value.

Implementation utility: Documentation, examples, test assets, migration guidance, and integration support matter more than promotional claims.

Operational relevance: The repository should help with production concerns such as durability, telemetry, policy, evaluation, security, deployment, or interoperability.

Adoption realism: Licensing, version pinning, dependency scope, upgrade behavior, and ownership must be reviewable by an enterprise engineering team.

Stars were treated as a discovery signal, not a ranking formula. Repository popularity cannot answer whether a project matches your runtime, support model, risk profile, or target architecture.

MCP Foundations and Official SDKs

MCP repositories should be read in a specific order. Start with the specification, then understand discovery and reference servers, and only then choose the language SDK used by your client or server implementation.

modelcontextprotocol/modelcontextprotocol

Best for: Understanding the protocol contract before writing integration code.

This is the authoritative repository for the MCP specification, protocol schema, and official documentation. Architects should begin here because many implementation mistakes come from learning MCP only through a framework wrapper. The specification clarifies the boundaries between hosts, clients, servers, tools, resources, prompts, transports, capability negotiation, and lifecycle behavior.

Use this repository when creating architecture standards, compatibility requirements, security reviews, or internal MCP design guidance. It is also the right place to monitor specification evolution and proposal discussions.

Operational caveat: Do not assume a framework’s MCP feature set equals the entire current specification. Record the specification version, SDK version, and framework adapter version as separate configuration items.

modelcontextprotocol/registry

Best for: Understanding MCP server discovery, publication metadata, and registry integration.

The MCP Registry repository represents a major change from the earlier ecosystem, where discovery depended heavily on community lists and manual configuration. The registry provides a standardized service for clients to discover published MCP servers and their metadata.

For enterprise teams, the more important lesson is that discovery is not the same as trust. Registry metadata can improve inventory and onboarding, but an organization still needs publisher verification, package review, permission analysis, secret handling, sandboxing, approval workflows, and revocation.

Operational caveat: Treat public registry entries as untrusted supply-chain inputs until your internal intake process verifies the publisher, artifacts, requested permissions, network destinations, and update mechanism.

modelcontextprotocol/servers

Best for: Reference implementations, examples, and understanding common server patterns.

This repository contains MCP server implementations and links to a broader ecosystem of servers. It is useful for learning how filesystem access, source control, databases, browser automation, and other capabilities are exposed through MCP concepts.

Its value is educational and architectural. Engineers can compare tool schemas, transports, error handling, configuration patterns, and local execution models before building a custom server.

Operational caveat: A reference or example server is not automatically production-approved. Review the repository status of each server, its data access, command execution surface, authentication behavior, network egress, and whether it is maintained in the official repository or elsewhere.

modelcontextprotocol/python-sdk

Best for: Building MCP clients and servers in Python.

The official Python SDK is the starting point for Python-based MCP development. It supports client and server construction, typed tool definitions, resources, prompts, and standard transports. It is particularly relevant for internal automation, data services, AI engineering tools, and Python-heavy agent platforms.

At the July 20, 2026 validation point, the main branch documented v2 prerelease behavior and explicitly recommended the v1.x line for production. That makes version pinning more than a packaging preference. It is an architecture control that protects production from accidental major-version adoption.

Operational caveat: Pin the production dependency to the approved major line, keep upgrade testing separate, and verify whether the documentation you are reading matches the version installed in your environment.

modelcontextprotocol/typescript-sdk

Best for: Building MCP integrations for Node.js, web services, developer tools, and TypeScript platforms.

The official TypeScript SDK is the natural choice for organizations building MCP hosts, clients, and servers in the JavaScript and TypeScript ecosystem. It is especially relevant for IDE integrations, web-facing services, developer platforms, and teams already operating Node.js services.

As of the validation date, the v2 line was beta and the v1.x line remained the supported production release. Teams should therefore test package names, API changes, transport behavior, and compatibility rather than assuming a drop-in upgrade.

Operational caveat: Align Node.js runtime support, SDK major version, MCP specification version, and framework integration version in one compatibility matrix.

A2A Protocol and Interoperability

MCP connects an agentic application to tools and context. A2A connects independent agentic applications to one another. That distinction matters because a remote agent has its own identity, behavior, state, tools, policies, and failure modes. It should not be modeled as a simple local function merely because another agent can invoke it.

a2aproject/A2A

Best for: Understanding agent discovery, task exchange, collaboration, and interoperability boundaries.

This is the authoritative Agent2Agent protocol repository. It defines how opaque agentic applications can discover capabilities, exchange messages, collaborate on tasks, and operate without exposing internal memory or implementation details.

The repository is essential for architects designing cross-team or cross-platform agent systems. It helps separate the public interaction contract from the private implementation behind each agent. That separation supports organizational autonomy, language and framework diversity, and controlled delegation.

Operational caveat: Protocol compatibility does not establish authorization or business trust. Define who may discover an agent, submit work, receive artifacts, cancel tasks, and access sensitive output.

a2aproject/a2a-samples

Best for: Learning A2A through runnable examples across frameworks and use cases.

The samples repository shortens the path from specification reading to observable behavior. It includes examples that demonstrate clients, servers, agent cards, task flows, and framework integrations.

Use it to build a lab where teams can inspect request flow, streaming, task state, errors, and interoperability before they expose real business agents. It is also useful for comparing how different frameworks map their internal concepts to the A2A contract.

Operational caveat: Samples demonstrate protocol mechanics, not your production security or reliability model. Add identity, transport protection, rate limits, durable state, telemetry, and failure injection before treating a sample as a deployment pattern.

a2aproject/a2a-python

Best for: Implementing A2A clients and servers in Python.

The official Python SDK provides the practical building blocks for exposing Python agentic applications as A2A servers and calling remote A2A agents. It supports asynchronous implementation patterns and integrations for common transports, telemetry, and storage options.

This repository is valuable when an organization has independently developed Python agents that now need a consistent interoperability layer. It can also be used to wrap an existing framework-based agent without forcing every participating team onto the same orchestration framework.

Operational caveat: Pin the A2A SDK and specification compatibility level together. Migration between protocol generations can affect message models, transports, task semantics, and integration tests.

Agent Frameworks Worth Comparing

The framework layer is where teams make decisions about state, graph execution, handoffs, memory, tools, retries, human approvals, deployment, and provider integration. There is no universal winner. The correct choice depends on how much abstraction the team wants and which operational responsibilities the framework must own.

openai/openai-agents-python

Best for: Lightweight Python agent development with tools, handoffs, guardrails, sessions, and tracing.

The OpenAI Agents SDK provides a compact set of primitives for building agent workflows without requiring a large orchestration platform. It supports agents, tools, handoffs, guardrails, human-in-the-loop patterns, sessions, and tracing. It can be a strong fit for teams that want a readable code-first design and do not need to begin with a complex graph runtime.

The repository is especially useful for studying how agent responsibilities, delegation, tool access, and trace data can remain explicit in application code.

Operational caveat: Built-in primitives do not replace your enterprise control plane. Define persistence, tenant isolation, model access, secret management, retention, and approval policy outside the happy-path example.

google/adk-python

Best for: Code-first agent development with Google ecosystem integration and structured workflow capabilities.

Google’s Agent Development Kit is designed for building, evaluating, and deploying sophisticated agents with a code-first approach. It is relevant for teams using Google Cloud, Gemini models, or a broader model-agnostic architecture that still benefits from Google’s agent tooling.

The repository includes agent composition, workflow patterns, tools, evaluation, and deployment-oriented capabilities. It deserves evaluation when the target environment includes Vertex AI or when teams want to compare a vendor-backed framework with independent orchestration libraries.

Operational caveat: Major-version changes can reshape APIs and runtime assumptions. Pin the framework, test migration paths, and verify which features are stable versus experimental before standardizing it.

microsoft/agent-framework

Best for: Production-oriented Python and .NET agent systems, especially in Microsoft-centered enterprises.

Microsoft Agent Framework is the current strategic repository for organizations that previously evaluated AutoGen or Semantic Kernel for new agent projects. It supports Python and .NET, graph-based workflows, checkpointing, human-in-the-loop control, middleware, provider flexibility, and OpenTelemetry integration.

Its importance is not only feature breadth. Microsoft now directs new AutoGen users toward Agent Framework, and Semantic Kernel identifies it as the enterprise-ready successor. That makes this repository a lifecycle decision, not merely another framework option.

Operational caveat: Existing AutoGen and Semantic Kernel applications should follow documented migration guidance rather than being rewritten blindly. Inventory feature parity, custom extensions, state models, telemetry, and hosting dependencies first.

langchain-ai/langgraph

Best for: Durable, stateful, graph-based agent workflows that need explicit control.

LangGraph is a strong option when an agent workflow must pause, resume, branch, retry, preserve state, or involve human decisions. The graph model makes execution paths and state transitions more visible than a simple autonomous loop.

This repository is especially useful for systems where reliability matters more than minimal code. It can model long-running business processes, multi-agent handoffs, memory-aware flows, and recovery checkpoints while keeping the orchestration logic explicit.

Operational caveat: A graph can become difficult to operate if state schemas, node ownership, error transitions, and replay behavior are not designed early. Treat the graph as production workflow code, not prompt glue.

crewAIInc/crewAI

Best for: Role-based multi-agent collaboration combined with event-driven workflow control.

CrewAI remains a practical choice for teams that think naturally in terms of specialist agents, tasks, crews, and controlled flows. Its higher-level abstractions can make collaborative agent patterns easier to communicate and prototype, while flows provide a path toward more deterministic orchestration.

The repository is valuable for business-process automation where role separation is meaningful, such as researcher, reviewer, analyst, planner, and operator responsibilities.

Operational caveat: Role descriptions do not create security boundaries. Tool permissions, data access, memory isolation, delegation limits, and approval requirements must be enforced by runtime controls rather than prompt text alone.

pydantic/pydantic-ai

Best for: Type-safe Python agents with structured inputs, outputs, dependency injection, and validation.

Pydantic AI is compelling for engineering teams that want agent development to feel like conventional typed application development. Its emphasis on validation and structured data helps reduce ambiguity at the boundaries between models, tools, and application code.

It is particularly useful when downstream systems require dependable schemas, when tool arguments must be validated, or when agent output becomes an input to an automated business process.

Operational caveat: Type validation can reject malformed structures, but it cannot prove that a semantically valid action is authorized, safe, or factually correct. Pair schema enforcement with policy, evaluation, and human approval where consequences are material.

strands-agents/harness-sdk

Best for: Model-agnostic Python and TypeScript agent harnesses with hooks, tools, guardrails, and observability.

The Strands Agents project has evolved into a broader harness SDK repository supporting production agent construction across Python and TypeScript. It is relevant for teams that want control over the agent loop while retaining flexibility across models and cloud environments.

Its focus on hooks, lifecycle control, tools, observability, and guardrails makes it a useful comparison point against higher-level multi-agent frameworks. Built-in MCP integration also helps teams connect the harness to standardized tool servers without making MCP the orchestration engine.

Operational caveat: Model-agnostic does not mean behavior-equivalent. Evaluate tool calling, structured output, context limits, streaming, safety behavior, and failure handling for every approved model provider.

Evaluation and Observability Repositories

An agent that completes a demo is not necessarily reliable. Production teams need regression tests, adversarial cases, traces, token and latency data, tool-call evidence, and a way to connect failures back to prompts, models, policies, and code versions.

promptfoo/promptfoo

Best for: Automated evaluation, regression testing, red teaming, and CI/CD gates for prompts, agents, and RAG systems.

Promptfoo has expanded beyond prompt comparison into a practical evaluation and security testing platform. It can compare providers and configurations, execute test cases, score outputs, and run adversarial probes as part of engineering workflows.

Use it to establish release gates for agent behavior. A deployment pipeline can require passing task-specific evaluations, refusal tests, tool-use checks, data leakage tests, and cost or latency thresholds before promoting a new model, prompt, tool, or framework version.

Operational caveat: Generic benchmarks are not enough. Build test suites from your own incidents, business rules, sensitive data classes, tool permissions, and unacceptable outcomes.

Arize-ai/openinference

Best for: OpenTelemetry-compatible semantic conventions and instrumentation for AI application tracing.

OpenInference helps teams represent model calls, retrieval, tools, agents, and surrounding application context as telemetry that can flow to compatible observability backends. Its value is portability: instrumentation can be designed around open telemetry concepts rather than a single proprietary viewer.

The repository includes instrumentation for many agent frameworks and model SDKs, including MCP-related paths. It is a strong foundation when an organization wants consistent spans across heterogeneous AI applications.

Operational caveat: Trace payloads can contain prompts, outputs, retrieved data, tool arguments, and identifiers. Apply masking, sampling, access control, retention, and data residency policy before enabling broad capture.

openlit/openlit

Best for: An integrated open-source AI engineering platform with observability, evaluation, guardrails, prompt management, and infrastructure visibility.

OpenLIT combines OpenTelemetry-native tracing with a broader operational platform. It can be useful for teams that want dashboards and AI-specific engineering capabilities without assembling every component individually.

Its scope includes LLM observability, GPU monitoring, evaluations, guardrails, prompt management, and integrations across model providers, vector databases, and agent frameworks. That makes it relevant for platform teams building shared AI operations capabilities.

Operational caveat: Broad platforms create their own lifecycle and data-governance responsibilities. Review storage, tenancy, authentication, upgrade paths, telemetry volume, and which features are required versus merely available.

Agent Security and Red Teaming

Agent security cannot be reduced to prompt injection filtering. The attack surface includes tools, credentials, retrieved content, MCP servers, remote agents, memory, artifacts, network access, approval bypass, excessive autonomy, and the software supply chain.

NVIDIA/garak

Best for: Automated vulnerability scanning and adversarial probing of language models and AI applications.

Garak provides a broad set of probes for behaviors such as prompt injection, jailbreaks, data leakage, hallucination, toxicity, and other known failure classes. It is useful for security testing before deployment and for repeated regression testing when models or system prompts change.

Security teams can use it as one layer in a larger assessment process, especially to create repeatable evidence rather than relying on informal manual prompting.

Operational caveat: Scanner coverage is not assurance. Add application-specific abuse cases, tool misuse scenarios, multi-turn attacks, indirect prompt injection, identity boundary tests, and incident-response validation.

OWASP/secure-agent-playbook

Best for: Structuring agent security reviews, threat modeling, control ownership, and audit procedures.

The OWASP Secure Agent Playbook is valuable because it focuses on the work surrounding the scanner. It provides procedures for assessing agentic systems, reviewing MCP servers, analyzing prompt injection paths, modeling multi-agent threats, and connecting findings to controls and evidence.

This repository is particularly useful for architects, security reviewers, platform owners, and governance teams that need a common review method across multiple agent projects.

Operational caveat: A playbook becomes useful only when responsibilities are assigned. Map each required control to an owner, implementation mechanism, evidence artifact, exception process, and review trigger.

What Changed Since the 2025 List

The original article was oriented toward learning resources, community directories, and early agent frameworks. The 2026 refresh changes the balance for several reasons.

Official Protocol Repositories Now Matter More Than Curated Lists

Community “awesome” lists remain useful for discovery, but MCP now has an official specification repository, official SDKs, reference servers, and a registry project. Those sources should become the primary baseline for architecture and compatibility decisions.

A2A Is Now an Implementation Topic

Agent-to-agent interoperability is no longer only a conceptual future direction. The protocol repository, samples, and official Python SDK give teams a concrete path for exposing and consuming independent agents.

Microsoft’s Framework Guidance Changed

AutoGen is now in maintenance mode and directs new users to Microsoft Agent Framework. Semantic Kernel also identifies Agent Framework as its enterprise-ready successor. Existing applications still require supported migration planning, but new framework evaluations should begin with the current strategic repository.

Evaluation, Telemetry, and Security Became First-Class Layers

A repository list that stops at orchestration leaves teams without a way to prove behavior, diagnose failures, control release risk, or assess attacks. Promptfoo, OpenInference, OpenLIT, Garak, and the OWASP Secure Agent Playbook are included because production readiness depends on evidence and controls, not framework capability alone.

A Practical Shortlist by Use Case

You do not need to adopt all 20 repositories. Use the list as a map, then create a smaller approved stack for each product or platform team.

Engineering need	Start with	Add next	Primary question to resolve
Learn MCP correctly	MCP specification	Python or TypeScript SDK	Which specification and SDK versions are approved?
Publish internal MCP servers	MCP SDK	Registry patterns and reference servers	How will publishers, permissions, and updates be verified?
Connect independent agents	A2A protocol	A2A samples and language SDK	Which identities may discover and delegate to each agent?
Build a lightweight Python agent	OpenAI Agents SDK or Pydantic AI	Promptfoo and OpenInference	How much orchestration and type safety are required?
Build durable stateful workflows	LangGraph or Microsoft Agent Framework	OpenTelemetry instrumentation	How will state, replay, checkpoints, and human approval work?
Build role-based collaborative workflows	CrewAI	Promptfoo and OpenInference	Which permissions are enforced outside role prompts?
Support Python and .NET enterprise teams	Microsoft Agent Framework	OpenInference or OpenLIT	What is the migration path from existing Microsoft agent stacks?
Keep models and clouds flexible	Strands Harness SDK	MCP SDK and evaluation suite	Which provider differences must be regression tested?
Establish release gates	Promptfoo	Garak and business-specific evaluations	What failures block deployment?
Establish shared AI telemetry	OpenInference or OpenLIT	Existing OpenTelemetry backend	What sensitive data may enter traces?
Run an agent security review	OWASP Secure Agent Playbook	Garak and custom attack scenarios	Who owns remediation and evidence?

Repository Intake Policy for Enterprise Teams

A team should not add an agent repository to production merely because a developer can install it. Use a lightweight intake policy that forces version, ownership, security, and evidence decisions.

The YAML below is a policy template, not a vendor-specific executable file. Adapt the fields to your architecture review, software composition analysis, and CI/CD systems.

repository_intake:
  required:
    ownership:
      - internal_service_owner
      - security_reviewer
      - upgrade_owner
    source_review:
      - verified_publisher
      - approved_license
      - security_policy_present
      - release_or_maintenance_status_recorded
    dependency_controls:
      - exact_or_bounded_version_pin
      - software_bill_of_materials
      - vulnerability_scan
      - transitive_dependency_review
    agent_controls:
      - tool_permission_inventory
      - secret_and_identity_model
      - human_approval_boundaries
      - telemetry_and_audit_plan
      - evaluation_suite
      - rollback_procedure
  reject_when:
    - unreviewed_main_branch_dependency
    - undocumented_network_egress
    - unrestricted_tool_execution
    - missing_runtime_owner
    - no_regression_evidence

A successful intake does not mean the repository is permanently approved. It means the team has a recorded owner, pinned baseline, known permissions, measurable tests, telemetry plan, and a trigger for reassessment.

A 30-Day Learning and Validation Path

The most effective way to use this list is to build one thin vertical slice rather than running 20 disconnected tutorials.

Week One: Protocol Boundaries

Read the MCP specification and build one local server with the approved stable SDK line. Expose a low-risk read-only tool. Record the host, client, server, transport, authentication assumptions, and tool schema.

Then read the A2A specification and compare the interaction model. Document why the MCP server is a tool provider while an A2A endpoint represents an independently operated agent.

Week Two: Orchestration

Implement the same business task in two candidate frameworks. One should be lightweight and code-first; the other should support explicit durable state or graph execution. Compare implementation complexity, state handling, human approval, retry behavior, and deployment dependencies.

Do not select a framework from a hello-world example. Force at least one tool failure, one malformed result, one interrupted workflow, and one manual approval.

Week Three: Evaluation and Telemetry

Create a small regression suite with valid tasks, invalid requests, injection attempts, tool misuse cases, and expected refusal behavior. Add tracing for model calls, tool calls, handoffs, latency, token use, and errors.

Review the traces for sensitive content before connecting them to a shared backend.

Week Four: Security and Operational Readiness

Use Garak and custom scenarios to probe the system. Apply the OWASP playbook to identity, tools, MCP servers, remote agents, memory, data flows, and audit evidence.

Finish with a go or no-go review that assigns ownership for upgrades, alerts, incidents, exceptions, and rollback.

Enterprise Adoption Checklist

Before standardizing any repository from this list, confirm the following:

• The project’s role in the architecture is explicit.
• The approved version and compatibility baseline are pinned.
• The license and dependency chain have been reviewed.
• Maintainer, release, maintenance, or migration status is recorded.
• Tool permissions and network egress are documented.
• Human approval boundaries match the consequence of actions.
• Secrets use workload identity or a managed secret system rather than source code or prompt context.
• Agent, tool, MCP, and A2A interactions produce useful audit evidence.
• Evaluation suites include business rules, security cases, and prior incidents.
• Trace collection has masking, access, retention, and residency controls.
• Failure, replay, cancellation, and rollback behavior have been tested.
• One internal owner is accountable for upgrades and deprecation response.

Conclusion

The most important GitHub repositories for AI agents in 2026 are not simply the projects that make an agent demo easy. They are the repositories that define contracts, implement interoperability, control execution, generate evidence, and expose security weaknesses before those weaknesses reach production.

MCP and A2A solve different architectural problems. MCP standardizes access to tools and context; A2A standardizes collaboration between independently operated agents. Frameworks such as OpenAI Agents SDK, Google ADK, Microsoft Agent Framework, LangGraph, CrewAI, Pydantic AI, and Strands provide different control models on top of those boundaries. Evaluation and observability projects make behavior measurable. Garak and the OWASP Secure Agent Playbook help convert security from a prompt-level concern into an engineering and governance discipline.

The practical path is not to clone all 20 repositories. Select one protocol baseline, one or two candidate frameworks, one evaluation approach, one telemetry approach, and a defined security review process. Pin versions, build a thin vertical slice, test failure and abuse paths, and assign operational ownership before scaling.

This refresh should remain a living architecture index. Revalidate it when protocol releases land, when framework maintainers change direction, or when your organization’s identity, telemetry, and risk requirements change.

External References

• Model Context Protocol: Specification and Documentation for the Model Context Protocol
  Canonical URL: https://github.com/modelcontextprotocol/modelcontextprotocol
• Model Context Protocol: MCP Registry
  Canonical URL: https://github.com/modelcontextprotocol/registry
• Model Context Protocol: Model Context Protocol Servers
  Canonical URL: https://github.com/modelcontextprotocol/servers
• Model Context Protocol: MCP Python SDK
  Canonical URL: https://github.com/modelcontextprotocol/python-sdk
• Model Context Protocol: MCP TypeScript SDK
  Canonical URL: https://github.com/modelcontextprotocol/typescript-sdk
• Agent2Agent Project: Agent2Agent Protocol
  Canonical URL: https://github.com/a2aproject/A2A
• Agent2Agent Project: A2A Samples
  Canonical URL: https://github.com/a2aproject/a2a-samples
• Agent2Agent Project: A2A Python SDK
  Canonical URL: https://github.com/a2aproject/a2a-python
• OpenAI: OpenAI Agents SDK for Python
  Canonical URL: https://github.com/openai/openai-agents-python
• Google: Agent Development Kit for Python
  Canonical URL: https://github.com/google/adk-python
• Microsoft: Microsoft Agent Framework
  Canonical URL: https://github.com/microsoft/agent-framework
• LangChain: LangGraph
  Canonical URL: https://github.com/langchain-ai/langgraph
• CrewAI: CrewAI
  Canonical URL: https://github.com/crewAIInc/crewAI
• Pydantic: Pydantic AI
  Canonical URL: https://github.com/pydantic/pydantic-ai
• Strands Agents: Harness SDK
  Canonical URL: https://github.com/strands-agents/harness-sdk
• Promptfoo: Promptfoo
  Canonical URL: https://github.com/promptfoo/promptfoo
• Arize AI: OpenInference
  Canonical URL: https://github.com/Arize-ai/openinference
• OpenLIT: OpenLIT
  Canonical URL: https://github.com/openlit/openlit
• NVIDIA: Garak
  Canonical URL: https://github.com/NVIDIA/garak
• OWASP: Secure Agent Playbook
  Canonical URL: https://github.com/OWASP/secure-agent-playbook
• Microsoft: AutoGen
  Canonical URL: https://github.com/microsoft/autogen
• Microsoft: Semantic Kernel
  Canonical URL: https://github.com/microsoft/semantic-kernel

The post 20 Essential GitHub Repositories for AI Agents, MCP, A2A, and Agent Security in 2026 appeared first on Digital Thought Disruption.