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.
