Building an Enterprise Agent Harness from Scratch10/10: Which 2026 Frameworks and Product APIs Can Implement This Architecture?

The first nine chapters assembled the parts of an enterprise agent harness. Now I will lay out the frameworks, SDKs, model APIs, and managed agent products available in 2026 and see which work each can take over. Keep the $42 refund in mind while reading: are we missing the loop that lets the model call tools, or the ability to wait for approval, recover a task, and check its result? That question gives each product name a purpose.

First, Which Ready-Made Tools Are Available?

Frameworks, SDKs, and Open-Source Harnesses for Building Agents

This group consists of development tools that go inside our own services. A framework organizes program flow; an SDK is a collection of components we can call directly. They help run the loop in which a model chooses the next step, calls a tool, and receives its result. A harness surrounds that loop with context, tools, state, and approval. The enterprise application still decides how to deploy the service, who the user is, and whether the refund may execute. Read “What it does for me” first to find the work you want to hand over, then check the runtime and model binding to see whether it fits your existing system.

Product	What it does for me	Runtime / When to use it	Bound to a model provider?
LangChain stack (LangGraph / LangChain / Deep Agents)	LangGraph preserves state and controls transitions between steps. LangChain provides the standard model–tool loop. Deep Agents adds planning, file-based context, and subagents.	Runs in your application or Agent Server; choose an entry point based on how much control you need.	No: supports multiple model providers.
OpenAI Agents SDK	Its runner handles the multi-turn loop, tools, agent handoffs, input/output checks, session state, and execution traces.	Runs in your application; useful when already using OpenAI APIs while retaining control of deployment and business state.	No: supports non-OpenAI models, custom model integrations, and LiteLLM; platform-provided tools vary with the model.
Claude Agent SDK	Runs the Claude Code loop in a team-managed process, including file operations, command execution, permissions, sessions, and checks around execution.	Runs in your Python or TypeScript application; useful for reading and writing files, working in repositories, or executing commands.	Yes: Claude. Bedrock or Vertex changes the deployment entry point.
Google Agent Development Kit (ADK)	Provides agent components in multiple languages, step routing, retries, human input, session state, and evaluation.	Runs locally or in the cloud; useful for defined workflows or collaboration between agents.	No: supports Gemini, Claude, OpenAI, and other models.
Microsoft Agent Framework	Provides basic agents, Harness Agents with planning and file capabilities, graph workflows, session state, interception around execution, and MCP tools.	Available in C# and Python, with Go in public preview; can also deploy to Foundry. Version 1.0 became generally available in April 2026, and the Harness was released on July 22.	No: supports Foundry, Anthropic, OpenAI, Ollama, and other model sources.
Strands Agents SDK	Provides the model–tool loop, session state, checks around execution, human intervention, budgets, and cancellation controls.	Runs in your Python or TypeScript process; useful for starting with a small loop and adding production controls.	No: Bedrock is the default, with Anthropic, OpenAI, Gemini, and other providers also supported.
Pydantic AI	Uses Python types to define dependencies, tool inputs, and structured outputs, exposing invalid fields before execution.	Runs in your Python service; useful for teams emphasizing type checks, tests, and data contracts.	No: supports multiple model providers; provider-specific parameters need reconfiguration.

APIs for Calling Models and Agent Capabilities Directly

Once a framework runs the agent loop, each round still needs a model endpoint. An API is the interface through which a program requests another service. These APIs accept inputs and return model results and tool requests. A team can call them directly or use them through the SDKs above.

Product API	What it does for me	Runtime / When to use it	Bound to a model provider?
OpenAI Responses API	Accepts text, images, and files, and lets the model request functions, web search, file search, or remote MCP tools.	The model runs at OpenAI; useful for direct model requests or a loop written by your team.	Yes: OpenAI.
Claude API: Messages API	Sends structured messages through `POST /v1/messages`. Claude proposes tool requests with `tool_use`; the application executes them and returns `tool_result`.	The model runs on Anthropic's platform; useful when the team controls requests, client-side tools, and business state.	Yes: Claude.
Gemini API: Interactions API	Provides a unified way to call Gemini models and specialist agents, with server-side conversation state, background long-running tasks, and execution steps that can be displayed.	The model or agent runs at Google; generally available in June 2026.	Yes: Gemini.

Platforms That Host Agent Execution

After connecting the model and loop, the team must still preserve sessions, maintain the runtime, isolate users' tasks, and scale as requests increase. Managed platforms take over some of that work along with the harness. Compare the actual responsibilities they accept. “Managed” means the platform runs that part of the program. Hosting your own agent code and using a loop supplied by the platform are different scopes of responsibility.

Product	What it does for me	Runtime / When to use it	Bound to a model provider?
Claude Managed Agents	Anthropic hosts the loop and sessions. The isolated environment for commands and files can be managed by Anthropic or self-hosted by the team.	Runs as an Anthropic managed service; introduced in April 2026 and currently in beta.	Yes: Claude.
OpenAI Agents API	OpenAI runs the Codex harness, saves sessions, and manages long context. The execution environment can be platform-hosted, self-hosted, or omitted.	Runs on OpenAI's managed harness; entered public beta on September 10, 2026.	Yes: OpenAI-hosted models and harness.
Amazon Bedrock AgentCore Runtime	Hosts and scales the team's agent container, isolates sessions, and connects identity and runtime records. The agent loop remains the team's code.	Runs on AWS; useful when you already have agent code and want to hand over the runtime infrastructure.	No: you can choose models; the runtime, AWS identity, and observability depend on AWS.
Amazon Bedrock AgentCore Harness	Supplies a Strands-powered managed loop. The team declares models, tools, skills, and instructions.	Runs on AgentCore Runtime; generally available on June 17, 2026.	No: supports Bedrock, OpenAI, Gemini, and LiteLLM-compatible providers; the platform depends on AWS.
Gemini Enterprise Agent Platform	Deploys agents through Agent Runtime and connects identity, tool entry points, memory, and observability in one platform.	Runs on Google Cloud; launched in April 2026.	Depends on the supported catalog: models are selectable; execution depends on Google Cloud.
Microsoft Foundry Agent Service	Prompt Agents run from configuration. Hosted Agents accept the team's framework or container and provide an endpoint, automatic scaling, Entra identity, session state, and observability.	Runs in Microsoft Foundry; useful for organizations already using Azure identity and networking.	Depends on the Foundry model catalog; execution depends on Azure.

Add Durable Execution and Observability

Whether a team runs the loop or uses a managed platform, concrete systems must determine where to resume after a restart and how to investigate a failure. Durable execution saves progress so a task can continue across restarts. Observability preserves records of calls that can be investigated. The following products take on different parts of that work; not every product performs both jobs.

Supporting product	What it does for me	Runtime / When to use it	Bound to a model provider?
Temporal	Restores the task from execution history. Model calls and payment queries become retryable steps; durable timers and external notifications support approval waits.	Self-hosted or Temporal Cloud; useful for critical workflows across services or days.	No: does not restrict the LLM.
Restate	Records completed steps and business state and can wait across restarts for human approval or an external callback.	Cloud, BYOC, or self-hosted; integrated with Pydantic AI in May 2026.	No: does not restrict the LLM.
DBOS	Uses a library and decorators to store workflows, steps, and waiting progress in Postgres, then continues from completed steps after restart.	Runs beside your application and Postgres; useful for teams already using Postgres.	No: does not restrict the LLM.
LangSmith	Collects model calls, tool calls, and errors, turns production failures into test data, and compares versions for regressions.	Cloud, Hybrid, or self-hosted; useful for tracing agent paths and setting release gates.	No: does not restrict the LLM.

How Much Must Change to Switch Models?

The final column answers model compatibility first. LangChain, OpenAI Agents SDK, ADK, Microsoft Agent Framework, Strands, and Pydantic AI can connect to several providers, leaving the existing task state and much of the loop in place. “Wait for approval before refunding” remains a business rule. The adaptation work concerns how requests reach the new model and how the program reads its results. Tool argument formats, structured outputs, streaming events, stop reasons, and platform-provided tools can change. I retain the same business-tool contract and adapt and regression-test the new model integration.

Then look at the runtime platform. AgentCore Harness can switch among Bedrock, OpenAI, Gemini, and LiteLLM-compatible models within the same AWS harness. That provides model choice, while AWS still handles sessions, isolation, identity, tool entry points, and execution records. Claude Managed Agents, OpenAI Agents API, Gemini Enterprise Agent Platform, and Foundry Agent Service likewise retain their own platform state. A migration must cover history, state reconstruction, environments, credentials, audit records, and deployment entry points. Switching models and moving the entire runtime are separate decisions. The first depends on adapting model interfaces; the second also depends on moving history and unfinished tasks.

With those migration costs in view, I will give the same refund to different options and see which steps each takes over.

Put the Duplicate Charge from Chapter 1 Through Each Option

If I use Responses API or Messages API with a base model and custom business tools, the model can read descriptions and propose a refund-tool call. My application handles the loop, approval storage, and recovery after timeouts. Gemini Interactions API can also store conversation state on the server, run in the background, and call Google's specialist agents. Order policies, payment tools, and business outcomes still connect back to my system.

If I first need a standard agent loop, the choice follows the team's existing systems. Claude Agent SDK fits tasks that read and write files or execute commands. A team already using OpenAI APIs can let OpenAI Agents SDK handle multi-turn execution, hand off work, and check inputs and outputs around the run. A Python team can use Pydantic AI to validate the refund intent first. ADK, Microsoft Agent Framework, and Strands connect naturally to the clouds and programming languages their teams already know.

When this refund requires a fixed sequence, I write it as “collect evidence → propose a specific refund amount → wait for approval → execute → verify the refund ID.” LangGraph makes that sequence explicit. A persistent state store saves progress under the same thread_id, the identifier used to find the same workflow record. The approval node is the step that waits for and processes approval. When the manager approves, the program re-enters that node to handle the result, then moves to a separate payment node. Payment calls keep the same action ID and idempotency key. LangGraph preserves where the program has reached; the payment system confirms whether the refund actually occurred.

The LangChain stack has three levels. LangGraph controls complex state and defined steps. LangChain provides the standard loop. Deep Agents adds planning, file-based context, long tasks, and subagents. Enter through LangGraph when you want to specify steps and transitions, LangChain when a standard loop is enough, and Deep Agents when you want planning, file, and subagent capabilities already assembled. LangSmith can record model and tool calls alongside them, then use past failures to check whether a new version has regressed.

When a task must wait across services for days, I add Temporal, Restate, or DBOS. They preserve approvals, timed waits, and recovery positions. Stable action IDs, the effect ledger, and the payment service jointly establish whether the same refund has executed twice.

If the team also wants to hand over sessions, loops, isolated environments, and scaling, it can choose a managed platform. Claude Managed Agents and OpenAI Agents API host the harness. AgentCore Harness provides a configuration-driven harness; AgentCore Runtime hosts the team's own agent code. Foundry and Gemini Enterprise Agent Platform also connect cloud identity, tool entry points, and runtime records to the call path.

Why 2026 Lets Us Write Less Integration Code

This year's changes fall into three areas. First, managed products explicitly take over the harness rather than supplying only a model. Claude Managed Agents and OpenAI Agents API have entered public availability stages, AgentCore Harness is generally available, and Foundry and Gemini Enterprise Agent Platform bring execution, identity, and tool entry points into the same product surface.

Second, custom agents can gain durable execution more easily. Pydantic AI and Restate provided direct integration in May. Temporal's October 2026 Product Edition lists agent integrations with ADK, OpenAI Agents SDK, Strands, and LangGraph as generally available. The integration code saved here connects agent steps to stored progress, waiting notifications, and recovery. With less of that wiring to write, teams can focus on approval, idempotency, and authoritative result verification.

The third area is connection: an agent needs a way to call an external tool or assign work to another agent. A2A 1.0, released on March 12, 2026, exchanges tasks and artifacts between independent agent systems. The MCP 2026-07-28 core specification gives tool requests explicit versions, identity, and capabilities. The MCP Tasks extension, still a draft as of November 8, 2026, expresses status queries, cancellation, and waits for input for a single long-running tool call. With ready-made choices for tools, execution, and connections, I can assemble several clear starting points.

Four Combinations You Can Start With

Combination 1: A Minimal Self-Hosted Agent

I start by connecting LangChain to a model API and the company's tool entry point. When a user reports a duplicate charge, LangChain lets the model organize the refund intent—the order, amount, and reason—then call the order-lookup and refund-request tools. The tool entry point checks whether the user may refund that order, and the payment service uses the same action ID to prevent a duplicate refund. LangSmith connects model and tool records for investigation. This combination retains room for custom development and suits a team that already has backend, permissions, and logging systems and wants to get the agent loop running quickly.

Combination 2: Make the Refund Steps Explicit

When the model must not improvise the refund order, I use LangGraph to define five nodes: look up the order, propose the amount, wait for manager approval, execute the refund, and verify the result. The persistent state store writes the current node and task data to reliable storage, so the process can exit without losing its position. If the manager approves the next day, the program reruns the paused approval node. I therefore keep payment in a separate node after approval and use the same idempotency key throughout. The company's tool entry point enforces permissions, the effect ledger records the action, and the payment service supplies the final result. This combination suits finance, procurement, and compliance tasks with fixed steps, pause/resume requirements, and complete audit trails.

Combination 3: Validate Data, Then Run Long Tasks Reliably

I use Pydantic AI to define the refund intent with three fields: order, amount, and reason. Missing fields or wrong types stop the flow before invalid arguments reach the payment system. If an amount should be a number but the model returns an explanation, the program asks it to correct the output. Once the amount is correctly formatted, company permissions and business rules still decide whether the refund is allowed. Restate or Temporal saves the model's recorded decisions, pending approvals, and completed steps. After a restart, execution continues from the last reliable point instead of guessing the amount again. Once approval arrives, the call still passes through the company tool entry point, and the payment service returns the final refund result. This combination suits Python teams and tasks that wait across days or span several services.

Combination 4: A Managed Harness with Enterprise Controls

When the team does not want to maintain agent processes, session storage, isolated environments, and scaling, I choose a managed platform from Claude Managed Agents, OpenAI Agents API, AgentCore Harness, Gemini Enterprise Agent Platform, or Foundry Agent Service. The platform runs the agent. Existing company systems still handle four responsibilities: identify the user, decide whether the refund is allowed, execute the payment call, and query the payment system for the final refund ID. This suits a team that has chosen its cloud and wants to hand over runtime infrastructure. The choice must include both model binding and platform migration costs.

Whichever combination I choose, I run the duplicate charge from Chapter 1 through the whole system. Does approval apply only to this specific refund amount? Does a restart reload the same intent? Does a payment timeout retain the same action ID? Do both the company tool entry point and payment service check permissions? Can the verifier retrieve one refund ID? Can the call records connect the entire process?

With a framework that supports several providers, I also give at least two models the same task contract and tool-input format, then compare valid refund intents, human interventions, latency, and total cost. This tests the behavior of the whole agent after a model change, rather than one isolated answer.

Across these ten chapters, we started with a minimal loop and added completion criteria, context, tool boundaries, recovery, permissions, evaluation, and multi-agent collaboration. The product directory now has a purpose for every name: what it takes over, what it leaves to us, and where to investigate when something fails.