Framework Providers

AgentVisor™ supports multiple agent frameworks — LangGraph, CrewAI, Google ADK, and Strands Agents — through a pluggable framework provider system. This page covers what's common across every framework: how AgentVisor picks a provider, how it discovers an agent's schema, and the shape of the local test loop used to try an agent before deploying it behind a sandbox.

See the framework-specific guide for discovery file format, framework config, checkpointing/state behavior, and runnable examples:

• LangGraph Agents
• CrewAI Agents
• Google ADK Agents
• Strands Agents

Provider Selection

AgentVisor selects a framework provider by checking, in order: an explicit framework.provider in mav-agent-config.yaml, then langgraph.json, then agent.yaml, then crewai.yaml, then — only in agentvisor exec mode, and only if none of those discovery files exist — the interactive provider.

framework: section	langgraph.json	agent.yaml	crewai.yaml	agentvisor exec mode	Result
Absent	Yes	Any	Any	Any	langgraph provider (implicit)
Absent	No	Yes	Any	Any	adk provider (implicit)
Absent	No	No	Yes	Any	crewai provider (implicit)
Absent	No	No	No	Yes	interactive provider (implicit)
Absent	No	No	No	No	Error: no provider found
Present, provider: set	Any	Any	Any	Any	Named provider (explicit, always wins)
Present, provider: absent	Any	Any	Any	Any	Validation error: provider is required

A project should generally only ship one of langgraph.json, agent.yaml, or crewai.yaml to avoid relying on this ordering — set framework.provider explicitly if you need more than one present at once (e.g. during a migration).

Strands has no discovery file of its own, so it never appears in the auto-detection columns above — it's only ever reached through the "Present, provider: set" row, with framework.provider: "strands". See Strands Agents: Why mav-agent-config.yaml Is Required.

Schema Discovery

AgentVisor discovers each agent's input/output schema using the same three-tier fallback for every framework:

1. Build-time cache (.agentvisor/schema.json) — used if it's newer than the framework's discovery file (LangGraph's langgraph.json, CrewAI's crewai.yaml, ADK's agent.yaml — or, for Strands, agent.py itself, since Strands has no discovery file)
2. Dynamic extraction (python3 -m agentvisor.schema_cli) — imports your agent/crew/graph module and extracts the full schema, including input/output types and description
3. Fallback — names only, read directly from the discovery file, with no full input/output schema. Strands has no discovery file to fall back to, so it has no third tier: schema either comes from tier 2 or is unavailable.

What triggers tier 2 is framework-specific:

Framework	Trigger
LangGraph	Any graph registered in langgraph.json
CrewAI	Any crew registered in crewai.yaml; input schema is derived from {placeholder} tokens in task descriptions
Google ADK	Calling register_agent() on your root agent
Strands	Calling register_agent() on your root agent

Local Test Loop

Before deploying behind a sandbox, every framework follows the same basic loop to test an agent locally:

1. Start Temporal — temporal server start-dev, or docker compose up -d if your scaffolded project ships a compose.yml with Temporal already configured
2. Set up a Python environment — only needed for --sandbox=none; see Local Development Setup for installing the SDK from the release wheel. A sandbox mode (docker/gvisor) already has everything installed in the guest image
3. Export credentials your agent's model provider needs, as environment variables
4. Serve the agent — agentvisor serve . --sandbox=none for fast local iteration without container overhead, or agentvisor serve ./my-agent to run behind a sandbox
5. Create a thread and start a run:

THREAD=$(curl -sX POST http://localhost:8090/threads | jq -r '.thread_id')

curl -sX POST "http://localhost:8090/threads/$THREAD/runs?wait=120s" \
    -H "Content-Type: application/json" \
    -d '{"input": {...}}' | jq

Each framework guide's own Testing Locally section shows this with the exact credentials and input shape for that framework.

SDK Dependency in requirements.txt

Every framework shares the same rule for requirements.txt in sandboxed modes (docker/gvisor): don't add a bare agentvisor — it's pre-installed in the guest image, and reinstalling it risks a version mismatch against the guest runtime's gRPC contract. See Local Development Setup: requirements.txt and the SDK for the full rule, including how to add an optional extra like agentvisor[tracing].