8 agent harnesses: APIs, execution, licenses, hosting, and support

This directory covers eight agent harnesses and their public documentation, repositories, licenses, hosted services, and support records as checked July 30, 2026.

1. OpenAI Agents SDK

• Project and owner: OpenAI publishes the OpenAI Agents SDK as separate Python and TypeScript packages. The public Python repository is openai/openai-agents-python. The documentation describes the SDK as an upgrade of OpenAI's experimental Swarm project and identifies agents, handoffs, guardrails, sessions, and tracing as its principal components.

• Release and status: The Python SDK documentation publishes a release policy and changelog. The policy uses a modified pre-1.0 scheme in which minor version updates can contain breaking changes. Patch releases are reserved for backward-compatible fixes under that policy. The changelog records package versions and dated changes. The TypeScript package has a separate repository and release stream.

• Language, package, and API: The Python package is openai-agents; the TypeScript package is published for Node.js environments. The Python API centers on Agent, Runner, tools, handoffs, guardrails, sessions, model settings, and structured outputs. Typed Python functions become tools through signature inspection and Pydantic schema generation. The default OpenAI model path uses the Responses API. The SDK overview documents adapters for other model providers.

• Agent object: An agent is a configuration object containing a name, instructions, model, tools, handoffs, input and output guardrails, output type, hooks, and model settings. Dynamic instructions can read run context. An output type can be a Pydantic model or another type that the SDK converts to a structured-output schema. Agents do not run as resident worker processes by themselves.

• Execution model: Runner.run() is asynchronous, Runner.run_sync() provides a synchronous wrapper, and Runner.run_streamed() exposes streamed run events. A turn sends conversation items and available tools to the selected model. Tool requests are dispatched, results return as new items, and the loop calls the model again. The run ends on a final output, a handoff, an exception, or a turn limit.

• Handoffs and agents as tools: A handoff changes the active agent within the same run. The new agent receives the run history according to the configured handoff behavior and produces the eventual final output unless another transition occurs. An agent exposed as a tool runs as a bounded tool call and returns its result to the calling agent. The multi-agent documentation treats these as separate orchestration forms.

• Run context and limits: RunContextWrapper carries application context for instructions, hooks, guardrails, and tools. The context object is local application state and does not automatically enter the model prompt. max_turns limits model turns. Model token limits, application timeouts, queue limits, and external-service rate limits remain separate controls.

• Run results and streaming events: A completed run returns a result containing final output, the active agent, new conversation items, raw model responses, guardrail results, and input state for another run. Streamed runs expose raw model events, run-item events, and agent-change events. Items in a run include message, tool-call, tool-output, handoff, and reasoning-related records according to the selected model and transport.

• Model and tool settings: ModelSettings carries temperature, top-p, penalties, truncation, tool choice, parallel-tool-call settings, and provider-specific fields where the model adapter supports them. Tool behavior can include error functions, enabled predicates, output transformation, timeouts supplied by application code, and approval configuration. Usage records aggregate model input, cached input, output, and request counts exposed by the provider.

• Persistence and recovery: The sessions API reads conversation history before a run and writes new items afterward. Documented backends include SQLite, Redis, SQLAlchemy-compatible databases, MongoDB, Dapr state stores, and the OpenAI Conversations API. EncryptedSession wraps another session implementation with encryption and time-based expiry. Session storage preserves conversation items; it does not supply worker leasing, delayed scheduling, or transaction recovery for external tools.

• Human approval state: The human-in-the-loop workflow represents approval points as interruptions. A run can return serializable RunState. The host application stores that state, records approval or rejection decisions, and resumes the run. The approval request contains the tool and arguments proposed by the model. Resumption continues the SDK run with the recorded decision.

• Tool protocols: The SDK supports Python function tools, hosted OpenAI tools, agents used as tools, local shell and computer integrations, and Model Context Protocol servers. The MCP guide documents hosted MCP, Streamable HTTP, Server-Sent Events, and standard input/output transports. It includes tool-list caching and per-tool approval policies. MCP server authentication is configured separately from the agent's model settings.

• Documented security and control mechanisms: Input guardrails run against initial input for the first agent. Output guardrails run against the final agent output. Tool guardrails wrap function-tool execution. Handoff input filters can alter the history transferred to another agent. Tool approval policies can interrupt selected MCP or function calls. The SDK also exposes run hooks and agent hooks around lifecycle events.

• Tracing and telemetry: Tracing is enabled by default in the Python SDK. The tracing documentation covers spans for agent runs, model calls, tool calls, handoffs, and guardrails. Model input, model output, tool input, and tool output can appear in trace payloads depending on settings. Custom trace processors can send records to another destination. The documentation states that organizations using OpenAI Zero Data Retention cannot use the built-in OpenAI tracing service.

The SDK exposes model, tool, guardrail, handoff, session, and trace events; queueing and durable job scheduling remain outside the runner.

• License and service terms: The Python source uses the MIT License. The license permits use, copying, modification, distribution, sublicensing, and sale with preservation of the copyright and permission notice. OpenAI API use is governed separately. The OpenAI Services Agreement states that customers retain input rights, own output to the extent permitted by law, and do not have customer content used to improve services unless they agree.

• Hosted infrastructure: The SDK executes in application-controlled infrastructure. OpenAI hosts model endpoints and the optional trace dashboard. Session backends can run locally, in application databases, or through documented managed services. The SDK repository does not provide a managed worker queue or application uptime service.

• Published support and SLA: The open-source repository uses GitHub issues and release notes for package maintenance. API support and availability are governed by the account's OpenAI service plan and applicable agreement. The SDK documentation does not publish a separate uptime SLA for application code running the local runner.

• Documented limits: Provider adapters do not expose every OpenAI Responses API feature. The models guide records differences involving structured output, tool calls, usage reporting, and provider-specific fields. Session state can contain messages and tool results. Trace payloads can contain model and tool content. The Python release policy permits interface changes in minor releases while the package remains pre-1.0 under its stated scheme.

• Primary sources: SDK overview, agents, runner, multi-agent orchestration, sessions, human approval, MCP, models, tracing, release policy, source license, and OpenAI Services Agreement.

2. LangGraph

• Project and owner: LangChain, Inc. publishes LangGraph. The public repository is langchain-ai/langgraph. The project provides Python and JavaScript libraries. LangSmith is a separate hosted product that supplies deployment, tracing, evaluation, and related operations for LangGraph and other applications.

• Release and status: LangGraph 1.0 is documented as a long-term-support release. LangChain's versioning policy explains major, minor, and patch releases. Its release policy describes maintenance windows for the current and previous major versions. Python and JavaScript packages follow separate package histories.

• Language, package, and API: The Python package is langgraph; persistence implementations use packages such as langgraph-checkpoint-sqlite and langgraph-checkpoint-postgres. The JavaScript package exposes corresponding graph and persistence concepts. The Graph API uses state schemas, nodes, edges, reducers, compiled graphs, and commands. The Functional API uses @entrypoint and @task.

• Execution model: A compiled state graph uses a Pregel-style runtime. Nodes receive graph state and return updates. Edges identify eligible next nodes. A super-step can schedule several nodes at once. Reducers merge concurrent writes to the same state channel. Conditional edges and Command combine state updates with routing decisions. Send creates map-style work with per-invocation state.

• Subgraphs and multi-agent use: A node can invoke another compiled graph. Subgraphs can share parent state keys or use separate schemas with explicit mapping. Prebuilt agents use this graph runtime but are not required. Model calls and tool calls remain ordinary node or task code from the runtime's perspective.

• Functional execution model: @entrypoint marks the durable outer function. @task marks units whose results can be persisted and reused. Ordinary control flow, loops, and conditionals remain in the host language. The Functional API uses the same checkpointer concepts as the Graph API.

• Persistence and recovery: The persistence documentation identifies a thread_id as the key for checkpoint history. A checkpointer writes a StateSnapshot at super-step boundaries. The snapshot includes channel values, configuration, metadata, next nodes, and tasks. A store holds data across threads and is separate from the checkpointer.

• Pending writes and recovery: Pending writes record results from completed tasks when another task in the same super-step fails. On a later run, completed task results can be reused instead of executed again. Checkpoint replay starts from a recorded state and creates a new execution branch. The runtime does not reverse effects already performed in external systems.

• Checkpointer interfaces and storage: Documented saver methods include put, put_writes, get_tuple, and list, with asynchronous variants. SQLite and PostgreSQL implementations are separate packages. Serialization supports typed values and optional encryption. The persistence documentation also describes a pickle fallback and states the code-execution risk of loading untrusted pickled checkpoint data.

• Checkpoint inspection and state updates: Thread-state APIs return the current snapshot or historical snapshots for a thread. update_state writes values as if they came from a named graph node and creates another checkpoint. The as_node argument affects which node the scheduler treats as the writer and therefore which edge runs next. Checkpoint metadata records source, step, writes, and parent configuration where the saver supports them.

• Time travel and branching: A prior checkpoint configuration can become the input to a new run. Steps before that checkpoint are replayed from recorded state, while later steps execute on the new branch. A state update applied to a historical checkpoint creates another branch. The checkpoint record does not remove the original history or reverse external effects from either branch.

• Interrupts and human input: interrupt() emits JSON-serializable data and pauses execution. Resumption uses the same thread_id and a Command containing resume data. The interrupted node starts again from its beginning. The documentation places side effects before an interrupt outside exactly-once guarantees because that code can execute again.

• Tool protocols: LangGraph nodes and tasks can call Python or JavaScript functions, LangChain tool objects, provider-hosted tools, and remote services. LangChain MCP adapters load tools from MCP servers. Tool schema validation occurs in the tool layer. Graph routing and checkpoint storage remain separate from MCP transport and authentication.

• Documented security and control mechanisms: State schemas restrict stored keys and value types. Reducers define merge behavior. Recursion limits bound graph steps. Interrupts create external decision points. Static breakpoints stop before or after named nodes for debugging. Operator APIs can inspect threads, checkpoint history, and state, and can create updated state snapshots.

• Persistence data model: Checkpoints, pending writes, cross-thread store entries, traces, datasets, and application artifacts occupy separate storage systems. LangSmith's hosted deployment adds run queues and Agent Server workers. The Agent Server architecture describes workers acquiring queued runs, loading graph and checkpoint state, executing application code, and streaming events.

LangGraph distinguishes thread checkpoints from cross-thread store data; LangSmith traces and application artifacts use additional stores.

• License and service terms: LangGraph source uses the MIT License. LangSmith is governed by separate commercial service terms. The source license does not set LangSmith retention, support, or uptime terms.

• Hosted infrastructure: LangGraph runs as a library with an application-selected checkpointer and worker environment. LangSmith Deployment provides a managed path. The self-hosted LangSmith architecture lists application services, PostgreSQL, Redis, ClickHouse, and optional blob storage. The documentation uses Kubernetes and Helm for the self-hosted deployment model.

• Retention record: LangSmith's administration documentation documents 14-day base trace retention, 400-day extended retention, and dataset retention until deletion. The data-purging documentation describes purge APIs and compliance deletion paths. Contract and plan details can alter available features.

• Published support and SLA: LangGraph repository maintenance follows the published package release policy. LangSmith support and service commitments belong to LangSmith plans and signed terms. The open-source LangGraph license disclaims warranties and does not provide an application-service SLA.

• Documented limits: Resuming an interrupt restarts its node. State schemas and serialized values require compatibility across application versions. A replay creates another execution path without undoing prior effects. Large conversation or artifact data stored directly in graph channels increases checkpoint size. Concurrent updates to one channel require a reducer or a single writer.

• Primary sources: repository, Graph API, Functional API, persistence, interrupts, versioning, release policy, Agent Server architecture, self-hosted LangSmith, retention, purging, and license.

3. Microsoft Agent Framework

• Project and owner: Microsoft publishes Microsoft Agent Framework in microsoft/agent-framework. The documentation describes it as the successor to Semantic Kernel's agent features and AutoGen. The separate microsoft/autogen repository states that AutoGen is community-managed and in maintenance mode.

• Release and status: Microsoft Learn maintains the framework overview and migration guides. Package and language features are released independently for Python and .NET. Microsoft documents migration from AutoGen and Semantic Kernel. Preview and general-availability labels can differ between an open-source package and a Microsoft Foundry hosted feature.

• Language, package, and API: The framework exposes Python and .NET APIs. Its agent layer includes model clients, messages, sessions, context providers, functions, MCP tools, middleware, and response streaming. Its workflow layer includes typed executors, graph edges, messages, checkpointing, and event streaming. Azure and non-Azure model clients connect through provider packages.

• Execution model: A model client receives messages, instructions, and registered tools. Model-requested function calls execute and return results for subsequent model turns. An agent session carries conversation-specific state. Context providers add memory or other application context to a run without requiring every item to remain in the transcript.

• Workflow execution model: Executors receive typed messages and emit messages to connected executors. Graph edges represent sequential, conditional, fan-out, fan-in, and externally controlled routing. An executor can wrap an agent or ordinary application function. Workflow events expose execution progress and output.

• Workflow construction: Workflow builders register executors and connect them with typed edges. Edges can carry messages to one executor, several executors, or an aggregation point. Executor state is separate from the messages traveling along edges. A workflow run can stream events to the caller while its executors process messages.

• Agent responses and streaming: Agent calls can return complete responses or streamed response updates. Response objects contain messages, content items, usage data, and provider metadata according to the model client. Function-call and function-result content use typed objects. Middleware can observe the same request and response path without changing the agent's public call shape.

• AutoGen migration record: The AutoGen migration guide maps AutoGen agents to Agent Framework agents and maps teams to typed workflows. It documents differences in message types, state, orchestration, and package names. AutoGen state and group-chat events do not have a byte-for-byte persistence format shared with Agent Framework.

• Persistence and recovery: Agent sessions preserve agent-specific conversation state. Workflow checkpointing saves executor state and pending messages. Resumption reads those types through the deployed application's serializers. Checkpoint compatibility therefore depends on the application version retaining or migrating each stored executor-state type.

• Middleware: The middleware documentation covers interception of an agent run, a function call, or a chat-client request. Middleware can add context, logging, policy checks, retries, caching, and telemetry. Ordering follows the configured middleware chain. Function-call middleware receives the resolved function and arguments.

• Tool protocols: Typed Python and .NET functions become agent tools. MCP clients expose remote server tools to the agent. Tool descriptions and schemas guide model selection and argument generation. The function implementation retains responsibility for authentication, tenant checks, resource ownership, and external side effects.

• Documented security and control mechanisms: Middleware can apply policy before function dispatch. Azure integrations can use Microsoft Entra ID and managed identity. Application Insights and OpenTelemetry integrations record agent and workflow activity. Workflow graph edges constrain permitted routes. Human input can enter through workflow events and executor messages.

• Hosted identity and data boundaries: The framework can run as source packages in application infrastructure. Microsoft Foundry provides hosted agents, model endpoints, tracing, identity integration, and related services. Each billed Azure resource has its own region list, product terms, data-handling documentation, and service status.

Microsoft Agent Framework packages can run in application infrastructure; Microsoft Foundry and Azure services use separate service identities, contracts, and availability records.

• License and service terms: Agent Framework source uses the MIT License. Microsoft Azure and Foundry services use the Microsoft Product Terms, Data Protection Addendum, and service-specific terms. AutoGen code uses LICENSE-CODE, while other material in the AutoGen repository can carry separate notices.

• Hosted infrastructure: The open-source packages run in Python or .NET processes selected by the application owner. Azure provides model hosting, identity, monitoring, storage, and Foundry agent services. The framework repository does not turn a locally hosted workflow into a Microsoft-operated service.

• Published support and SLA: Repository issues and releases cover source maintenance. Azure support depends on the subscribed Azure Support plan. SLA coverage depends on the exact Azure service and feature, its region, and its availability status. A framework package release does not create an uptime SLA for application-owned workers.

• Documented limits: Python and .NET packages can expose different features and serialization details. AutoGen migration changes agent, team, message, event, and workflow APIs. Middleware retries can execute a function more than once if external side effects complete before a failure is recorded. Checkpoint restoration requires stored state to remain readable by the deployed code.

• Primary sources: framework repository, overview, AutoGen migration, middleware, Agent Framework license, AutoGen repository status, and AutoGen code license.

4. Google Agent Development Kit

• Project and owner: Google publishes the Agent Development Kit, usually abbreviated ADK. The Python repository is google/adk-python. Google also publishes Java and other ecosystem components. The documentation is hosted at google.github.io/adk-docs.

• Release and status: The Python repository describes an approximately biweekly release cadence. Release records and package changelogs identify versions. Feature availability can differ by language. Local ADK packages, Cloud Run deployment, and Vertex AI Agent Engine have separate version and service records.

• Language, package, and API: The Python package exposes agents, runners, sessions, events, callbacks, tools, artifacts, planners, and memory interfaces. Java has a separate SDK. Core agent types include LlmAgent, SequentialAgent, ParallelAgent, and LoopAgent. A runner binds an agent tree to session and artifact services.

• Execution model: The runtime documentation describes a run as processing a new message through an agent tree and yielding events. Events represent model output, tool calls, tool responses, agent transfers, state changes, artifact changes, and final responses. LlmAgent uses a model to select tools and transfer control. Workflow agents apply declared sequencing, parallelism, or looping.

• Callbacks: Callbacks run before and after agent execution, model calls, and tool calls. They can inspect inputs, outputs, context, and state. Some callback return values replace the underlying model or tool operation. Callback ordering and exceptions therefore affect event history and final output.

• Persistence and recovery: The sessions documentation defines a session as the transcript, event history, and current state for one conversation. SessionService creates, reads, updates, and lists sessions. In-memory service is documented for local development. Database-backed and Vertex AI managed services provide persistent storage paths.

• State changes: Event actions carry state updates so the session service records the change with the event. Direct mutation of a local in-memory session object does not create the same durable event record. State keys can use prefixes for application, user, and session scope according to ADK conventions.

• Artifacts and memory: ArtifactService stores named, versioned binary objects outside message text. Sessions can refer to artifacts through events. Memory services provide retrieval across session history. These stores have separate persistence and deletion behavior.

• Long-running tools: Long-running function tools emit intermediate events and later receive a completed tool result. Consumers process the intermediate and final events in order. Worker termination and duplicate external writes are outside the event schema unless the application records them through tool-specific state.

• Tool protocols: ADK supports custom function tools, Google tools, OpenAPI-generated tools, MCP tools, agents used as tools, and authenticated tools. Tool authentication can request a credential through the runtime. MCP connections use the server's declared transport and authentication.

• Development interfaces: ADK includes command-line development surfaces for running an agent, launching a local web interface, and serving an API. The runner and local services load an agent application from its package structure. The web and API development servers expose session and event behavior around the same agent code used by the local runner.

• Evaluation records: ADK documentation includes evaluation sets composed of conversations, expected tool trajectories, and response criteria. Evaluations can compare tool calls and final responses under configured metrics. Evaluation artifacts remain separate from production session state and Agent Engine service records.

• Documented security and control mechanisms: Tool confirmation can pause a function request for human response. Callbacks can reject or replace a tool action. Workflow agents constrain order and concurrency. Session services preserve event history. Google Cloud deployments can apply IAM, service accounts, VPC controls, and Cloud audit records according to the selected service.

• Persistence issue record: GitHub issue 3197 documented older serialized sessions failing after library fields and database columns changed. The issue is closed and records the related fix. It remains a public example of session-schema compatibility across versions.

• License and service terms: The Python project uses the Apache License 2.0. Google Cloud and Vertex AI use separate cloud terms. Google's Vertex AI data-governance documentation states that customer data is not used to train or fine-tune models without permission or instruction and documents feature eligibility for zero data retention.

• Hosted infrastructure: ADK can run in local processes and application-managed containers, including Cloud Run. Vertex AI Agent Engine provides managed deployment, sessions, memory, evaluation, and operations. Local ADK, Cloud Run, and Agent Engine use different identity, persistence, scaling, network, and observability systems.

• Published support and SLA: The Python repository publishes releases and issue tracking. Google Cloud Customer Care covers subscribed cloud services under its plans. The Vertex AI SLA lists covered services and availability commitments. SLA coverage depends on whether the selected Agent Engine feature and region appear in the applicable service definition.

• Documented limits: Parallel agents can return overlapping state updates. Database and managed session stores require schema compatibility. The language SDKs do not expose every feature at the same time. Event history can contain prompts, tool arguments, tool results, state changes, and artifact references. Local execution does not reproduce Agent Engine identity, quota, networking, or service availability.

• Primary sources: ADK documentation, Python repository, runtime, sessions, session compatibility issue, license, Agent Engine, Vertex AI data governance, and Vertex AI SLA.

5. CrewAI

• Project and owner: CrewAI Inc. publishes the open-source CrewAI framework and the commercial CrewAI AMP platform. The source repository is crewAIInc/crewAI. The framework separates crews, which coordinate role-based agents and tasks, from flows, which define event-driven application control.

• Release and status: The repository publishes Python package releases and a changelog. CrewAI documentation covers open-source packages and AMP under separate navigation sections. Hosted AMP features and terms can change independently of the source package.

• Language, package, and API: CrewAI is a Python framework. Main objects include Agent, Task, Crew, Process, Flow, and tools. Crews use sequential or hierarchical processes. Flows use decorators for start methods, listeners, and routers. Flow state can be a dictionary or a Pydantic model.

• Execution model: A sequential crew runs tasks in declared order. Later tasks can receive earlier outputs as context. A hierarchical crew uses a manager agent or manager model to allocate and review tasks. Delegation exposes agents as collaborators. Crew-level settings control process type, manager model, memory, caching, planning, and execution limits.

• Agent and task records: An agent definition includes role, goal, backstory, model, tools, delegation setting, iteration limits, request limits, execution-time limits, callbacks, and code-execution settings. A task includes a description, expected output, assigned agent, tools, context tasks, guardrails, callback, async setting, and output destination. Task output records raw text and can include Pydantic or JSON output when configured.

• Crew kickoff interfaces: Crews expose synchronous, asynchronous, batch, and replay-related kickoff paths in the documented API. Inputs become interpolation values available to task and agent definitions. Crew output contains the final raw result, structured result when configured, task outputs, and usage metrics. Hierarchical crews require a manager agent or manager model.

• Flow execution model: The flows documentation describes an event-driven outer workflow. @start marks entry methods. @listen runs methods after named events. @router selects later paths. A flow method can call a crew, ordinary Python code, or an external service. Flow execution emits state and event records.

• Persistence and recovery: Flow persistence saves state after method execution and reloads it by flow identifier. Typed flow state records a declared schema. A failure after an external write and before the next state save leaves the external operation and stored flow state at different points. Crew memory, task output, flow state, and hosted run records are separate data collections.

• Crew memory: CrewAI documents short-term, long-term, entity, and contextual memory facilities. Storage backends and embedding providers vary by configuration. Memory can be shared into later model prompts. Memory records and flow checkpoints have different retrieval and deletion paths.

• Tool protocols: Agents can use CrewAI's packaged tools, custom Python tools with declared argument schemas, MCP servers, and delegated agents. Tools execute with the permissions and credentials of their worker or remote service. MCP supplies discovery, schemas, transport, and server authentication according to the configured server.

• Output checks: Task guardrails receive task output and can accept, reject, or transform it according to application code. A failed guardrail can produce another agent attempt up to configured limits. Guardrails operate on task output after tools used during the task have already executed.

• Documented security and control mechanisms: Agent and crew settings include maximum iterations, maximum requests per minute, maximum execution time, delegation controls, tool lists, cache settings, and manager configuration. Flows expose declared routes around crew calls. Typed state uses Pydantic validation. Hosted AMP adds team and deployment controls described in its documentation.

• Telemetry: The repository's telemetry section says anonymous telemetry is active unless disabled. It lists collected framework and execution metadata and distinguishes anonymous telemetry from the share_crew option, which sends additional execution information. Environment settings control telemetry behavior.

CrewAI's open-source package, model providers, AMP platform, and connected tools each have separate licenses or service terms.

• License and service terms: Framework source uses the MIT License. AMP is governed separately. CrewAI's public terms of use, effective September 24, 2025, grant platform rights to use customer data to provide services, improve products and services, train or develop models or algorithms, and create aggregated data under section 1.5. Signed order forms and addenda can set different terms.

• Hosted infrastructure: Open-source CrewAI runs in application-managed Python environments. CrewAI AMP provides hosted deployment, REST access, triggers, integrations, observability, and team administration. Hosted connectors can add OAuth grants, third-party service accounts, and provider data retention.

• Published support and SLA: The source repository provides issue tracking and releases. AMP support, incident response, uptime, retention, and export rights depend on the subscribed plan and contract. The public framework license disclaims warranties and does not set a hosted-service SLA.

• Documented limits: Hierarchical processes add manager model calls and task review. Open-ended agent delegation can continue until iteration, time, or request limits stop it. Persisted Pydantic state requires schema migration when fields change. Anonymous telemetry remains active until disabled. Guardrails attached to tasks evaluate output and do not authorize external writes before tool execution.

• Primary sources: repository, crews, flows, telemetry, AMP overview, MIT license, and CrewAI terms.

6. Strands Agents

• Project and owner: AWS publishes Strands Agents as open-source Python and TypeScript SDKs. The Python repository is strands-agents/sdk-python. AWS documents Strands alongside Amazon Bedrock AgentCore, a group of managed agent services.

• Release and status: Python and TypeScript use separate repositories and release streams. The language overview records feature coverage for each SDK. Experimental and provider-specific features can appear in one language before the other.

• Language, package, and API: The Python and TypeScript SDKs expose agents, model providers, tools, hooks, sessions, conversation managers, MCP, OpenTelemetry, graphs, workflows, and swarms. The Python quickstart uses Amazon Bedrock by default. Documentation also covers Anthropic, Gemini, OpenAI, Ollama, LiteLLM, and custom model providers.

• Execution model: The agent loop sends messages, instructions, and tool definitions to a model. It executes requested tools, appends results, and calls the model again. Streaming exposes lifecycle events. Model providers implement a common interface while retaining provider-specific configuration and event differences.

• Graph, workflow, and swarm execution: Graphs use declared nodes and edges. Workflows sequence agents. Swarms allow agents to hand control to one another while sharing context and working memory. The swarm guide documents limits for handoffs, iterations, and execution time.

• Tool concurrency: Strands uses concurrent tool execution by default when a model requests several tools. The tool-executor documentation also provides a sequential executor. Dependency ordering therefore depends on executor choice or declared workflow structure.

• Persistence and recovery: Session managers store messages and state in files, Amazon S3, or a repository implementation. Conversation managers control the history sent to the model. Sliding-window management drops older context according to configured rules. Summarizing management replaces older conversation material with derived summaries. Session storage and model-context choice are separate interfaces.

• Model-provider interface: A provider adapter receives system prompts, messages, tool specifications, and inference configuration, then emits normalized stream events. Provider implementations can expose additional configuration for credentials, region, model identifiers, caching, and request options. Tool-call, usage, and reasoning event coverage depends on the provider.

• Observability: Strands emits OpenTelemetry traces and metrics for agent loops, model calls, tools, and multi-agent activity according to the configured exporter. Hooks can add attributes or records at lifecycle boundaries. AgentCore Observability is one destination; a separately configured OpenTelemetry collector is another.

• Hooks: The hooks documentation describes typed events before and after invocations, model calls, tool calls, and graph nodes. A before-tool hook can cancel a call, change the selected tool, or modify arguments. Hook code executes in the host application and can emit telemetry or policy records.

• Tool protocols: Tools can be decorated functions, TypeScript functions, community packages, MCP tools, or other agents. The tools documentation states that tools run with the permissions of the host process. MCP requests use remote server authentication and transport configured by the application.

• Cancellation: The agent-loop documentation distinguishes cancellation behavior by tool type. An in-flight MCP request receives best-effort cancellation. An ordinary local tool can complete before the loop observes cancellation. Final external state therefore depends on the tool and service involved.

• Documented security and control mechanisms: The sandbox documentation describes isolation for code execution. A sandboxed command runs within the configured sandbox boundary. Hooks can cancel or modify tool calls. Swarm settings limit handoffs, iterations, and execution time. The agent process, model call, session manager, and tools outside a configured sandbox remain separate components.

• License and service terms: The Python SDK uses the Apache License 2.0. Amazon Bedrock and AgentCore use the AWS Service Terms and AWS data-processing terms. Model providers other than Bedrock use their own service terms.

• Hosted infrastructure: The SDK can run in application-managed infrastructure. Amazon Bedrock AgentCore provides Runtime, Memory, Gateway, Identity, Browser, Code Interpreter, Observability, and related services. AgentCore Runtime hosts containerized applications. IAM integration covers policies and temporary credentials.

• Service boundaries: AgentCore is a group of services rather than one storage and execution process. Runtime, Memory, Gateway, Identity, Browser, Code Interpreter, and Observability have distinct IAM actions, data paths, networking, and retention records. SDK session managers can also use stores outside AgentCore.

• Published support and SLA: The AgentCore FAQ says the Amazon Bedrock SLA applies to AgentCore. The Amazon Bedrock SLA defines availability percentages, service-credit tiers, exclusions, and claim procedures for covered services. AWS Support plans govern case response and escalation separately from service availability.

• Documented limits: Python and TypeScript feature coverage differs. Default tool concurrency can execute independent requests at the same time. Swarm limits stop local orchestration but do not undo completed external operations. Session restoration recreates conversation state without providing business transaction recovery. Sandbox coverage applies to configured sandbox operations and does not encompass every SDK component.

• Primary sources: Python repository, language overview, agent loop, tools, tool executors, hooks, swarm, sandbox, SDK license, AgentCore, runtime, IAM, AgentCore FAQ, Bedrock SLA, and AWS Service Terms.

7. OpenAI Codex

• Project and owner: OpenAI publishes Codex as a coding-agent product and an open-source command-line client. The client repository is openai/codex. It contains the Rust workspace for the CLI, terminal interface, execution core, application server, MCP server, protocol types, and supporting packages.

• Release and status: The repository publishes tagged releases and platform binaries. Codex product access and model availability are governed by OpenAI account and product plans. The open-source client and hosted Codex services have separate release paths.

• Language, package, and API: The current client is implemented primarily in Rust. It provides an interactive terminal interface and the non-interactive codex exec command. The application server exposes threads, turns, items, diffs, commands, and approvals through JSON-RPC. Codex can also expose an MCP-compatible server for client integrations.

• Execution model: An interactive thread contains user turns and agent actions. A turn can include model output, shell commands, file edits, MCP calls, and requests for user input. Commands run with a configured working directory, environment, approval policy, and sandbox policy. File changes remain in the workspace.

• Non-interactive execution model: codex exec accepts a task for script or CI execution and emits terminal, JSON, or structured events according to options. Exit status represents the client process. External commands and remote actions can complete before a process interruption, so process failure is separate from external action status.

• Application-server protocol: The app-server README documents JSON-RPC messages for thread creation and resumption, turns, items, review, commands, patches, and approvals. Clients correlate events through stable thread, turn, and item identifiers. Approval requests carry associated command or file-change context.

• Persistence and recovery: Threads can be resumed through supported interfaces. Resumption restores conversation and item context. Workspace files and Git preserve repository changes. Neither thread context nor Git records every remote write, database mutation, sent message, or published package performed by commands.

• Workspace state: The CLI detects changed files and produces diffs. Pre-existing user changes can coexist with agent edits. Repository configuration, build scripts, dependency manifests, hooks, and tool outputs become input to the agent and command environment. A clean CI checkout and a long-lived developer checkout therefore present different state.

• Instruction discovery: Codex reads instruction files from configured locations and applies repository-scoped guidance according to directory scope. Instructions can describe commands, tests, formatting, file ownership, and repository procedures. They are model context rather than operating-system policy. Sandbox and approval settings continue to govern executable access.

• Configuration record: Client configuration covers model choice, provider, reasoning settings, approval policy, sandbox policy, MCP servers, profiles, environment handling, notifications, and other client behavior. Repository, user, and command-line configuration can affect the effective run. The app-server protocol reports configured behavior through its client and thread interfaces rather than requiring terminal-text parsing.

• Patch and review items: Supported interfaces represent file changes as patch or diff items. A review-mode run can inspect repository changes and return findings without creating a commit. A commit remains an ordinary version-control operation. The client repository and protocol distinguish a proposed file change from a later Git commit.

• Approval and sandbox controls: Approval policy determines when an operation requires human consent. Sandbox policy determines filesystem, process, and network access for commands. These settings are independent. A permissive approval policy does not expand a restrictive sandbox, and approval does not add privileges unavailable to the sandbox.

• Tool protocols: Codex uses built-in shell and file-editing operations and can connect to MCP servers. MCP adds remote tools and resources using configured credentials. Codex's MCP server presents Codex capabilities to another MCP client. Server authentication and action permissions remain specific to each integration.

• Documented security and control mechanisms: The harness can set a working directory, restrict writable paths, control network access, and require approvals for commands or file changes according to the active mode. Approval policy and sandbox policy are separate controls. Tool output and repository instructions enter the agent context. The client records command and patch items for review.

Codex runs commands and edits inside the configured workspace and sandbox; model inference and MCP services cross separate network and credential boundaries.

• License and service terms: The client uses the Apache License 2.0. The license covers repository source, not hosted inference. OpenAI account, API, ChatGPT, or Codex service terms govern submitted code, model access, retention, and support according to the selected product path.

• Hosted infrastructure: Commands and file edits execute on the machine, container, or remote environment running the client, unless a specific Codex hosted product supplies the workspace. Model inference uses the configured OpenAI service. MCP servers and other integrations use their own infrastructure.

• Published support and SLA: GitHub releases and issues cover the open-source client. Hosted product support follows the OpenAI plan and agreement for the account. The Apache-licensed client does not include an uptime commitment for a local workspace or customer CI worker.

• Documented limits: Codex is specialized for software work. A resumed thread does not provide exactly-once command semantics. Untrusted repository code can execute in test processes. Network denial can prevent dependency installation or integration tests. A passing test run reflects the tests that executed and does not add transactional rollback for remote side effects.

• Primary sources: Codex repository, app-server protocol, approval protocol, and Apache 2.0 license.

8. Anthropic Claude Code

• Project and owner: Anthropic publishes Claude Code as a coding-agent product. The public distribution and issue repository is anthropics/claude-code. The repository license notice states that use is governed by Anthropic's Commercial Terms rather than an open-source software license.

• Release and status: Anthropic distributes Claude Code through supported installation channels and publishes release information in its repository and documentation. Product behavior, model access, and hosted service terms follow the account and authentication route. Direct Anthropic access and supported cloud model platforms can use different commercial contracts.

• Language, package, and API: Claude Code provides an interactive terminal interface and a non-interactive print mode. The CLI reference documents claude -p, JSON output, streaming output, session continuation, session resumption, turn limits, permission modes, system prompts, a model flag, and MCP configuration.

• Execution model: Interactive mode maintains a repository-aware conversation. A session can include model output, file reads, file edits, shell commands, searches, MCP calls, hooks, and approval prompts. File changes remain in the selected workspace and are visible through version-control tools.

• Print-mode execution: claude -p returns non-interactive output for scripts and automation. --output-format json and streaming formats expose structured records. --max-turns limits agent turns in print mode. Process timeouts and worker lifecycle belong to the calling automation system.

• Persistence and recovery: --continue loads the most recent conversation for the current directory. --resume selects a prior session by identifier. Resumption restores conversation context. It does not reverse commands or remote writes completed in a prior process. The current checkout, dependencies, tool configuration, and organization settings can differ from those used earlier.

• Hooks: Claude Code hooks run commands at documented lifecycle points. Hook configuration can come from user, project, or organization-managed settings. Hooks execute outside the model's generated shell step and can read lifecycle input or affect subsequent actions according to their configuration.

• Instruction and settings files: Claude Code uses CLAUDE.md files for project and user instructions. Settings can be stored at user, project, local-project, and managed-policy levels according to product documentation. The effective configuration can include permissions, hooks, environment variables, plugins, and MCP servers. Managed settings can restrict configuration available to local users.

• Structured output: Print mode can emit plain text, JSON, or stream-oriented JSON. Structured records include message and result information used by calling scripts. The final result record is distinct from shell-command output generated during the session. Exit status and result payload represent the client process rather than a transaction status for every external system called by tools.

• Subagents and task records: Claude Code can delegate bounded work to subagents configured with separate instructions and tool access. The parent session receives subagent results through the product's task flow. Subagent execution remains part of the same workspace and surrounding credential boundary unless the deployment supplies separate isolation.

• Tool protocols: Claude Code includes repository, file, and shell tools and supports MCP servers. MCP configuration can be project-scoped, user-scoped, or managed by an organization. A project repository can therefore carry MCP configuration that affects the tool surface after checkout, subject to product settings and approval.

• Documented security and control mechanisms: Permission modes determine when tool use requires approval. The CLI documents --dangerously-skip-permissions, which bypasses permission prompts. Command execution still occurs with the operating-system, container, workspace, credential, and network privileges available to the process. Managed settings and corporate proxy configuration add organization-level controls.

• Enterprise network controls: The corporate proxy documentation separates API, telemetry, and error-reporting endpoints. Enterprise deployments can route these endpoints through a corporate proxy. Proxy configuration, certificate trust, endpoint allowlists, and payload inspection belong to the surrounding network.

• Data collection record: The repository's data collection section describes usage data, feedback, and error reporting. It says feedback can include usage signals, associated conversation data, and /bug submissions. Account type and commercial terms determine additional data-handling conditions.

• Workspace and recovery: Repository files and Git record file changes. Session history records conversational context. Neither system provides a transaction log for cloud resources, messages, database changes, or publications executed by commands. Automated jobs can preserve command output and test records outside an ephemeral workspace through the calling system.

• License and service terms: LICENSE.md states that Claude Code use is subject to Anthropic's Commercial Terms. The public repository does not grant an MIT, Apache, BSD, or other open-source client license. Model inference and product use follow the contract attached to the authentication route.

• Hosted infrastructure: File edits and commands run in the configured local, container, virtual-machine, or remote development workspace. Model inference uses Anthropic's hosted service or another documented provider path. MCP servers, proxies, telemetry endpoints, and source-control services use separate infrastructure.

• Published support and SLA: Repository issues and product documentation provide public maintenance channels. Commercial support and service availability follow the applicable Anthropic or cloud-provider agreement. The public repository's commercial license notice does not publish an uptime SLA for a locally executed command or customer-managed CI worker.

• Documented limits: Claude Code is a coding harness rather than an embeddable general-purpose workflow scheduler. Session resumption does not provide exactly-once command execution. Hooks and MCP servers expand the executable and remote tool surface. Print-mode turn limits bound model turns but do not by themselves set operating-system process, network, or external-service timeouts.

• Primary sources: Claude Code documentation, CLI reference, corporate proxy requirements, public repository, data collection and retention section, and license notice.