Agent Framework Selection

Selection guide for agent frameworks by runtime style, model-provider fit, tool interface, memory/state, deployment, and governance needs.

Full series Previous: Workflow Automation Tools Inventory Next: AI Ecosystem Stack Patterns

Introduction

Agent Framework Selection is a synthesis article, which means it connects multiple wiki pages into a practical decision guide. Selection guide for agent frameworks by runtime style, model-provider fit, tool interface, memory/state, deployment, and governance needs. Instead of acting as another inventory or glossary entry, this page introduces the question a team is trying to answer, the constraints that shape the answer, and the proof needed before the recommendation should be trusted.

The introduction highlights agent, tool, state, framework, selection, orchestration because those terms usually define the trade-off space: architecture fit, operational complexity, governance, observability, cost, and validation effort. A reader should use this page after reading the relevant concepts, entities, and inventories. The value is not just in naming options, but in showing how to choose among them, what risks to inspect, and what experiment would confirm the best path for a real LLM Wiki or AI platform environment.

Agent framework selection should start from the control model: who owns the loop, tools, state, guardrails, evaluation, and deployment surface. A simple code-first SDK and a managed cloud agent service solve different problems. ^[inferred]

Selection Matrix

Need	Strong Shortlist	Why
Lightweight OpenAI-centered agent app	OpenAI Agents SDK	Small primitive set, built-in tool calling, handoffs, sessions, tracing, and MCP support.
Multi-provider custom agent app	LangChain Agents, PydanticAI, Semantic Kernel	Better fit when provider portability or app-defined orchestration matters.
Typed Python agent workflows	PydanticAI, OpenAI Agents SDK	Strong fit for schema validation and Python-native tools.
Agent plus RAG plus graph orchestration	LangChain Agents with LangGraph, LlamaIndex workflows	Better fit for stateful orchestration and retrieval-heavy systems.
Microsoft enterprise stack	Semantic Kernel, Azure AI Foundry Agent Service	Fits Microsoft identity, cloud, and enterprise integration assumptions.
AWS-native managed agent	AWS Bedrock Agents	Managed service fit for AWS/Bedrock-centered architectures.
Strict tool governance	MCP plus guardrails/observability stack	Tool access needs security boundaries beyond framework ergonomics.

Decision Criteria

Criterion	What To Check
Runtime ownership	Does the framework own the loop, or does the application own it?
Tool model	Are tools plain functions, schemas, plugins, action groups, MCP servers, or hosted tools?
State and memory	Is state built in, app-defined, or delegated to an orchestration layer?
Handoffs	Can agents delegate safely, or does orchestration require custom graph/state logic?
Observability	Are traces, tool calls, evals, and errors visible enough for debugging?
Security	Can tool access be scoped, audited, denied, and tested?
Deployment	Is the target local app, container service, managed cloud agent, or enterprise platform?

Guardrail

Do not pick an agent framework just because it can call tools. The hard parts are permission design, failure recovery, observability, evals, state control, and human approval for risky actions. ^[inferred]

Default Recommendation

For a Python app centered on OpenAI APIs, start with OpenAI Agents SDK. For multi-provider or highly custom orchestration, compare LangChain/LangGraph, PydanticAI, and Semantic Kernel. For cloud-native managed workflows, evaluate Bedrock Agents or Azure AI Foundry Agent Service only if their operational constraints fit the project. ^[inferred]

Agent Risk Matrix

Risk	Why It Matters	Mitigation
Tool overreach	Agents can call powerful APIs with weak intent validation	scope tools, require approvals, log every call
Unbounded loops	Agent loops can burn cost and create unpredictable latency	set step/time/token budgets and explicit stop conditions
State confusion	Memory or session state can make behavior non-reproducible	define state schema and reset rules
Prompt injection	Retrieved or external content can steer tool behavior	separate instructions from data and add tool-call validation
Poor observability	Agent failure is hard to diagnose without trajectories	trace model calls, tools, handoffs, and final decisions
Provider lock-in	Framework primitives can bind the app to one model ecosystem	isolate provider-specific code and test portability

Selection Workflow

1. Decide whether the agent is a simple tool-using assistant, a multi-agent workflow, or a managed enterprise agent.
2. Define the tool permission model before picking the framework.
3. Pick the smallest framework that can express the needed state, handoff, and deployment model.
4. Add tracing/evals before expanding tool access.
5. Run a failure drill: bad tool output, unavailable API, prompt injection attempt, and partial task completion. ^[inferred]

Proof Of Fit

Test	Expected Evidence
Tool scope test	Agent cannot call tools outside its role or permission boundary
Handoff test	Delegation is visible in traces and has clear ownership
State reset test	Agent behavior is reproducible when session/memory is cleared
Failure recovery test	Agent handles tool failure without unsafe retries
Human approval test	Risky write/actions pause for approval or policy gate

Enrichment Status

• Status: enriched
• Added: risk matrix, selection workflow, and proof-of-fit tests.
• Still needs human review before lifecycle can move from draft to reviewed.

Sources

• Agent Development Tools Inventory
• MCP Tools Inventory
• Agent Development Frameworks
• OpenAI Agents SDK
• LangChain Agents

Practical Implementation Context

For the Agent Framework Selection synthesis page, practical implementation means using an agent framework scorecard to make a decision path testable. The page should connect concepts, inventories, references, and entities into a clear argument about which framework should host the agent workflow, then name the evidence needed before the recommendation is trusted.

• Evaluate the decision through tool adapters, agent loop, and test harness.
• Compare the evidence signals: SDK fit, observability hook, and deployment pattern.
• Use the validation path: prototype tool call, run evaluation, then record trade-off.
• Keep the recommendation current by checking whether one representative agent task runs with tracing and failure handling still holds.

Implementation note: this agent framework scorecard should keep the decision about which framework should host the agent workflow tied to a validation path where reviewers prototype tool call, run evaluation, and record trade-off.

Reference Implementation Pattern

For the Agent Framework Selection synthesis page, the reference pattern is an agent framework scorecard. It should not merely summarize tools; it should explain which framework should host the agent workflow, what trade-offs matter, and what proof would validate the choice.

decision_record:
  topic: "Agent Framework Selection"
  artifact: "agent framework scorecard"
  decision: "which framework should host the agent workflow"
  inputs:
    - "tool adapters"
    - "agent loop"
    - "test harness"
  evaluation:
    - "SDK fit"
    - "observability hook"
    - "deployment pattern"
  proof_of_fit: "one representative agent task runs with tracing and failure handling"
  next_action: "record trade-off"

For example, after updating the related concept and inventory pages, a team can ask $wiki-synthesize to compare the options and then use this page as the durable place for the trade-off, the recommended next experiment, and the evidence needed before adoption.

Key Takeaways

• Treat the source page as distilled knowledge, then add enough implementation context for a standalone reader.
• Make trade-offs visible: reliability, observability, governance, cost, and maintenance burden all matter.
• Use structured headings, tables, examples, and explicit warnings to help readers scan and apply the material.

Operational Depth

Decision Ownership

Agent Framework Selection synthesis page should operate as an agent framework scorecard. It owns the decision path for which framework should host the agent workflow, so it should be reviewed whenever constraints, tools, or architecture assumptions change.

Validation Signals

Operational review should inspect tool adapters, agent loop, and test harness, then compare that evidence with SDK fit, observability hook, and deployment pattern.

Validation Run

The synthesis is still trustworthy when reviewers can prototype tool call, run evaluation, and record trade-off. The proof point is that one representative agent task runs with tracing and failure handling.

Review Cadence

Review this page whenever source material changes, linked pages are promoted, or a reader would make a different decision because of new information. The review should check content accuracy, link integrity, and whether the operational proof still matches the current LLM Wiki graph.

Reader Outcome

A reader should leave with a decision path and a concrete validation step.

Frequently Asked Questions

What decision does Agent Framework Selection help with?

It helps readers connect related concepts, entity profiles, and inventory candidates into a practical decision path with clear trade-offs.

How should the recommendation be validated?

Define a proof-of-fit scenario, test the riskiest assumption, and record the result back into the wiki so the synthesis remains grounded.

What makes this different from an inventory page?

An inventory lists candidates. A synthesis page explains how to choose among them under constraints such as agent, tool, state.

Conclusion

Agent Framework Selection should end as a decision aid. The article connects concepts, inventories, and entity profiles so readers can understand which option fits a real constraint set rather than simply collecting tool names. Its conclusion should point back to the decision that needs to be made and the proof needed to trust that decision.

The next step is to turn the trade-offs around agent, tool, state, framework into a small validation plan: choose the likely path, define what success looks like, test the risky assumption, and feed the result back into the wiki. That loop is what makes a synthesis page operational instead of merely descriptive.

Full series Previous: Workflow Automation Tools Inventory Next: AI Ecosystem Stack Patterns