"OpenAI vs Claude Harnesses (3/3) — The Difference in Operating Philosophy"

If you compare OpenAI and Claude by model scorecards first, you can miss the more important difference. In real agent work, the bigger split is often not model IQ but where the harness actually lives. OpenAI leans toward assembling a runtime from APIs, tools, MCP, and SDK layers. Claude Code leans more toward organizing a working environment through CLAUDE.md, skills, hooks, permissions, and subagents. Both build agents. The floor they stand on is different.

Key Takeaways

  • OpenAI harnesses are fundamentally platform-assembly oriented. You combine Responses API, tools, function calling, remote MCP, and the Agents SDK into your own runtime.
  • Claude harnesses feel more workspace-operations oriented. CLAUDE.md, skills, hooks, permissions, and subagents shape how the agent behaves inside a working environment.
  • So the main OpenAI question is often "Which runtime responsibilities belong in which layer?" while the Claude question is closer to "Which rules and boundaries should be enforced at which layer?"
  • This is not a winner-versus-loser distinction. OpenAI often feels natural for product-facing agent backends. Claude often feels natural for repo-native, long-running, workspace-heavy agent operations.
  • The point of this comparison is not generic model performance. It is operating philosophy.

1. Same agent category, different starting point

Taken together, Part 1 and Part 2 show that the two ecosystems start from slightly different questions.

OpenAI surfaces usually read like this:

  • how to generate and continue responses
  • which tools to expose
  • how to connect tool loops and conversation state
  • where to place handoffs, tracing, and guardrails

Claude Code surfaces usually read more like this:

  • how the agent should behave in this project
  • which repeated procedures belong in skills
  • which checks should be automated with hooks
  • which actions should be allowed, questioned, or denied

So while both are agent systems, the feel is different:

  • OpenAI: assemble an agent runtime
  • Claude: operate an agent workspace

2. OpenAI has a stronger runtime-centered philosophy

The OpenAI surface today is strongly shaped around Responses API, tools, remote MCP, the Agents SDK, and tracing. That is powerful, but it also asks a clear question:

What kind of runtime are you trying to build?

With OpenAI, you usually decide things like:

  • which tools should be exposed for which request
  • how your function schemas define operational boundaries
  • how much state should stay in the API versus external artifacts
  • when orchestration deserves an SDK layer
  • where evaluation and observability should live

This fits naturally when you are building an agent backend inside a product. OpenAI gives you strong runtime parts, but much of the "how should this agent live in our environment?" question still belongs to your own harness design.

3. Claude has a stronger work-environment philosophy

Claude Code starts closer to the idea of an agent that already reads files, edits code, runs commands, and works inside a real repository. Because of that, its surfaces are developed more around work rules and environment boundaries.

The major layers are usually:

  • CLAUDE.md: identity, hard rules, read-first guidance
  • skills: reusable procedures
  • hooks: automatic checkpoints before or after actions
  • permissions/settings: access boundaries and safety policy
  • subagents: role isolation and delegation

So the Claude question becomes:

How should this agent behave inside this workspace?

That is especially direct for local repos, internal docs, operational folders, and long-running handoff-heavy work.

4. The main difference is not intelligence but the floor beneath it

This table is the most practical way to summarize the split.

Comparison axis OpenAI tendency Claude tendency
Core philosophy platform assembly workspace operations
Main question what runtime should we build how should the agent work here
Strong surfaces API, tools, MCP, SDK, tracing instruction files, skills, hooks, permissions
Developer role runtime architect work-rules designer
Natural environment product backends, embedded agents local repos, team workspaces, coding agents
Common failure mode messy orchestration and state bloated instruction files, weak rule separation

This is why harness quality can diverge even when model capability looks similar on paper. The operating floor is different.

5. The document philosophy differs too

In OpenAI-style harnesses, documentation often behaves like:

  • API usage rules
  • tool-schema design notes
  • orchestration design docs
  • tracing and eval plans

That is, documentation often works like an assembly blueprint.

In Claude-style harnesses, documents more directly shape agent behavior:

  • CLAUDE.md
  • skill documents
  • hook settings
  • permission policies
  • handoff artifacts

So documents are not only blueprints. They are also live behavior surfaces.

That difference matters in practice. OpenAI often feels like reading system design and writing runtime code. Claude often feels like structuring the workspace so the agent can work safely and consistently inside it.

6. Safety emphasis lands in different places

Both ecosystems care about safety and guardrails, but the operational center of gravity differs.

OpenAI tends to focus on:

  • tool exposure
  • schema constraints
  • guardrails
  • tracing and evals
  • app-level approval flows

Claude tends to surface:

  • permissions.allow/ask/deny
  • sensitive path blocking
  • hook-based pre/post checks
  • subagent role separation
  • workspace boundary configuration

Put simply, OpenAI often feels stronger at controlling the surface of capability, while Claude feels stronger at controlling the surface of workspace access.

7. Context philosophy is also different

In OpenAI harnesses, context often feels like a runtime assembly problem:

  • what to include in the request
  • when to trigger search
  • whether to keep state in response chains or external artifacts
  • how to summarize tool output

In Claude harnesses, context is more tightly coupled to project structure:

  • which CLAUDE.md files are loaded
  • which skill is invoked
  • which handoff artifact starts the next session
  • which directory rules govern the current task

So OpenAI often treats context as a request/run composition problem, while Claude often treats it as a workspace and session structure problem.

8. When each philosophy feels natural

OpenAI often feels more natural when

  • you are building an agent backend inside a product
  • you want to assemble APIs, tools, MCP, tracing, and orchestration in code
  • you want model routing and control flow inside your service
  • the runtime matters more than the local workspace

Claude often feels more natural when

  • the agent is already operating directly in a repo or document workspace
  • team rules, path constraints, handoffs, and approval flow matter heavily
  • you want to separate instruction, procedure, automation, and permissions cleanly
  • the main problem is not "how do we build it" but "how do we make it work safely here"

Not absolute. But this is usually the least confusing way to choose.

9. Common misunderstandings

"OpenAI is just an API, so its harness story is weaker"

Not really. Its runtime flexibility is often stronger. What it does less directly is define your workspace discipline for you.

"Claude is a coding tool, so it is less relevant for broader agent systems"

Also too simplistic. Claude-side patterns like MCP, subagents, permissions, and long-running workflows can support much broader operations. The default feel is simply more workspace-native.

"Model quality decides everything anyway"

Only partly. In practice, tool surfaces, permission boundaries, evaluation loops, and instruction architecture often matter more than people expect.

10. Conclusion: match the operating philosophy before you compare the model

OpenAI and Claude are both central choices in the agent era. But the most important difference for harness engineering sits below feature checklists.

  • OpenAI pushes you toward building an agent runtime
  • Claude pushes you toward operating an agent workspace

So the better first question is not "Which model is better?" but:

  • am I assembling a runtime inside a product
  • or shaping a working environment where an agent can operate safely

That is a more durable comparison frame than benchmark tables alone. In many teams, the answer is both: OpenAI for service runtime, Claude-like tools for internal workspace operations.

The simplest conclusion is this:

Before comparing models, decide whether your main problem is runtime assembly or workspace operations.

References

  • OpenAI Docs, Responses
    https://platform.openai.com/docs/api-reference/responses?api-mode=responses
  • OpenAI Docs, Using tools
    https://platform.openai.com/docs/guides/tools?api-mode=responses
  • OpenAI Docs, Agents SDK
    https://platform.openai.com/docs/guides/agents-sdk/
  • Anthropic Docs, Claude Code settings
    https://docs.anthropic.com/en/docs/claude-code/settings
  • Anthropic Docs, Hooks reference
    https://docs.anthropic.com/en/docs/claude-code/hooks
  • Anthropic Docs, Subagents
    https://docs.anthropic.com/en/docs/claude-code/sub-agents
  • drafts/blog/260519_OpenAIํ•˜๋„ค์ŠคB01_ResponsesAPI์™€AgentsSDK_๋ธ”๋กœ๊ทธ.md
  • drafts/blog/260519_Claudeํ•˜๋„ค์ŠคB02_CLAUDEmd_Skills_Hooks_Permissions_๋ธ”๋กœ๊ทธ.md
  • docs/blog_series_ํ•˜๋„ค์Šค์—”์ง€๋‹ˆ์–ด๋ง_์ด๊ด„_design.md
  • sources/260518_ํ•˜๋„ค์Šค์—”์ง€๋‹ˆ์–ด๋ง_15์žฅ_๋ธ”๋กœ๊ทธํ™œ์šฉ๋…ธํŠธ.md

This post is Part 3 of 3 in the OpenAI and Claude Harnesses series. Next reading: evaluation harnesses, long-running agents, and Harness Is Everything.

Series overview: Harness Engineering Series Guide

๋Œ“๊ธ€

๋Œ“๊ธ€ ์“ฐ๊ธฐ

์ด ๋ธ”๋กœ๊ทธ์˜ ์ธ๊ธฐ ๊ฒŒ์‹œ๋ฌผ

Agent Memory Engine (2/10) — Building an AI Agent Memory System with SQLite Alone

← 1/10 SQLite Memory Engine f… ๐Ÿ“š Series Index 3/10 memcore Completed → A memory engine that runs without daemons, without dependencies, anywhere ํ•ต์‹ฌ ์š”์•ฝ This post covers how to design an AI agent memory engine (memcore) on a single-file SQLite backend. - Structure: 25 modules, ~6,464 lines, 22 DB tables - Principles: no daemon, single-file portability, no required external dependencies, host-agnostic - Core techniques: 4-layer hybrid search (topic · vector · FTS5 · LIKE), U-tag dialectic-based confidence evolution, ingestion-layer bias rejection rules What This Post Covers One approach to building AI agent memory without a server or cloud vector DB. Specifically: (1) the limitations of text-file-based memory, (2) vector DB alternatives compared and selection criteria, (3) how to layer search tiers, (4) how to evolve confidence scores over time, and (5) how to block biased memory accumulation at the ingestion stage. Design Principles: Why Single-File SQLite Text-file-based ...
Read more »

"ML Foundations (9/9) — PyTorch vs TensorFlow, and the Road to Local LLMs"

์ด๋ฏธ์ง€
← 8/9 Deep Learning Architec… ๐Ÿ“š Series Index (series end) The final part. So far we've focused on models. Now we focus on the tools that actually run them . We'll lay out the philosophical difference between PyTorch and TensorFlow, and trace how Hugging Face transformers , llama.cpp , MLX , and Ollama built the bridge to running large language models on your own machine. By the end you should have the full mental model of "download a pretrained LLM and serve it locally." 0. Learning Objectives Explain the eager-vs-graph difference between PyTorch and TensorFlow. Explain, in graph terms, how autograd automates the backward pass. Use Hugging Face transformers ' AutoModel , AutoTokenizer , and pipeline abstractions. Describe llama.cpp's GGUF quantization, INT4 inference, and CPU-first flow. Describe Apple MLX's use of unified memory and how it differs from PyTorch. Run a local LLM with Ollama and call it through an OpenAI-compatible API. ...
Read more »

"RAG Core Study (14/26) — Evaluation Sets with RAGAS & DeepEval"

์ด๋ฏธ์ง€
Series overview: Series index ๐Ÿ“š Series Index Without an evaluation set, every RAG improvement is a story, not evidence. RAG systems fail in more than one place: retrieval, context selection, answer generation, and grounding. That means "looks better" is not a metric. Part 14 explains how to build a golden dataset , how RAGAS and DeepEval fit into the workflow, and why teams must separate retrieval quality from answer quality if they want tuning decisions to hold up. 0. Prerequisites Part 13 reranking — system quality now depends on multi-stage ranking. Part 1 grounding — a correct-looking answer is not enough. Part 12 Hybrid — multiple retrieval settings need comparison on fixed data. 1. Learning Objectives Build a small but useful golden dataset for RAG. Distinguish retrieval metrics from answer metrics . Use RAGAS and DeepEval in the right roles. Avoid the common traps in judge-model-based evaluation. 2. ํ•ต์‹ฌ ์š”์•ฝ An evaluation set for RAG is ...
Read more »

"ML Foundations (8/9) — Deep Learning Architectures: CNN, RNN, Attention"

์ด๋ฏธ์ง€
← 7/9 Deep Learning Training ๐Ÿ“š Series Index 9/9 PyTorch vs TensorFlow → What did we keep adding on top of an MLP? Vision went CNN, sequences went RNN/LSTM, and eventually both converged on Attention and the Transformer. Each architecture is easier to remember if you read it as what it gave up to gain something else . This part is the one-line summary of the decisive inflection points: LeNet → AlexNet → ResNet → LSTM → Attention → Transformer. 0. Learning Objectives Explain why CNN's convolution, pooling, and weight sharing match images so well. Trace what got unblocked from LeNet → AlexNet → VGG → ResNet as depth grew. State BPTT for RNNs and the vanishing/exploding gradient problem. Write the LSTM gate equations (forget, input, output) with intuition. Write the attention formula in query/key/value form and the scaled dot-product variant. State the precise reasons Transformers replaced RNNs (parallelism + long-range dependencies). 1. ํ•ต์‹ฌ ์š”์•ฝ CNN : weight sharin...
Read more »

"ML Foundations (7/9) — Deep Learning Training: Optimizers, Regularization, Initialization"

← 6/9 Neural Networks ๐Ÿ“š Series Index 8/9 Deep Learning Architec… → Building an MLP, as we did in Part 6, is not the same as getting it to train well . The right optimizer, regularization, initialization, and learning rate — when these line up, deep networks converge. When they don't, the network refuses to learn at all. This part is the catalog of those crafts, with formulas, paper citations, and code in one place. 0. Learning Objectives Compare and write the update rules for SGD, Momentum, Nesterov, and Adam. Explain how Dropout, BatchNorm, and LayerNorm work and where they belong in a model. Derive the variance formulas for Xavier and He initialization and match them to activations. Implement step, cosine, and warmup learning-rate schedules in PyTorch. Explain why gradient clipping is effectively required for RNNs and Transformers. Diagnose the most common training failures (NaN, plateau, overfitting) and apply first-line fixes. 1. ํ•ต์‹ฌ ์š”์•ฝ SGD : \(w \leftarro...
Read more »

OpenClaw to Hermes Migration (2/13) — What to Preserve, Partially Port, or Discard

← 1/13 Current Structure Inve… ๐Ÿ“š Series Index 3/13 What Moves to Hermes → A code review record classifying operational scripts into three tiers: preserve, partial-preserve, and discard. What This Post Covers An asset classification framework (preserve / partial-preserve / discard) for migrating a legacy agent system to a successor A concrete case applying the Strangler Fig + Subset Migration strategy to a memory pipeline Classification results evaluated across LOC, external dependencies, and replaceability axes A method for slimming down a bloated single file (1,310 LOC) using the migration as a natural entry point Problem Definition: Port Everything or Cut Deep? The OpenClaw inventory comprises multiple agents, multiple scheduler/daemon processes, and multiple operational scripts. When moving to the successor system, Hermes, the choice is not binary. A full port carries accumulated technical debt along with it; a minimal port discards hard-won domain logic. Code-revie...
Read more »

AI Agents I Built (5/7) — Building an Automated Blogger API Publishing System

← 4/7 My Life Organizer Agent ๐Ÿ“š Series Index 6/7 Dual → Designing a Markdown-Based Auto-Publish Pipeline with Blogger API v3 + OAuth 2.0 Key Summary Blogger API v3 + OAuth 2.0 enables a pipeline that converts Markdown files into publishable HTML posts blogger_publish.py handles the full flow — frontmatter parsing → body cleanup → HTML conversion → CSS injection → API post — in a single script For bulk publishing, quota management (delay, retry, TOC suppression) is the critical design concern Platform Selection Criteria API access is mandatory for AI agent-driven content publishing. A comparison of platforms: Platform API Cost AdSense Decision WordPress.com REST API Paid plan required Paid only Cost overhead Ghost REST API Self-hosted or paid Manual setup Ops overhead Blogger v3 API Free Native integration Adopted Blogger is free, exposes a REST API, and integrates natively with AdSense. For personal blog automation, this combination i...
Read more »