The frameworks, libraries, and protocols that underpin AI development. These are the software foundations your applications are built with.

Adopt

Mature, well-supported technologies ready for production use.

PyTorch

PyTorch is the default for most machine learning teams, especially for deep learning. Its Python-first design and dynamic computational graphs make models straightforward to write, debug and step through, which is why it took hold in research first, before production. The ecosystem around it runs deep: clear documentation, a large catalogue of pre-trained models and an active community that keeps the common paths well worn, so teams of any size can get moving quickly.

Earlier doubts about production readiness have largely gone. Deployment tooling such as TorchServe, close integration with the rest of the ML stack and a steady, stable release cadence make it dependable at scale, and it’s what most major technology firms and research groups now build on. TensorFlow still has its place, particularly in established production systems, but for new machine learning work we recommend PyTorch as the default.

dbt

dbt (data build tool) brings software engineering practice, version control and testing, to the data transformations that feed AI systems. That discipline is worth having because a model is only as reliable as the data behind it, and dbt keeps the transformation layer transparent and easy to trust.

In practice, teams use it to build clean, well-documented pipelines from the warehouse through to AI applications, and to adapt them quickly as requirements change. It works with the data platforms most shops already run and has a strong community behind it, which makes it a sound default when you’re building out AI infrastructure.

MCP

The Model Context Protocol (MCP) standardises how language models connect to external tools and data, replacing the custom, per-connection integration work teams would otherwise write by hand. Servers are straightforward to create, and a growing ecosystem of community-built ones cuts the effort further. MCP is now a vendor-neutral project governed by the Agentic AI Foundation under the Linux Foundation, the same body that stewards AGENTS.md.

Uptake has been fast. Some large organisations are aiming to make every internal API AI-accessible through MCP.

Security needs to be a first-class concern. Every MCP server must enforce authentication and authorisation independently of the calling model, with tool grants following the principle of least privilege. Audit logging of all tool calls is essential for traceability. MCP servers returning untrusted data can become an indirect prompt injection vector, so outputs from external sources need careful sanitisation before being fed back into model context.

A broader architectural concern surfaced in April 2026 when OX Security demonstrated that MCP’s STDIO transport executes arbitrary commands without validation, leading to multiple CVEs across downstream projects. Their proof of concept also showed malicious entries accepted by most MCP registries. Treat MCP servers sourced from public marketplaces with the same caution as any third-party dependency: review the code, pin versions and run servers with minimal permissions.

For simpler workflows that operate on local files and code rather than external services, Claude Skills offer a lighter-weight alternative worth considering before committing to MCP server development.

We tend to think of MCP as headless plumbing, a way to hand an agent the tools and data it needs with no human in the loop. The surprise this quarter is MCP Apps, an official extension that lets a server render a visual interface, a form or a live dashboard, directly in the host. It is early but not a toy: Claude, VS Code and Microsoft 365 Copilot already support it, and companies such as Postman, Shopify and Hugging Face are building on it. Server-supplied UI opens a fresh attack surface, so treat it as promising rather than proven.

See also: Claude Skills, Agentic tool use.

Trial

Promising technologies with growing adoption, worth exploring for specific use cases.

Microsoft Agent Framework

Microsoft Agent Framework (MAF) launched in October 2025, merging AutoGen’s agent abstractions with Semantic Kernel’s enterprise features into a single open-source platform. MAF supports Python and .NET, offering graph-based workflows for multi-agent orchestration alongside session-based state management and telemetry.

The framework is still reaching stability, which keeps it in Trial, but it consolidates Microsoft’s previously fragmented agent story, and teams building multi-agent systems on Microsoft’s stack should evaluate it as their primary framework.

As with any agent framework granting tool access, apply least-privilege scoping and build in prompt injection awareness from the start.

See also: Agentic tool use, MCP, A2A, Vendor agent SDKs.

Vendor agent SDKs

The frontier labs now ship their own SDKs for building agents directly against their models: Anthropic’s Claude Agent SDK, OpenAI’s Agents SDK and Google’s Agent Development Kit. Each hands you the agent loop, tool calling, sessions and context management as a library you drive from your own code, so you write less orchestration yourself.

The Claude Agent SDK runs the harness that powers Claude Code as a library, with its built-in tools, subagents, hooks and permissions. OpenAI’s Agents SDK is the production-ready successor to Swarm, code-first by design: your server owns the tools, state and approval decisions while the SDK runs the loop. Google’s ADK is the most enterprise-oriented, model-agnostic through LiteLLM though tuned for Gemini, with Vertex AI’s Agent Engine as its managed runtime.

There’s the standard trade-off against agnostic frameworks such as LangGraph and Microsoft Agent Framework: a vendor SDK tracks its model’s newest capabilities closely, at the cost of coupling you tightly to one provider. Use a first-party SDK when you’re committed to a model and want its full capability surface, and an agnostic framework when portability is the priority.

All of these run tool-calling agents that act on files, shells, APIs and MCP connectors, so take prompt injection seriously: content returned by a tool can steer the agent into actions you didn’t intend. Scope tool permissions tightly, keep a human approval step for anything that changes state, sandbox execution and treat everything a tool returns as untrusted input.

A2A

Google’s Agent2Agent (A2A) protocol standardises communication between AI agents. Launched in April 2025 and now governed by the Linux Foundation, it lets agents from different providers discover each other’s capabilities and collaborate without custom integration.

It complements MCP rather than competing with it: MCP connects models to tools and data sources, A2A handles agent-to-agent communication. The design centres on “Agent Cards” that advertise capabilities in JSON, so agents can delegate tasks to one another dynamically, over text or video streaming.

A2A’s complexity is justified when agents must collaborate across runtime boundaries, whether different vendors, stacks or organisations. Inside a single runtime, simpler options usually suffice: an orchestrating agent calling tools directly through MCP, a workflow engine such as Temporal or an AI-powered workflow automation platform coordinating LLM steps deterministically, or a multi-agent framework such as LangGraph or Microsoft Agent Framework handling orchestration in-process. Reach for A2A when none of these fit your topology.

LLM testing frameworks

DeepEval evaluates LLM outputs against built-in metrics for relevance, factual accuracy, hallucination detection and toxicity. It integrates with pytest, so teams already running Python test suites can adopt it without new tooling.

Promptfoo takes a CLI-first approach with strong CI/CD integration. Where DeepEval is a Python library you embed in your test suite, Promptfoo runs as a standalone tool comparing outputs across models and prompt variants. OpenAI acquired Promptfoo in March 2026, though it remains open-source under the MIT licence. Teams running multi-model strategies should consider whether the acquisition affects their comfort with Promptfoo as a neutral evaluation tool.

Consider DeepEval if you want evaluation inside an existing Python test suite, and Promptfoo if you want standalone prompt regression testing, particularly where CI/CD pipelines gate deployments on the results.

LlamaIndex

LlamaIndex, formerly GPT Index, started as a framework for indexing data so that LLMs could retrieve it efficiently. It has matured considerably since then, with production deployments across Fortune 500 organisations and a Workflows 1.0 release that adds a lightweight agentic orchestration layer alongside the retrieval core.

We keep it in Trial because LlamaIndex’s strongest case is narrower than its scope suggests: retrieval-heavy systems that benefit from its 100+ data connectors and fine-grained indexing controls. For RAG over large corpora or enterprise knowledge bases, it is the framework we would recommend looking at first. For general LLM orchestration though, LangChain & LangGraph or Microsoft Agent Framework tend to be a better fit.

LangChain & LangGraph

LangChain handles general-purpose LLM interactions while its companion LangGraph extends this to stateful, graph-based agent workflows.

Both reached 1.0 in late 2025, with a commitment to no breaking changes before 2.0. That settles the abstraction churn that made earlier versions awkward to build on. LangGraph’s graph model is worth the overhead when you need durable, resumable state across long-running or multi-agent workflows. It stays in Trial because simpler agents rarely need it: if no state has to persist across a crash or a pause, a provider SDK and a plain tool loop is less to maintain. Try it where your control flow and state are complex enough to justify the framework.

Formal specification languages

Formal specification languages describe system behaviour precisely enough that properties can be verified before code is written. They sit on a spectrum from lightweight languages that structure intent, through model checkers that explore state spaces, to theorem provers that deliver mathematical proof. TLA+ is the most widely adopted for distributed systems; Amazon used it to find subtle AWS bugs that testing could not surface. Alloy takes a lighter, auto-analysed approach, while Dafny and Lean 4 have drawn substantial AI-assisted proof-synthesis work this year. AI assistants have lowered the barrier enough to make specification viable well beyond the safety-critical systems that once justified it.

We develop Allium, our own language at the practical end: it captures behaviour in a structured, machine-readable form that AI agents use to guide implementation and generate tests. It cannot prove properties across all states the way TLA+ or Alloy can, but it captures intent precisely enough to serve as a contract between human and agent.

AI has shifted the economics of rigour. Agents have rendered formal specification much less costly and much more necessary, given how readily models resolve ambiguity in directions you did not intend.

Assess

Emerging or specialised technologies that merit evaluation for specific use cases.

JAX

JAX combines NumPy’s familiar API with hardware acceleration and automatic differentiation, and interest in it is growing. TensorFlow and PyTorch remain dominant, but JAX is gaining traction in research settings and among teams working on custom ML architectures.

Its functional approach to ML computation and its ability to compile to multiple hardware targets through XLA (Accelerated Linear Algebra) distinguish it from more established frameworks. It suits projects that need high-performance numerical computing, though teams should weigh its relative immaturity in deployment tooling and a smaller ecosystem of pre-built components. We recommend experimenting with JAX on research projects or contained proofs-of-concept before considering broader adoption.

Smolagents

Smolagents is Hugging Face’s minimalist agent framework. The core fits inside a thousand lines of code. Its distinguishing feature is the code agent pattern: rather than calling tools through structured tool-call protocols, agents write Python snippets that run against the tool catalogue. This typically reduces LLM calls per task by around a third and produces more transparent reasoning traces.

The natural concern is that letting an agent run arbitrary Python is a security risk. Smolagents addresses this through sandboxed execution backends, including Blaxel, E2B, Modal and Docker, which the framework expects to be enabled outside local development. For teams unwilling to execute model-written code at all, smolagents also offers a ToolCallingAgent mode that emits standard JSON tool calls rather than Python, trading some of the code agent’s efficiency for a smaller attack surface.

We keep it in Assess because adoption outside Hugging Face’s own examples is still limited. For teams in the Hugging Face stack who want a lighter alternative to LangGraph or Microsoft Agent Framework, it is well worth a look.

CrewAI

CrewAI orchestrates teams of specialised agents that collaborate through defined roles and task delegation. It supports human-in-the-loop integration and ships a dedicated production architecture, CrewAI Flows, and it has found wide adoption for agent collaboration, including in enterprises.

Best practices for multi-agent design are still emerging, and managing several agents adds operational overhead that a single orchestrating agent often avoids. Worth evaluating where the work benefits from multiple specialised agents rather than one capable one.

DSPy

DSPy treats prompts as optimisable programs rather than handcrafted text. You define signatures (input-output specifications) and modules (composable building blocks), and DSPy’s optimisers automatically generate effective prompts based on example data. The optimisation process can discover strategies that humans might not have considered.

The framework shows particular promise for complex pipelines involving multiple LLM calls or retrieval steps. DSPy remains in Assess because it introduces a programming paradigm unfamiliar to most teams, and the investment pays off only for systems that benefit from automated prompt optimisation. For simpler single-prompt applications, traditional approaches may remain more practical.

LinkML

LinkML allows teams to define data models in YAML and generates multiple outputs: JSON Schema for validation, Python dataclasses for code, RDF/OWL for semantic web compatibility and documentation. This makes it valuable for phased ontology development where teams want to start practically but preserve the option for formalisation later.

The framework emerged from biomedical informatics but applies broadly. For AI applications, LinkML models can define entities and relationships for knowledge graphs and structured output schemas for LLMs. It remains in Assess because adoption is relatively niche. Organisations already committed to JSON Schema may find less incremental value, but for teams starting fresh on knowledge representation, LinkML offers a middle path between ad-hoc schemas and full OWL modelling.

PydanticAI

PydanticAI brings the developer experience of FastAPI to generative AI application development. It is built by the team behind Pydantic, the validation layer that underpins the OpenAI, Anthropic and Google ADK SDKs alongside LangChain, LlamaIndex and others. It offers model-agnostic LLM support, structured responses through Pydantic validation and a dependency injection system for testing.

PydanticAI reached v1 in September 2025 and has since added durable execution, streaming structured outputs and graph-based control flow. It uses existing Python patterns rather than introducing new paradigms, which makes it immediately approachable for teams already familiar with the ecosystem. Production deployments are appearing, and for Python-first stacks it is a strong default to evaluate.

Prolog

Prolog has regained relevance for neurosymbolic AI architectures. This decades-old logic programming language gives you guaranteed logical inference with explainable reasoning chains, which LLMs can’t reliably supply: they handle ambiguous language well but can’t follow complex rules or explain why they reached a conclusion. By coupling an LLM with a Prolog reasoning engine, teams can build systems where the model handles the input and Prolog enforces business logic, validates conclusions or traverses knowledge graphs. Implementations typically use Prolog to represent domain rules that validate LLM outputs before they reach users. This pattern suits regulated industries where decisions must be auditable.

We keep Prolog in Assess because the tooling for LLM integration remains immature and performance can suffer at scale. Teams should also consider whether semantic web technologies (RDF, OWL, SPARQL) might serve similar purposes with better tooling support.

Hold

Not recommended for new projects; better alternatives exist.

AutoGen

AutoGen is now in maintenance mode, receiving bug fixes only. In October 2025 Microsoft merged AutoGen and Semantic Kernel into the Microsoft Agent Framework (MAF), which consolidates both projects’ capabilities into a single platform. Semantic Kernel is likewise in maintenance mode. Teams currently using either framework should plan their migration to MAF; new projects should start there directly.

TensorFlow

TensorFlow remains a capable deep learning framework and helped popularise machine learning at scale, but its large API surface, fragmented deployment story and intricate architecture make it harder going than more modern alternatives, especially for newcomers.

PyTorch is now the community favourite for research and production, with a more intuitive model and better debugging. For new projects we recommend PyTorch or higher-level tools unless you have a reason to stay on TensorFlow, such as existing deployments or TensorFlow Extended (TFX) for ML pipelines.

Keras

Keras has moved from a standalone deep learning framework to tighter integration with TensorFlow.

Keras was an intuitive entry point into deep learning, with an API that made neural networks more accessible, but the ecosystem has moved on. PyTorch has gained momentum, with clearer debugging, better documentation and a more Pythonic approach. Lightning and FastAI offer similar ease of use while staying closer to current practice. For new projects, we recommend these alternatives rather than investing in Keras-specific expertise.

R

R has a long history in data science and statistical computing, but we place it in Hold for new projects. It remains capable for statistical analysis and visualisation, though its adoption is declining in favour of Python’s broader ML and AI ecosystem.

The industry now prefers Python-based ML frameworks, and Python integrates more tightly with modern AI platforms. R retains some advantages for specific statistical applications and academic research, but teams starting new AI initiatives will benefit from standardising on Python and the AI libraries that reach it first.

OpenCL

OpenCL (Open Computing Language) was an early standard for parallel programming across different types of processors, but for new projects teams should look to alternatives.

Its promise was write-once-run-anywhere code for GPUs, CPUs and other accelerators, yet industry support has declined. Major hardware vendors have shifted focus to more specialised frameworks such as CUDA for NVIDIA hardware, while newer alternatives such as SYCL offer better developer experiences with similar cross-platform benefits. A complex programming model, inconsistent tooling and a fragmented ecosystem make OpenCL hard to justify for new development against more actively maintained alternatives.

Languages & Frameworks