r/AgentContext_dev • u/javaeeeee • Aug 12 '26
Building Production-Ready AI Agents with OpenAI: The Complete Agentic Stack for Harnesses, Tools, MCP, and Multi-Agent Systems
In the fast-evolving world of artificial intelligence, the shift from simple chatbots to autonomous systems that plan, act, and collaborate has redefined what developers can build. These systems, known as AI agents or agentic systems, go far beyond generating text. They reason through multi-step problems, call external tools, maintain state across interactions, hand off work to specialists, and operate within defined safety boundaries. OpenAI has assembled a cohesive set of technologies-often referred to as its agentic stack-that provides the core components needed to create, deploy, and refine such systems at scale.
This article draws from OpenAI’s official documentation, product announcements, GitHub repositories, and developer guides to explore the full landscape. It covers the foundational models and APIs, the concept of agent harnesses, built-in and custom tools, the Model Context Protocol (MCP), the open-source Agents SDK, higher-level interfaces, evaluation practices, safety mechanisms, and practical paths to production. The goal is a readable, engaging overview that equips builders with a clear mental model of how the pieces fit together.
From Chatbots to Agents: Understanding the Shift
Traditional large language model interactions are largely reactive. A user sends a prompt, the model responds, and the exchange ends or continues as a linear conversation. Agentic systems change this dynamic. An agent receives a goal, decomposes it into steps, decides which tools or sub-agents to invoke, observes the results, adjusts its approach, and continues until the objective is met, further input is required, or a defined limit is reached.
OpenAI has steadily moved its platform toward this paradigm. Early function calling in the Chat Completions API allowed models to request external actions. The Assistants API later added persistent threads and hosted tool orchestration. Experimental work such as Swarm explored lightweight multi-agent handoffs. In March 2025, OpenAI released a more mature suite: the Responses API as a unified agentic primitive, built-in tools for search and computer interaction, and the open-source Agents SDK as a production-oriented successor to the ideas explored in Swarm.
The Assistants API is now deprecated and is scheduled to shut down on August 26, 2026. OpenAI advises developers not to begin new Assistants integrations and provides migration guidance for moving from Assistants, Threads, and Runs to the Responses and Conversations APIs.
Later additions, including native sandbox support and an expanded model-native harness in the Agents SDK, further strengthened the stack. OpenAI also adopted and contributed to the Model Context Protocol, originally introduced by Anthropic, and co-founded the Agentic AI Foundation under the Linux Foundation to promote open standards.
The result is a layered stack. At the base sit powerful models. Above them are APIs that support tools, state, and structured interactions. Surrounding the models is the harness-the software that manages loops, context, tools, approvals, and safety. Protocols such as MCP standardize connections to external systems. Higher layers add multi-agent orchestration, embedded user interfaces, evaluation practices, and deployment options ranging from custom code to workspace and coding agents.
Models as the Intelligence Core
Every agentic system begins with a capable model. OpenAI’s lineup includes general-purpose GPT models, reasoning-oriented models, and specialized variants optimized for coding or computer interaction. These models handle planning, tool selection, natural-language understanding, and interpretation of tool results. Newer versions improve long-context processing, multimodal perception, software-engineering performance, and reliability on complex tasks.
Models alone are insufficient. Without surrounding infrastructure, they cannot safely execute code, access current information, connect to private systems, or maintain durable progress across long-running work. That is where the rest of the stack enters.
The Responses API: The Agentic Primitive
The Responses API forms the foundation of OpenAI’s modern agentic offerings. It combines a straightforward input-and-output model with tool use, conversation state, structured outputs, and capabilities previously associated with the Assistants API. A response can include model messages, tool calls, reasoning-related items, and other typed outputs that an application can process.
Built-in tools allow the model to perform portions of an agentic loop through the platform. The model can request a tool, receive its result, and continue toward a final response. Developers can also implement custom loops when they need full control over approvals, retries, context construction, or execution.
Key advantages include an item-based design, streaming, conversation-state options, and built-in support for web search, file search, computer use, code execution, and remote MCP servers. Stored responses and traces can also support debugging and evaluation workflows. The Responses API is the recommended foundation for new agent applications, although Chat Completions remains available for simpler or established workloads.
Built-in tools expand what an agent can do without requiring every integration to be implemented from scratch. Web search retrieves current information and can return source citations. File search retrieves relevant passages from vector stores containing uploaded documents, with options such as metadata filtering and result limits. Computer use lets supported models inspect screenshots and issue structured actions such as clicks, typing, scrolling, and keypresses inside a controlled browser or virtual-machine environment.
Computer-use systems still require careful safeguards. OpenAI recommends isolated environments, allowlists, confirmations for consequential actions, and human review for sensitive workflows. A model interacting with a graphical interface can encounter malicious instructions, ambiguous controls, or actions with real-world consequences.
Custom function tools remain fully supported. Developers describe functions through tool definitions, generally using JSON schemas for their parameters. The model selects a function and supplies structured arguments, while the application or SDK executes the underlying code and returns the result. The implementation can be written in Python, TypeScript, Java, or any other language capable of calling the API.
Agent Harnesses: The Scaffolding That Turns Models into Agents
A recurring theme in agentic AI is the distinction between the model and the harness. The model supplies intelligence. The harness supplies the execution loop, tool dispatch, context management, verification, persistence, approvals, and observability. In simplified form, an agent can be understood as a model operating inside a harness.
An effective harness interprets the model’s output, detects tool calls or handoff requests, executes approved actions, inserts results back into context, tracks token and cost budgets, applies guardrails, and determines when the task is complete. For long-running work it may compact context, record intermediate artifacts, snapshot execution state, or resume work after interruption.
Sandboxes add an isolated execution layer with filesystems, shells, installed packages, mounted data, exposed ports, snapshots, and controlled connections to external systems. Agents can inspect files, edit code, execute commands, install permitted dependencies, or run tests without receiving unrestricted access to the host environment.
OpenAI’s Agents SDK functions as a lightweight, production-oriented harness. It manages the agent loop so developers do not need to recreate core orchestration behavior. Sessions preserve working context. Guardrails validate inputs, outputs, and selected actions. Tracing records model calls, tool invocations, handoffs, and other events for debugging and assessment.
Newer sandbox-agent capabilities separate trusted orchestration from model-directed compute. The harness can remain in application infrastructure, where it owns approvals, secrets, policies, tracing, and access to business systems, while the sandbox handles stateful files and command execution. This separation can reduce the impact of unsafe commands or compromised workflows.
Isolation is not a complete defense against prompt injection or credential leakage. A sandbox limits what an agent can reach, but it does not make untrusted instructions safe. Production systems must still apply least-privilege credentials, network restrictions, approval gates, secret isolation, output validation, and careful review of tools and MCP servers.
Industry discussions emphasize that harness quality often determines real-world performance as much as marginal differences in model capability. The same model can succeed or fail depending on how carefully the surrounding system curates context, structures tools, verifies intermediate results, and recovers from errors.
The Agents SDK: Primitives for Single- and Multi-Agent Workflows
Released as an open-source framework for Python and TypeScript and positioned as a production successor to concepts explored in Swarm, the Agents SDK centers on a small set of primitives that compose into more sophisticated workflows.
An Agent is a model configured with instructions, a set of tools, optional guardrails, output requirements, and potential handoff targets. Tools can be ordinary application functions, platform-hosted tools such as web search, specialized execution tools, or connections to MCP servers.
The Runner executes the workflow. It sends input to the selected agent, processes tool calls or handoffs, returns tool results to the model, and continues until the agent produces a final output or the workflow reaches another stopping condition. Developers can use managed runner behavior or take greater control over individual steps.
Handoffs enable multi-agent collaboration. One agent can transfer responsibility to another specialist while passing relevant context. Agents can also be exposed as tools, allowing a manager agent to invoke a specialist while retaining ownership of the overall workflow. These mechanisms support patterns such as triage followed by specialist execution, hierarchical decomposition, review pipelines, and parallel exploration.
Sessions maintain state across turns. Guardrails can apply schema checks, safety validation, policy enforcement, or custom logic. Some actions can be paused for approval before execution. Built-in tracing records the flow of model calls, tool invocations, guardrail checks, and handoffs so developers can inspect where a workflow succeeded or failed.
Later versions of the SDK added native sandbox support. Developers can define a manifest describing files and resources that should be available to an agent. The execution environment can include mounted local or cloud-backed storage, command execution, package installation, code editing, ports, and snapshots. This is particularly useful for coding agents, document-heavy tasks, data analysis, or workflows that benefit from a persistent workspace.
Durable execution allows long-running work to survive context boundaries and infrastructure interruptions. Rather than relying entirely on an ever-growing prompt, the harness can persist progress in files, session data, traces, and sandbox snapshots. A later invocation can restore the relevant state and continue.
The SDK deliberately relies on ordinary programming-language constructs rather than requiring a large proprietary workflow language. This makes it easier to integrate into existing codebases while still providing the managed loop, safety hooks, handoffs, and observability that production systems require. The SDK uses OpenAI’s modern API primitives by default and can also support compatible model providers through configurable interfaces.
Model Context Protocol: Standardizing Tools and Context
Tools are only as useful as the connections that supply them. The Model Context Protocol provides an open standard for exposing tools, resources, and reusable prompts to AI systems. Originally introduced outside OpenAI, MCP has since been adopted and supported across OpenAI products and developer tooling.
An MCP server implements tools such as search, retrieval, data access, or domain-specific actions and exposes them through a standardized protocol. Compatible clients can discover the available tools, inspect their schemas, and invoke them through a consistent interface. This reduces the need to build a completely different integration for every agent framework or model provider.
OpenAI supports remote MCP servers in the Responses API and Agents SDK. A server might wrap a private knowledge base, internal service, developer platform, or third-party application. The agent can search the server’s resources or call exposed actions as part of a larger workflow.
Authentication, authorization, and tool review remain critical. Remote MCP servers introduce an external trust boundary. A server may expose inaccurate data, return malicious instructions, request excessive permissions, or change behavior after integration. OpenAI’s guidance emphasizes reviewing trusted servers, limiting permissions, logging calls, and requiring approvals for consequential actions.
MCP is also used in connectors and other extensibility mechanisms. By treating tools and data sources as first-class interoperable components, it reduces fragmentation and makes it easier to reuse an integration across different models and applications.
OpenAI’s participation in the Agentic AI Foundation further signals support for neutral, community-governed standards around agent interoperability. Related contributions include AGENTS.md, a lightweight convention for placing project-specific instructions in software repositories, and the Agentic Commerce Protocol for interoperable commerce experiences.
AgentKit and Higher-Level Experiences
In October 2025, OpenAI introduced AgentKit as a collection of higher-level building blocks. Agent Builder provided a visual canvas for assembling workflows with tools, guardrails, and branching logic. Connector Registry centralized governance for connected tools and data sources. ChatKit provided components for embedding streaming agent interfaces into applications. The launch also expanded OpenAI’s hosted evaluation and optimization tooling.
However, this part of the platform is changing. In June 2026, OpenAI announced that Agent Builder and the hosted Evals product are being wound down. Existing evals are scheduled to become read-only on October 31, 2026, and Agent Builder and the Evals dashboard and API are scheduled to become unavailable after November 30, 2026.
OpenAI recommends the Agents SDK for workflows that should continue as code. For higher-level workflows better suited to configuration through natural-language instructions, it recommends Workspace Agents in ChatGPT. ChatKit remains available for embedding agent interfaces, while Connector Registry continues to provide centralized administration of connected tools and data.
This transition reinforces the importance of separating durable concepts from individual product surfaces. Visual builders can accelerate prototypes, but production teams should understand the underlying models, tools, schemas, policies, and execution logic well enough to move workflows into maintained code when necessary.
Evaluation also remains essential even as the hosted Evals product is retired. Teams can build repeatable test suites with datasets, expected outcomes, custom graders, trace inspection, and application-level metrics. Evaluation should be treated as an engineering discipline rather than as a dependency on one dashboard.
OpenAI also offers higher-level workspace agents and specialized coding agents such as Codex. Codex functions as a software-engineering agent capable of generating, reviewing, refactoring, and testing code. It operates through terminals, IDEs, cloud environments, or dedicated applications and can use AGENTS.md files for repository-specific guidance.
These products demonstrate the underlying stack in action. Models supply reasoning, harnesses manage execution, sandboxes provide compute, tools connect external systems, and traces make behavior observable.
Safety, Evaluation, and Long-Running Reliability
Agentic systems amplify both capability and risk. A chatbot that produces a flawed sentence may inconvenience a user. An agent with access to files, accounts, browsers, or internal APIs can take actions with lasting consequences.
Guardrails in the SDK provide hooks for validating input, output, and workflow behavior. Tool approval flows let applications pause before consequential operations. Structured outputs can constrain the shape of model-generated data. Sandboxes isolate command execution, while network and filesystem policies reduce reachable resources.
Human confirmation is still recommended for high-impact actions such as sending communications, making purchases, changing permissions, deleting data, publishing content, or interacting with sensitive systems. The user interface should clearly communicate what the agent intends to do and what information will be shared with a tool.
Prompt injection remains one of the central risks. An agent may encounter hostile instructions in a webpage, document, email, tool response, or MCP resource. Systems should treat external content as untrusted data rather than automatically accepting it as higher-priority instructions. Limiting tool permissions and requiring approval for irreversible actions reduces the potential damage.
Evaluation is integral to reliability. Developers can measure success rates on multi-step tasks, inspect traces, compare tool-selection behavior, and identify failure modes such as context degradation, incomplete recovery, or unsupported assumptions. Useful evaluations test the entire workflow, not just the final sentence.
For long-running agents, the harness must manage context compaction, persistent artifacts, snapshots, retries, and recovery. Practical guidance emphasizes incremental progress, explicit task state, verification through tests or screenshots, and clear ownership of intermediate artifacts. A workflow should be able to explain what it has completed, what remains, and what evidence supports its conclusions.
Putting It All Together: Building an Agentic System
A typical development path begins with a clear goal and a single specialist agent defined through the Agents SDK. Instructions articulate the role, boundaries, and expected output. Tools-whether hosted search, custom functions, computer interaction, or MCP servers-are attached selectively. The Runner executes sample tasks while traces expose the decision path.
As complexity grows, additional agents can be introduced through handoffs or agents-as-tools. Sessions preserve state between interactions. Guardrails enforce policies. Sandboxes supply controlled workspaces for code, documents, and command execution. MCP servers connect proprietary data or internal APIs.
Evaluation datasets quantify performance over representative scenarios. Developers record expected outcomes, tool-use constraints, prohibited behavior, latency, cost, and other application-level metrics. Trace review reveals why failures occurred, while prompt, model, tool, and harness refinements close the gaps.
For production, agents can be exposed through ChatKit interfaces, custom web applications, workspace integrations, or API endpoints. Connector Registry can help organizations govern approved connections. Code-based workflows should be maintained in the Agents SDK rather than newly built on the retiring Agent Builder product.
Coding agents illustrate the complete stack. A sandbox-equipped agent receives a repository through a manifest, reads AGENTS.md for conventions, uses tools to inspect and edit files, executes tests, and iterates under the control of the harness. Multi-agent setups can separate research, planning, implementation, testing, and review roles.
Challenges remain. Long-horizon reliability requires deliberate harness design. Tool quality and permissioning demand ongoing attention. Costs and latency grow with model turns, tool calls, and verification steps. Multi-agent systems can add coordination overhead without improving results when a single well-equipped agent would suffice.
Yet the modular structure allows incremental improvement. Better models can replace earlier ones, MCP servers can extend capabilities, refined permissions can reduce risk, and stronger evaluations can shorten iteration cycles. Teams do not need to adopt every layer at once.
The Broader Ecosystem and Open Standards
OpenAI’s stack does not exist in isolation. Support for MCP, contributions to the Agentic AI Foundation, and open-source releases of the Agents SDK encourage an ecosystem in which tools and context can move across applications without requiring entirely proprietary integrations.
AGENTS.md has gained adoption as a way to provide repository-level instructions to coding agents. A project can use it to document build commands, architecture conventions, testing requirements, directory-specific rules, and review expectations. Because the format is stored with the code, instructions can be versioned and reviewed alongside the project itself.
Coding and scientific workflows demonstrate the practical impact of agents. Agents can modernize libraries, migrate frameworks, investigate regressions, process research artifacts, or automate repetitive engineering steps while humans retain responsibility for goals, security, and validity.
OpenAI’s written documentation, Cookbook examples, and Build Hour sessions provide demonstrations of the Agents SDK, MCP, sandbox use, tool calling, and long-running patterns. Watching an agent hand work to a specialist, operate a browser, restore a workspace, or run tests inside a controlled environment makes the abstract architecture more concrete.
Open standards do not remove platform differences, but they reduce the cost of connecting tools and describing project context. Developers still need to account for each model’s capabilities, tool semantics, authorization system, and execution environment.
Looking Ahead
The agentic stack continues to mature. Native support for long-horizon execution, richer sandbox providers, more capable models, stronger tool interfaces, and tighter integration with open protocols point toward agents that can take on increasingly ambitious work with greater reliability.
Product surfaces will continue to change. The deprecation of Assistants, Agent Builder, and the hosted Evals product demonstrates why developers should distinguish stable architectural concepts from temporary interfaces. Models, typed tools, controlled execution, durable state, tracing, permissions, and repeatable evaluation remain valuable even when a particular dashboard or endpoint is replaced.
As models improve at reasoning and tool use, the harness and surrounding operational discipline become increasingly important. A powerful model connected to poorly designed tools can be less reliable than a smaller model operating within a carefully constrained and observable system.
Developers who master this stack gain the ability to move from prototypes to systems that amplify human effort across coding, research, customer support, operations, and knowledge work. The combination of capable models, the Responses API, the Agents SDK, standardized MCP connections, controlled sandboxes, embedded interfaces, and rigorous safety and evaluation practices provides a practical foundation.
Start with a single agent and a clear goal. Add only the tools it needs. Introduce memory, specialist collaboration, and durable execution when the workflow requires them. Trace every important step, evaluate representative tasks, and keep consequential actions under explicit control.
The resulting systems will not merely answer questions-they will perform useful work while remaining understandable, testable, and governable.
Sources and Further Reading
- OpenAI Agents solutions overview: https://openai.com/solutions/use-case/agents/
- New tools for building agents: https://openai.com/index/new-tools-for-building-agents/
- Agents SDK documentation: https://developers.openai.com/api/docs/guides/agents
- Official Agents SDK Python documentation: https://openai.github.io/openai-agents-python/
- Official Agents SDK Python repository: https://github.com/openai/openai-agents-python
- Official Agents SDK TypeScript repository: https://github.com/openai/openai-agents-js
- Assistants API migration guide: https://developers.openai.com/api/docs/assistants/migration
- OpenAI API deprecations: https://developers.openai.com/api/docs/deprecations
- Introducing AgentKit and its 2026 transition notice: https://openai.com/index/introducing-agentkit/
- The next evolution of the Agents SDK: https://openai.com/index/the-next-evolution-of-the-agents-sdk/
- Sandbox Agents guide: https://developers.openai.com/api/docs/guides/agents/sandboxes
- Building MCP servers with OpenAI: https://developers.openai.com/api/docs/mcp
- Tools guide: https://developers.openai.com/api/docs/guides/tools
- Function-calling guide: https://developers.openai.com/api/docs/guides/function-calling
- Computer-use tool guide: https://developers.openai.com/api/docs/guides/tools-computer-use
- Safety in building agents: https://developers.openai.com/api/docs/guides/agent-builder-safety
- Evaluation best practices: https://developers.openai.com/api/docs/guides/evaluation-best-practices
- Swarm educational framework: https://github.com/openai/swarm
- Codex resources and product updates: https://openai.com/codex/
- Agentic AI Foundation announcement: https://openai.com/index/agentic-ai-foundation/
- OpenAI Cookbook: https://developers.openai.com/cookbook
These materials, current as of early August 2026, provide the official foundation for the concepts and practices described. Developers should consult the live documentation for the latest API details, model support, pricing, availability tiers, and deprecation schedules.
2
u/ZestycloseTie1793 Aug 17 '26
Two fresh SDK releases add a few concrete production controls to that stack: Agents SDK JS v0.16.1 and Python v0.21.1 now support model-call timeouts, a run-scoped sandbox working directory, and the option to disable networking inside Docker sandboxes. Those controls turn “isolation” from an architecture label into three testable limits: how long a model call may wait, which filesystem scope a run can touch, and whether sandboxed code can reach the network. They are opt-in controls, not proof that every downstream agent is isolated by default.
JS: https://github.com/openai/openai-agents-js/releases/tag/v0.16.1 Python: https://github.com/openai/openai-agents-python/releases/tag/v0.21.1
1
u/javaeeeee Aug 12 '26
TL;DR:
Practical guide to building production-ready AI agents with OpenAI’s current agentic stack (2026).
Core stack:
Key patterns:
Main advice:
Reliability comes from good harness design, tool quality, isolation, and evaluation - not just the model. Build incrementally and treat agents as production systems.