Beyond Agent Frameworks: The Emerging AI Harness Stack
Why LangChain, Strands, Pi, Omnigent and a new generation of agent infrastructure point to a shift in how we build AI systems
For the last few years, much of the conversation about building AI applications has revolved around agent frameworks.
LangChain became one of the best-known examples. Then came alternatives such as LlamaIndex, AutoGen, Semantic Kernel, CrewAI, Pydantic AI, Mastra, Strands, Google ADK and the OpenAI Agents SDK.
The usual comparison looked something like:
Which framework has the best tool calling, memory, RAG, multi-agent support and model integrations?
That is increasingly the wrong question.
By the middle of 2026, a different architecture was becoming visible. The basic model-and-tools loop was no longer the interesting part of an agent system. Pydantic put it particularly clearly when announcing Pydantic AI v2 in June: the inner loop — call the model, execute a tool, feed the result back — is largely settled. The leverage has moved into the layer around that loop: context management, tool exposure, permissions, lifecycle hooks, memory, execution environments and steering. Pydantic AI v2 announcement .
LangChain itself now makes a similar distinction. Its documentation describes LangChain as the agent framework, Deep Agents as an agent harness, LangGraph as the orchestration runtime, and LangSmith as the observability and evaluation platform. LangGraph documentation .
Meanwhile, projects such as Pi explicitly call themselves minimal agent harnesses, while Omnigent has introduced another abstraction entirely: the meta-harness, where complete coding agents such as Claude Code, Codex and Pi become replaceable execution engines. Pi.
The industry is moving from thinking about an agent as:
Model
+
Prompt
+
Toolstoward thinking about an agent runtime stack.
And for software engineering agents in particular, the harness may ultimately matter as much as — and in some situations more than — the model inside it.
The agent loop was only the beginning
At its simplest, an agent is not complicated.
User
│
▼
Model
│
├── final answer ───────────────► Done
│
└── tool call
│
▼
Tool
│
└──────────────► ModelStrands describes its foundational agent loop in almost exactly these terms: invoke the model, execute requested tools, return the results to the model and continue until the model produces a final answer. Strands agent loop .
LangChain's create_agent follows the same underlying idea,
implemented as a graph-based runtime on LangGraph.
LangChain agents
.
This loop is important, but it is becoming commodity infrastructure.
The difficult questions are everything around it.
What information should enter the context window?
What should happen when the context becomes full?
Which tools should the model see?
Can the agent run arbitrary shell commands?
Can it read secrets?
Can it modify the repository?
Should deleting a file require approval?
How does an agent resume after its process crashes?
How does it remember decisions made three hours earlier?
When should it create a subagent?
Should a reviewer inherit the implementer's context or start clean?
How do we prove that the agent actually ran the tests it claims to have run?
These aren't primarily model questions.
They are harness questions.
Two agents running the same model can perform very differently because their surrounding harnesses give the model different information, tools, feedback loops and constraints.
Recent research has started to formalise this idea. A May 2026 paper on AI Harness Engineering argues that software-engineering capability should be viewed as a model–harness–environment system, with responsibilities including context selection, project memory, task state, tool access, observability, verification, permissions and intervention recording. AI Harness Engineering .
That is a very different mental model from simply choosing an LLM framework.
A four-layer model for agent infrastructure
A useful way to understand the emerging landscape is to separate four architectural concerns.
┌─────────────────────────────────────────────┐
│ SOFTWARE FACTORY / WORKFLOW │
│ │
│ LangGraph • Temporal • ADK Workflows │
│ Microsoft Agent Framework │
└─────────────────────┬───────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ META-HARNESS │
│ │
│ Omnigent • Mastra* │
└─────────────────────┬───────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ AGENT / CODING HARNESS │
│ │
│ Pi • Deep Agents • Pydantic AI Harness │
│ Strands • Claude Agent SDK • OpenAI Sandbox │
└─────────────────────┬───────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ AGENT CORE │
│ │
│ LangChain • Pydantic AI • Strands │
│ OpenAI Agents SDK • AI SDK • Google ADK │
└─────────────────────┬───────────────────────┘
│
▼
LLMThe asterisk on Mastra is deliberate. Some products increasingly span several layers rather than fitting neatly into one.
This model is therefore not intended as a taxonomy of vendors.
It is a taxonomy of responsibilities.
And that distinction is becoming increasingly important.
Layer 1: The agent framework
The traditional agent framework provides the abstractions required to construct an agent.
Agent
├── Model
├── Instructions
├── Tools
├── State
└── Agent loopLangChain remains a good example.
Its current create_agent abstraction provides the model/tool
loop and is implemented on LangGraph, while middleware can intercept and
extend agent behaviour.
LangChain agent documentation
.
Other increasingly important examples include:
- Pydantic AI
- Strands Agents
- OpenAI Agents SDK
- Google ADK
- Microsoft Agent Framework
- Vercel AI SDK
- Mastra
But even these frameworks are expanding upward into harness territory.
Pydantic AI is a good illustration
Pydantic AI v2, released on 23 June 2026, introduced Capabilities as a central unit of composition.
A capability can package together:
instructions
tools
lifecycle hooks
model settingsso that behaviours such as memory, guardrails or coding support can be attached to an agent as a single composable concept. Pydantic AI v2 .
Pydantic then deliberately separated its core framework from the Pydantic AI Harness.
Pydantic AI
│
│ small/stable core
▼
Agent loop + providers + capabilities
│
▼
Pydantic AI Harness
│
├── filesystem
├── shell
├── context management
├── memory
├── planning
├── guardrails
└── coding capabilitiesPydantic explicitly describes this split as intentional: keep the agent core relatively small and stable, while allowing harness capabilities to evolve quickly. Pydantic AI v2 announcement .
That is an important architectural pattern.
Layer 2: The harness
A harness surrounds the agent loop with the machinery required to perform useful long-running work.
┌────────────────────┐
│ Agent Loop │
└─────────┬──────────┘
│
┌──────────────┼──────────────┐
│ │ │
Context Tools Memory
│ │ │
├──────────────┼──────────────┤
│ │ │
Policy Runtime Sessions
│ │ │
├──────────────┼──────────────┤
│ │ │
Verification Subagents ObservabilityCoding agents make the need for this layer particularly obvious.
A coding agent needs far more than model.generate().
Understand repository
↓
Search code
↓
Read files
↓
Plan change
↓
Edit
↓
Run compiler
↓
Run tests
↓
Inspect failures
↓
Repair
↓
VerifyThe quality of that environment dramatically changes the quality of the resulting agent.
Pi: harness minimalism
Pi is perhaps one of the purest examples of the coding-harness philosophy.
Its own description is concise:
Pi is a minimal agent harness.
Rather than trying to prescribe every desirable coding-agent feature, Pi provides extension points including extensions, skills, prompt templates and themes.
Importantly, Pi deliberately leaves features such as built-in subagents and plan mode out of the core, encouraging developers to add those behaviours themselves or install packages that implement them. Pi.
Pi also exposes an SDK for embedding its agent capabilities into other applications and automated workflows. Pi SDK.
Its philosophy is effectively:
small useful core
+
extension mechanism
+
your harness decisionsFor anyone interested in harness engineering itself, that is attractive.
Instead of inheriting somebody else's assumptions about planning, delegation, permissions and context management, you can experiment with those mechanisms directly.
LangChain's Deep Agents: the harness becomes explicit
LangChain has undergone a similar conceptual shift.
Deep Agents is now explicitly described by LangChain as an agent harness built on LangChain and LangGraph. It supplies capabilities including planning, filesystem tools, context management, subagents and long-term memory. Deep Agents .
LangChain
│
▼
Agent primitives
│
▼
Deep Agents
│
├── planning
├── filesystem
├── context management
├── subagents
├── memory
└── execution
│
▼
LangGraph
durable runtimeThis matters because it shows that the distinction between framework and harness is no longer just terminology invented by coding-agent enthusiasts.
One of the largest agent-framework ecosystems is now making the distinction itself.
Strands: a model-driven harness
Strands is another particularly interesting architecture.
Its philosophy is deliberately model-driven: rather than encoding every decision into a workflow, allow the model to reason about the task, choose tools and determine when it has completed the work, while the harness provides runtime control around that process. Strands model-driven approach .
By April 2026 Strands had released a TypeScript 1.0 SDK alongside Python, with typed tools, plugins and multi-agent orchestration. Strands TypeScript v1 .
By June, Strands was explicitly talking about its Harness SDK, adding improved context management and Strands Shell for isolated execution. Strands June 2026 update .
Its lifecycle hook architecture is particularly instructive:
Before invocation
↓
Before model
↓
After model
↓
Before tool
↓
After tool
↓
After invocationHooks allow developers to inspect or alter behaviour without modifying the core agent loop. Strands Hooks .
This is the sort of architectural primitive that becomes very important once agents are performing actions rather than merely producing text.
The framework no longer needs to predict every possible workflow.
Instead, it provides a simple autonomous loop surrounded by deterministic control points.
The common architecture is becoming visible
Compare several projects and a common pattern starts to emerge:
Pi
Extension
Pydantic AI
Capability
LangChain
Middleware / Deep Agent
Strands
Hook / PluginDifferent names, but a similar idea:
Keep the model-driven inner loop relatively simple and make the surrounding behaviour composable.
This may become one of the defining architectural patterns of agent systems.
Execution environments are becoming part of the harness
Another important shift is that compute is becoming an explicit agent abstraction.
Coding agents cannot safely be given unrestricted access to the machine running the application.
They need controlled environments in which they can:
read files
write files
run commands
install packages
execute tests
start servers
inspect outputswhile limiting what they can damage.
OpenAI's April 2026 evolution of the Agents SDK provides a good example. OpenAI introduced native sandbox-oriented agent capabilities where agents can operate in controlled workspaces with files and tools; its sandbox model covers filesystem access, shell execution, packages, ports, snapshots and resumable state. OpenAI Agents SDK evolution .
Strands similarly added its own isolated shell environment in June. Strands Shell .
Deep Agents supports pluggable filesystem and sandbox backends and shell execution when backed by an appropriate sandbox. Deep Agents overview .
This suggests another principle:
The execution environment is not infrastructure underneath the agent. It is part of the agent's behavioural architecture.
The filesystem the agent sees, the commands it can execute and the state that survives between sessions all affect its reasoning.
Layer 3: The meta-harness
Once organisations use multiple mature coding harnesses, another problem appears.
Imagine an engineering environment containing:
Claude Code
Codex
Pi
OpenCode
Cursor
internal agentsEach may be excellent individually.
But each tends to bring its own:
session model
permissions
tool semantics
context format
configuration
sandbox assumptions
UI
cost accountingNow suppose you want Claude Code to implement something and Codex to review it.
Or use Pi for inexpensive repository exploration.
Or run the same task through several harnesses and compare the results.
Without another abstraction, developers end up orchestrating these tools manually.
That is the problem addressed by the meta-harness.
Omnigent: the harness becomes replaceable
Omnigent was publicly released in June 2026 and positioned as a meta-harness that sits above existing agent harnesses, allowing systems such as Claude Code, Codex and Pi to become components behind a common layer.
Omnigent
│
policy / sessions / control
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Claude Code Codex Pi
│ │ │
complete complete complete
harness harness harnessThis is fundamentally different from LangChain-style composition.
LangChain traditionally asks:
Which models, tools and middleware should make up my agent?
A meta-harness asks:
Which complete agent runtime should perform this task?
That changes the unit of composition.
Omnigent was moving quickly during June and July. Its first tagged release was 13 June; by 27 July it had reached v0.7.0. The June v0.3 release expanded its harness fleet substantially, while the 10 July v0.5.0 release added a generic ACP harness capable of connecting compatible agents. Omnigent releases.
This architecture is interesting because it treats a coding harness almost like infrastructure treats a container runtime:
Task
│
▼
Meta-harness
│
├── select harness
├── apply policy
├── provision environment
├── observe execution
└── collect result
│
▼
Coding HarnessThe harness becomes replaceable.
Mastra shows how quickly the layers are converging
Mastra is difficult to place neatly because it increasingly spans several layers.
In June 2026 Mastra added support for the Agent Client Protocol, allowing Mastra agents to delegate coding tasks to ACP-compatible harnesses. Mastra ACP support .
On 15 June it announced SDK-based subagents for Claude Code, Cursor and Codex and explicitly described itself as moving toward a meta-harness, allowing those specialised harnesses to retain their native coding capabilities while participating in Mastra workflows, tracing and composition. Mastra SDK subagents .
Mastra had also extracted the interactive runtime around its own coding agent into a reusable Harness abstraction. By 30 June that API had been renamed AgentController to distinguish it from Mastra's broader role as a harness.
AgentController manages concerns such as sessions, modes, threads, permissions, subagents, model switching, persistence and UI events. Mastra AgentController .
This illustrates an important point.
The architecture is not evolving into four perfectly separated products.
Instead, successful frameworks are expanding vertically through the stack.
Layer 4: Durable orchestration
A coding harness is good at:
goal
↓
explore
↓
edit
↓
test
↓
finishBut a software-delivery process might look more like:
Requirement
↓
Architecture review
↓
Implementation
↓
Parallel component changes
↓
Integration
↓
Tests
↓
Security analysis
↓
Human approval
↓
Deployment
↓
Production verificationThis may take hours or days.
Processes may crash.
Humans may take hours to approve something.
Agents may need retries.
Steps may need to run in parallel.
At this point, the problem is no longer simply agent execution.
It is durable workflow execution.
This is where systems such as LangGraph and Temporal fit.
LangGraph explicitly focuses on durable execution, persistence, streaming and human-in-the-loop orchestration underneath higher-level agent abstractions. LangGraph .
Temporal addresses the more general distributed-systems problem of durable execution by persisting workflow progress so execution can continue across process, machine and infrastructure failures. Temporal durable execution .
Google's ADK was also moving in this direction. In July 2026 Google described ADK 2.0 workflows as a way to combine exploratory agent reasoning with deterministic workflow graphs, deliberately separating execution control from the LLM. Why Google built ADK 2.0 .
Microsoft was pursuing a similar idea with Agent Framework durable workflows; by May 2026 Microsoft was demonstrating workflow definitions that could move from in-process execution to durable Azure Functions hosting while preserving the workflow model. Durable workflows in Microsoft Agent Framework .
This suggests another useful separation:
Harness
owns how an agent works
Workflow runtime
owns when and whether work runsThose are different responsibilities.
The unit of composition is moving upward
Perhaps the most important architectural change is not any particular framework.
It is the unit developers compose.
A simplified history looks like this:
2023
Model calls
↓
2024
Models + prompts + RAG + tools
↓
2025
Agents
↓
2026
Harnesses
↓
Emerging
Systems of harnessesInitially we composed model calls.
Then we composed tools around models.
Then agents became reusable units.
Now complete harnesses are becoming reusable units.
A meta-harness such as Omnigent takes this idea literally: switch the runtime while preserving higher-level configuration and control. Omnigent harness documentation .
Mastra's ACP and SDK-agent work points in the same direction. Mastra ACP .
This could become a significant architectural transition.
The harness may matter more than another small model improvement
The AI industry understandably spends enormous attention on model benchmarks.
But imagine two systems using the same frontier model.
Agent A
model
+
bashAgent B
model
+
repository map
+
semantic/code search
+
structured file editing
+
context management
+
persistent decisions
+
git isolation
+
test feedback
+
compiler feedback
+
permission policy
+
subagent delegation
+
verificationThese are not equivalent agents.
Even though the underlying intelligence is identical.
The harness determines:
- what the model can observe;
- what actions it can take;
- what feedback it receives;
- what information survives;
- what actions are prohibited;
- and what evidence is required before work is considered complete.
This is why harness engineering is likely to become a discipline in its own right.
The important optimisation target is no longer:
How good is the model?
It becomes:
How effective is the model + harness + environment system?
That is precisely the direction emerging research on harness engineering is beginning to articulate. AI Harness Engineering .
Coding agents are exposing the architecture first
Software engineering is a particularly good environment for discovering these patterns because coding agents operate in an unusually rich feedback system.
A model can propose a code change.
Then the environment can respond objectively.
Agent
│
▼
Edit
│
▼
Compile
│
┌──────┴──────┐
│ │
pass fail
│ │
▼ └────► Agent
Test
│
┌───┴───┐
│ │
pass fail
│ │
▼ └──────────► Agent
Verify
│
▼
DoneThis creates powerful feedback loops.
Tests can challenge the model.
Compilers can challenge the model.
Linters can challenge the model.
Static-analysis tools can challenge the model.
Review agents can challenge the model.
Production telemetry can eventually challenge the model.
In other words, coding allows us to build agents that do not merely reason.
They can repeatedly act, observe and verify.
That makes software engineering a natural laboratory for harness engineering.
Model-driven inside, deterministic outside
One design principle appears repeatedly across these frameworks.
Do not necessarily make the entire workflow deterministic.
And do not give the model unrestricted autonomy.
Instead:
Allow autonomy inside deterministic boundaries.
deterministic boundary
┌──────────────────────────┐
│ │
│ Agent loop │
│ │
│ explore │
│ reason │
│ edit │
│ test │
│ delegate │
│ │
└──────────────────────────┘
deterministic controls
permissions
budgets
sandbox
verification
workflow gates
approvalsStrands' model-driven philosophy is one expression of this idea. Strands agent control .
Google ADK 2.0's deterministic workflow graph around agent reasoning is another. Google ADK 2.0 .
LangGraph's separation between higher-level agents and a durable orchestration runtime provides another variation. LangGraph .
This combination may be more robust than either extreme.
A future software factory
Put the pieces together and an interesting architecture emerges.
SOFTWARE FACTORY
│
▼
Durable Orchestration
LangGraph / Temporal / etc.
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Analyse Implement Review
│ │ │
└─────────────────┼──────────────────┘
│
▼
Meta-Harness
│
policy / routing / budget
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Claude Code Codex Pi
│ │ │
└─────────────────┼─────────────────┘
│
▼
Sandboxes
│
▼
Git Worktrees
│
▼
RepositoryA task could arrive at the factory.
The workflow decides what phases are required.
The meta-harness selects the most appropriate execution harness.
A specialised coding harness performs the work.
The sandbox constrains execution.
Tests and other evidence verify the result.
Another harness reviews the change.
A human intervenes where policy requires it.
The workflow persists throughout.
The models may change constantly.
The architecture does not have to.
So where does LangChain fit now?
LangChain remains highly relevant.
But it should no longer be compared directly with every other piece of this stack.
A better mapping as of July 2026 is:
| Technology | Primary architectural role |
|---|---|
| LangChain | Agent framework |
| Deep Agents | Agent harness |
| LangGraph | Durable agent orchestration |
| LangSmith | Observability and evaluation |
| Strands | Model-driven agent framework / harness |
| Pydantic AI | Typed agent framework |
| Pydantic AI Harness | Composable harness capabilities |
| Pi | Minimal coding harness |
| Mastra | Agent framework increasingly spanning harness and meta-harness concerns |
| Omnigent | Meta-harness over multiple agent runtimes |
| Temporal | General durable execution runtime |
This table is intentionally about architecture, not feature parity.
Most of these products overlap.
And those overlaps are likely to increase.
What I would build today
If I were designing a new engineering-agent platform in July 2026, I would resist choosing one enormous framework and allowing it to become the architecture.
Instead, I would define interfaces around the important boundaries:
Model
Agent
Tool
ToolRegistry
Context
Memory
Workspace
Sandbox
Policy
Approval
Harness
HarnessAdapter
Task
Run
Checkpoint
Verifier
Evaluator
Event
TraceThe actual implementation behind those interfaces could change.
Today:
Pi
Claude Code
Codex
Strands
Pydantic AITomorrow:
something betterThe goal would be to keep the architecture stable while the rapidly changing agent ecosystem evolves underneath it.
That becomes especially important when the useful life of an enterprise software platform may be ten years while the dominant coding-agent harness may change in ten months.
The emerging discipline: harness engineering
The phrase harness engineering is likely to become increasingly important.
It describes something broader than prompt engineering.
And broader than agent framework selection.
Harness engineering asks:
What does the model see?
What can it do?
What does it remember?
How is its context managed?
How does it interact with its environment?
What feedback does it receive?
How does it recover?
What evidence proves success?
When does a human intervene?
How are other agents delegated to?
How are actions governed?
How do we observe and evaluate the whole trajectory?These are systems-engineering questions.
And as agents become more autonomous, they increasingly look like the important questions.
The next abstraction is already forming
The progression is becoming clearer.
LLM
│
▼
Agent
│
▼
Harness
│
▼
Meta-Harness
│
▼
Software FactoryEach layer reduces the importance of the implementation details underneath it.
The model becomes interchangeable inside a harness.
The harness becomes interchangeable inside a meta-harness.
The agent becomes interchangeable inside a workflow.
Eventually, the organisation may care less about whether a change was produced by Claude, GPT, Gemini or another model.
Instead it will care that:
the requirement was understood
the correct repository was modified
the change obeyed architecture policy
the tests passed
security controls passed
the change was independently reviewed
the evidence was captured
the deployment succeeded
production remained healthyThat is a much more mature definition of autonomous software engineering.
And it leads to perhaps the most important conclusion.
The future of agentic software development will not be defined solely by better models.
It will be defined by the systems we build around those models.
The agent framework was the beginning.
The harness is becoming the architecture.
Comments