1. The Great Migration: Lock-In Moves Up the Stack
2. Anatomy of the Agent Harness: The 5-Pillar Control Plane
3. The SDK Wars: OpenAI Agents SDK vs. Claude Agent SDK
4. Four Vendor Philosophies: Architectural Comparison
5. The Switching-Cost Calculus: Financial and Code Churn Metrics
6. Build vs. Buy Decision Framework: The Executive Matrix
7. The 2027–2030 Harness Roadmap: From Prototypes to Micro-Harnesses
8. Vatsal Shah's Tactical Playbook for Engineering Leaders
9. Frequently Asked Questions (FAQ)
10. References & Standards

In the early phases of the generative AI boom, enterprise technology strategy was dominated by a single, high-stakes question: Which foundational model should we build on? Organizations spent millions evaluating parameter sizes, token pricing, and context windows, treating the model as the primary engine of intellectual property.

Because model intelligence has become a commodity, the source of competitive differentiation—and the primary risk of vendor lock-in—has migrated up the technology stack. The battleground is no longer the model itself, but the Agent Harness.

An agent harness is the runtime environment and control plane that wraps around a model. It provides the essential infrastructure that LLMs lack natively: persistent state, context window management, tool execution sandboxes, security observation sensors, and multi-agent coordination. Without a robust harness, a model is merely a stateless text predictor. With a harness, it becomes an autonomous system capable of executing complex workflows.

However, many organizations are building their agent harnesses directly on top of proprietary, model-specific SDKs. This creates a hidden, high-risk lock-in above the model layer. If your prompt templates, tool schemas, state transitions, and security policies are hardcoded into a vendor's native framework, you cannot easily switch models. You are locked into their platform, not because of their model's superior reasoning, but because of the massive codebase churn required to migrate your harness to a competitor's system.

This shift has profound organizational implications. Chief Technology Officers who previously focused their budgets on model licensing agreements are realizing that their custom orchestration logic, prompt tuning sequences, and tool connections represent their actual proprietary IP. If this IP is tightly bound to a specific model provider's runtime engine, the organization's strategic agility is severely compromised, exposing it to unchecked API price hikes and deprecation cycles.

Anatomy of the Agent Harness: The 5-Pillar Control Plane

To build a portable, resilient agent architecture, platform engineering teams must understand the core components of a modern harness. A production-grade control plane is composed of five distinct pillars:

1. The Context & Prompt Pipeline

The context pipeline is responsible for dynamic context management. Because model context windows are limited and expensive, the harness must dynamically prune, summarize, and rank information before sending it to the model. This includes managing semantic search retrieval, system prompt formatting, and historical turn-compaction.

Implementing a Semantic Compaction Pipeline

To prevent context window overflow and contain inference costs, the harness must run a compaction pipeline before executing model API endpoints. Below is a Python-based utility illustrating how to prune conversation history based on token constraints and vector relevance:

import tiktoken

class ContextCompactor:
    def __init__(self, model_name="gpt-4", max_tokens=4000):
        self.encoder = tiktoken.encoding_for_model(model_name)
        self.max_tokens = max_tokens

    def count_tokens(self, text: str) -> int:
        return len(self.encoder.encode(text))

    def compact_history(self, history: list, system_prompt: str) -> list:
        system_tokens = self.count_tokens(system_prompt)
        available_tokens = self.max_tokens - system_tokens
        
        compacted = []
        accumulated_tokens = 0
        
        # Process history in reverse (most recent first) to keep recent context
        for turn in reversed(history):
            turn_text = f"{turn['role']}: {turn['content']}"
            turn_tokens = self.count_tokens(turn_text)
            
            if accumulated_tokens + turn_tokens > available_tokens:
                # If too large, compress earlier turns using a summary block
                summary = self.summarize_block(turn['content'])
                summary_text = f"system: [Summary of earlier turns: {summary}]"
                summary_tokens = self.count_tokens(summary_text)
                
                if accumulated_tokens + summary_tokens <= available_tokens:
                    compacted.append({"role": "system", "content": f"[Summary: {summary}]"})
                break
                
            compacted.append(turn)
            accumulated_tokens += turn_tokens
            
        return [({"role": "system", "content": system_prompt})] + list(reversed(compacted))

    def summarize_block(self, text: str) -> str:
        # Placeholder for heuristic-based text compression
        return text[:100] + "..."

2. State & Memory Ledger

Models are stateless. The state ledger manages persistent memory across long-lived agent executions. It tracks variables, stores checkpoint hashes, handles agent pause/resume states for human-in-the-loop approvals, and manages vector-based long-term memory.

Designing the Stateful Session Schema

To preserve agent portability, session state must reside inside enterprise data layers rather than the model provider's cloud. A production session database schema should maintain strict separation between the orchestrator state and execution metadata:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "AgentSessionState",
  "type": "object",
  "properties": {
    "session_id": { "type": "string", "format": "uuid" },
    "active_checkpoint": { "type": "string" },
    "execution_status": { "type": "string", "enum": ["ACTIVE", "PAUSED_FOR_HITL", "COMPLETED", "FAILED"] },
    "variables": {
      "type": "object",
      "additionalProperties": { "type": "string" }
    },
    "memory_ledger": {
      "type": "object",
      "properties": {
        "short_term_buffer": { "type": "array", "items": { "type": "object" } },
        "long_term_vector_references": { "type": "array", "items": { "type": "string" } }
      }
    }
  },
  "required": ["session_id", "active_checkpoint", "execution_status"]
}

3. Tool Execution Sandbox

When a model decides to invoke a tool, the harness manages the execution process. It parses the tool request, validates input parameters against registered JSON schemas, isolates the execution inside a secure sandbox container (e.g., WebAssembly or a microVM), and returns the results to the model.

Implementing a Lightweight Wasm Sandbox Runner

To prevent arbitrary code execution on host systems, the harness isolates tool processes inside a WebAssembly runtime. Below is a TypeScript handler showing how the control plane initiates a sandboxed execution context:

import { WASI } from '@wasm/wasi';
import { WebAssemblyInstantiator } from './wasm-utils';

export class ToolSandbox {
  private wasi: WASI;

  constructor(private toolBinaryPath: string) {
    this.wasi = new WASI({
      args: [],
      env: { "SANDBOX_SECURE": "true" },
      preopens: { '/tmp': '/tmp/sandbox_isolated' }
    });
  }

  async run(toolArguments: Record<string, any>): Promise<string> {
    const wasmBuffer = await fs.promises.readFile(this.toolBinaryPath);
    const instance = await WebAssemblyInstantiator(wasmBuffer, {
      wasi_snapshot_preview1: this.wasi.wasiImport
    });
    
    // Inject arguments into the Wasm memory space
    this.wasi.start(instance);
    return instance.exports.execute_tool(JSON.stringify(toolArguments));
  }
}

4. Telemetry & Observation Sensors

Sensors act as the eyes and ears of the control plane. They log prompt-to-token ratios, track response latency, measure model costs (FinOps), and record exact execution graphs. This telemetry is critical for audit compliance and debugging agent drift.

Formatting OpenTelemetry Payloads for Agent Runs

To maintain observability across vendor migrations, sensor telemetry must adhere to standard OpenTelemetry semantic conventions. Below is a sample payload tracking a tool call execution span:

{
  "resourceSpans": [
    {
      "resource": {
        "attributes": [
          { "key": "service.name", "value": {"stringValue": "agent-orchestrator-harness"} },
          { "key": "agent.id", "value": {"stringValue": "log-auditor-agent-09"} }
        ]
      },
      "scopeSpans": [
        {
          "scope": { "name": "harness-telemetry-sensor" },
          "spans": [
            {
              "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
              "spanId": "00f067aa0ba902b7",
              "name": "mcp_tool_execution:run_audit_tool",
              "kind": 3,
              "startTimeUnixNano": 1784041898796000000,
              "endTimeUnixNano": 1784041899142000000,
              "attributes": [
                { "key": "gen_ai.system", "value": {"stringValue": "anthropic"} },
                { "key": "gen_ai.request.model", "value": {"stringValue": "claude-3-5-sonnet-2026"} },
                { "key": "gen_ai.usage.prompt_tokens", "value": {"intValue": 1420} },
                { "key": "gen_ai.usage.completion_tokens", "value": {"intValue": 230} }
              ]
            }
          ]
        }
      ]
    }
  ]
}

5. Multi-Agent Coordinator

In complex environments, tasks are divided among multiple specialized agents. The coordinator manages message routing, role boundaries, task delegation, and execution loops between agents.

Let us inspect the system architecture of this control plane:

The SDK Wars: OpenAI Agents SDK vs. Claude Agent SDK

The primary drivers of harness lock-in are the proprietary SDKs released by the major model providers. In late 2025 and 2026, the industry has seen a fierce standardization battle between the OpenAI Agents SDK and the Claude Agent SDK.

Each provider designed their SDK to optimize developers' workflows for their specific model API, but this optimization introduces structural bias:

• OpenAI Agents SDK: Built heavily around their Assistant API and stateful Threads endpoint. The state of the conversation and the execution of tools are managed natively on OpenAI's servers. While this simplifies initial development, it makes portability nearly impossible. Your application state lives in OpenAI's databases, and your tools are executed via their hosted runners.
• Claude Agent SDK: Focuses on stateless client-side orchestration, using the Model Context Protocol (MCP) as the primary interface for tool integration. It forces developers to manage conversation state locally, offering greater architectural flexibility but requiring a more complex platform team to run it.

Code Contrast: Stateful vs. Stateless Orchestration

To see this architectural gap in code, consider how tools are executed under each SDK.

OpenAI Stateful Threads (Locked to Cloud Runner):

# OpenAI Assistant approach - conversation state lives on their servers
from openai import OpenAI
client = OpenAI()

# The thread and assistant are cloud resources
assistant = client.beta.assistants.create(
    name="System Auditor",
    instructions="Review the code logs and execute diagnostic tool if drift detected.",
    tools=[{"type": "function", "function": {"name": "run_audit_tool", "description": "..."}}],
    model="gpt-4o"
)
thread = client.beta.threads.create()
# Execution runs on the cloud platform
run = client.beta.threads.runs.create(thread_id=thread.id, assistant_id=assistant.id)

Claude Stateless MCP Integration (Vendor-Agnostic):

# Claude stateless approach - client retains complete control over state
import asyncio
from mcp import ClientSession, StdioServerParameters

async def run_stateless_agent():
    # Tools exist on a local/remote MCP server, fully decoupled from Anthropic
    server_params = StdioServerParameters(command="node", args=["mcp-audit-server.js"])
    
    async with ClientSession(server_params) as session:
        await session.initialize()
        
        # Tools are read dynamically; state is stored in your local database
        tools = await session.list_tools()
        
        # The prompt is sent to Claude statelessly
        response = await call_claude_api(
            prompt="Analyze system logs.", 
            available_tools=tools,
            history_state=load_local_session(session_id="session_123")
        )

If an engineering team builds their tools using OpenAI's stateful Threads format, migrating those tools to Claude requires rewriting the entire state ledger and tool invocation handlers. The lock-in has moved from the model endpoint to the state management architecture.

To prevent this lock-in, organizations must adopt an Agent Portability Strategy. This strategy requires wrapping all model calls in a standardized, local abstraction layer (e.g., using open-source gateways like LiteLLM or custom middleware) and maintaining strict local control over tool definitions and conversation state.

Four Vendor Philosophies: Architectural Comparison

As platform teams evaluate the market, they encounter four primary architectural philosophies for building and running agent harnesses. These options range from fully managed SaaS platforms to custom, self-hosted frameworks:

Choosing the right philosophy requires balancing immediate development speed against long-term operational control and portability risk.

The Switching-Cost Calculus: Financial and Code Churn Metrics

Before committing to a vendor's managed harness, engineering leaders must calculate the true cost of migration. Churn calculations should evaluate three primary cost buckets:

1. Code Base Churn

If a harness is hardcoded to a model's SDK, migrating involves rewriting the prompt templates, tool routing logic, and error handlers. This can affect up to 40% of the application codebase.

$$Migration\ Code\ Churn\ (MCC) = \frac{\sum (LOC_{rewritten} + LOC_{deleted})}{Total\ LOC_{orchestration}} \times 100$$

Where $LOC_{orchestration}$ is the total lines of orchestration code (excluding raw business logic and UI files). In typical legacy migrations from OpenAI Assistants API to a vendor-agnostic LangGraph implementation, the MCC score averages 38.4%, requiring substantial developer cycles.

2. Telemetry and Audit Loss

When migrating from a hosted assistant API (like OpenAI's Threads) to a self-hosted framework, you lose historical run telemetry unless you have built a custom, vendor-agnostic logging warehouse. Without this, your historical performance evaluations and fine-tuning data are lost.

To quantify this, we define the Telemetry Loss Ratio (TLR):

$$TLR = 1 - \frac{Telemetry\ Records\ Successfully\ Migrated}{Total\ Telemetry\ Records\ Accumulated}$$

In native hosted services, TLR is effectively 1.0 (100% loss) because export endpoints for raw run execution traces, model token usage statistics, and prompt history details are not exposed via the API.

3. Pipeline Reconstruction Costs

Managed harnesses handle token allocation, model fallback, and rate-limiting natively. Moving to a self-hosted model means your platform team must construct these load-balancing features from scratch, adding significant infrastructure overhead.

The financial impact of this reconstruction can be calculated using the Amortized Engineering Cost formula:

$$AEC = \frac{T_{dev} \times Rate_{hourly} + C_{infra}}{N_{runs}}$$

Where $T_{dev}$ is the developer hours spent constructing the custom proxy load-balancer, $Rate_{hourly}$ is the average engineer salary rate ($120/hr in 2026), $C_{infra}$ is the auxiliary cloud runtime compute costs, and $N_{runs}$ is the number of production agent runs. For enterprises executing fewer than 100,000 runs per month, the AEC of building an in-house proxy load balancer can exceed $0.45 per run, wiping out the unit token cost savings of moving to open-source models.

Build vs. Buy Decision Framework: The Executive Matrix

To guide platform teams through the decision-making process, I have developed a structured decision gate:

Pinned Evaluation Checklist

1. Do you require strict data residency and on-premise execution?

- If Yes: Build a self-hosted, custom harness or use open-source frameworks. You cannot use managed vendor SaaS engines.

1. What is the ratio of custom enterprise tools to public utility APIs?

- If high enterprise integration: Build a custom control plane. Managed platforms struggle to safely connect to local legacy systems.

1. What is your target time-to-market for the initial prototype?

- If under 30 days: Use managed SaaS APIs for validation, but ensure a clear migration roadmap to a vendor-agnostic framework is drafted.

Organizational Governance: RACI Matrix for Agent Platforms

Deploying a production agent harness requires close collaboration between platform engineering teams (who own the infrastructure) and product engineering teams (who own the business workflows). The RACI matrix below outlines the division of responsibilities:

This RACI structure ensures that platform teams focus on building a secure, stable sandbox runtime and observing transaction costs, while product teams focus on maximizing model task success rates without needing to construct underlying telemetry systems from scratch.

To see the operational tradeoffs, let us inspect a comparison grid illustrating the difference between a prototype built directly on raw model APIs versus a production-grade custom harness:

The 2027–2030 Harness Roadmap: From Prototypes to Micro-Harnesses

As agent architectures mature, the control plane will undergo a major transformation. Platforms will move away from heavy, monolithic frameworks toward lightweight, micro-harnesses.

Phase 1: Gateway Abstraction (2026)

• Objective: Decouple model APIs from application logic.
• Actions: Deploy a central model proxy gateway. Standardize tool definition schemas using the Model Context Protocol (MCP). Stop direct integration of model-specific SDKs in product code.
• Metrics: API latency overhead, model switching time.

Phase 2: Sandbox Isolation (2027)

• Objective: Secure the tool execution environment and protect system resources.
• Actions: Mandate that all external tool calls run inside WebAssembly (Wasm) runtimes or microVM sandboxes managed by the harness. Implement real-time token and runtime budgets per execution loop.
• Metrics: Sandbox escape attempts (target: zero), tool runtime overhead.

Phase 3: Micro-Harness Deployment (2028)

• Objective: Scale coordinator squads without central bottlenecks.
• Actions: Replace central orchestrators with decentralized micro-harnesses that run locally alongside target microservices. Enforce SPIFFE-based agent identities for inter-harness communication.
• Metrics: Network hop overhead, resource utilization efficiency.

Vatsal Shah's Tactical Playbook for Engineering Leaders

For organizations executing a platform engineering shift, I recommend a structured plan:

The 90-Day Execution Guide

1. Map Your Agent Portfolio (Days 1–30):

- Identify all active agent prototypes and production scripts in the organization. Document their dependencies on proprietary libraries (OpenAI SDK, LlamaIndex, LangChain) and record their model configurations. - Audit the codebases to measure your current "Migration Code Churn" (MCC) score. Target a baseline mapping that identifies all hardcoded SDK calls. - Key Deliverable: An enterprise-wide Agent Inventory Registry mapping dependencies, data flow access, and operational risk metrics.

1. Deploy an Abstraction Proxy (Days 31–60):

- Deploy an open-source model gateway proxy (e.g., LiteLLM, custom proxy monolith) to unify and route all model API requests. - Refactor agent application codebases to query the local proxy gateway using standard JSON payloads, removing vendor-specific API client libraries entirely. - Key Deliverable: A unified gateway layer enforcing key rate-limiting rules, token budgeting policies, and model fallback logic. Target a maximum gateway latency overhead of < 15ms.

1. Decouple State and Tools (Days 61–90):

- Extract conversation state and variables from vendor-hosted cloud databases and locate them inside secure, local data structures (e.g., PostgreSQL, Redis). - Standardize all custom tools around the Model Context Protocol (MCP), exposing capabilities via stdio or SSE server sessions rather than embedding tool logic inside the orchestrator client. - Key Deliverable: A fully decoupled architecture where the model, the state ledger, and the tools communicate over verified schemas and open protocols.

Key Performance Indicators (KPIs) for Harness Migrations

To evaluate the success of your harness architecture shift, track the following metrics over a 12-month window:

• Model Swapping Velocity: The time in developer hours required to switch the active reasoning model of an agent from Claude 3.5 Sonnet to GPT-4o. Target: < 4 hours (down from 80+ hours in direct SDK setups).
• Token Optimization Index: The percentage reduction in token waste achieved by applying dynamic prompt compaction. Target: > 25% reduction.
• Tool Registration Cycle Time: The time required to register, sandbox, and authorize a new enterprise tool in the gateway. Target: < 30 minutes.
• Sandbox Security Containment: The number of unverified tool access violations blocked by WASI execution constraints. Target: 100% containment.

By following this playbook, you will preserve model portability, secure your execution pipelines, and protect your organization from vendor lock-in.

To understand how platform teams monitor and manage this infrastructure, let us examine a realistic UI mock of a harness evaluation dashboard:

In addition to evaluation telemetry, platform teams require configuration portals to manage execution limits, token caps, and sandbox permissions:

Frequently Asked Questions (FAQ)

Q1: What is the difference between an agent harness and an agent framework?

An agent framework (e.g., LangChain) is a development library containing pre-built helpers for writing agent code. An agent harness is the complete runtime control plane—including sandboxes, telemetry logging, state ledgers, and gateways—that manages the execution, security, and cost of that agent code in production.

Q2: Why is direct SDK integration a lock-in risk?

When you integrate model-specific SDKs (like OpenAI's native client) directly into your application, you format your prompts, state ledgers, and tool invocation hooks using their proprietary patterns. Swapping models later requires refactoring large portions of this orchestration logic, creating a high switching cost.

Q3: How does the Model Context Protocol (MCP) help?

MCP standardizes the interface between models and tools. By using MCP, your tools expose their schemas and parameter descriptions in a universal format. The orchestration harness reads this format, allowing you to swap the reasoning model without having to change the code of your underlying tools.

Q4: Should we build or buy our production harness?

If your applications require strict data residency, integrate with custom legacy infrastructure, or need specific compliance audits, you should build a vendor-agnostic harness on-premise. If you need to quickly validate a customer-facing prototype with minimal setup overhead, managed SaaS platforms are acceptable for initial validation.

Q5: How do we track the cost of autonomous agent runs?

You must implement a FinOps sensor in the harness. The sensor intercepts all outgoing model calls, parses prompt and completion tokens, correlates them with active model pricing rates, and logs the cost of each run to a central data warehouse.

References & Standards

1. Model Context Protocol (MCP): Protocol Specification & Developer Integration Guide. modelcontextprotocol.io
2. OpenAI Assistant API & Agents SDK: Stateful Thread Management and Tool Execution Interfaces. OpenAI Developer Documentation.
3. Claude Agent SDK: Stateless Client-Side Orchestration Patterns. Anthropic Developer Guides.
4. Agentic Software Engineering: Design Patterns for Stateful Multi-Agent Infrastructure. ThoughtWorks Software Architecture Repository.
5. FinOps for GenAI: Standardizing Token Cost Allocation and Inference Tracking. FinOps Foundation. finops.org

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "@id": "https://agiletechguru.com/blog/agent-harness-control-plane-build-buy-lock-in#article",
      "isPartOf": {
        "@id": "https://agiletechguru.com/blog/agent-harness-control-plane-build-buy-lock-in"
      },
      "headline": "The Agent Harness Is Your Control Plane — Why AI Lock-In Moved Above the Model Layer",
      "description": "Same frontier model. One team ships in weeks, another burns a year in prototype. The difference isn't GPT vs Claude — it's the harness you chained yourself to.",
      "image": {
        "@type": "ImageObject",
        "url": "https://agiletechguru.com/uploads/content/blog/agent-harness-control-plane-build-buy-lock-in/featured-banner.webp",
        "width": 1200,
        "height": 630
      },
      "datePublished": "2026-07-14T00:00:00+00:00",
      "dateModified": "2026-07-14T00:00:00+00:00",
      "author": {
        "@type": "Person",
        "name": "Vatsal Shah"
      },
      "publisher": {
        "@type": "Organization",
        "name": "Agile Tech Guru",
        "logo": {
          "@type": "ImageObject",
          "url": "https://agiletechguru.com/assets/images/logo.png"
        }
      },
      "mainEntityOfPage": "https://agiletechguru.com/blog/agent-harness-control-plane-build-buy-lock-in"
    },
    {
      "@type": "FAQPage",
      "@id": "https://agiletechguru.com/blog/agent-harness-control-plane-build-buy-lock-in#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "What is the difference between an agent harness and an agent framework?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "An agent framework (e.g., LangChain) is a development library containing pre-built helpers for writing agent code. An agent harness is the complete runtime control plane—including sandboxes, telemetry logging, state ledgers, and gateways—that manages the execution, security, and cost of that agent code in production."
          }
        },
        {
          "@type": "Question",
          "name": "Why is direct SDK integration a lock-in risk?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "When you integrate model-specific SDKs (like OpenAI's native client) directly into your application, you format your prompts, state ledgers, and tool invocation hooks using their proprietary patterns. Swapping models later requires refactoring large portions of this orchestration logic, creating a high switching cost."
          }
        },
        {
          "@type": "Question",
          "name": "How does the Model Context Protocol (MCP) help?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "MCP standardizes the interface between models and tools. By using MCP, your tools expose their schemas and parameter descriptions in a universal format. The orchestration harness reads this format, allowing you to swap the reasoning model without having to change the code of your underlying tools."
          }
        },
        {
          "@type": "Question",
          "name": "Should we build or buy our production harness?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "If your applications require strict data residency, integrate with custom legacy infrastructure, or need specific compliance audits, you should build a vendor-agnostic harness on-premise. If you need to quickly validate a customer-facing prototype with minimal setup overhead, managed SaaS platforms are acceptable for initial validation."
          }
        },
        {
          "@type": "Question",
          "name": "How do we track the cost of autonomous agent runs?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "You must implement a FinOps sensor in the harness. The sensor intercepts all outgoing model calls, parses prompt and completion tokens, correlates them with active model pricing rates, and logs the cost of each run to a central data warehouse."
          }
        }
      ]
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://agiletechguru.com/blog/agent-harness-control-plane-build-buy-lock-in#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Home",
          "item": "https://agiletechguru.com"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Blog",
          "item": "https://agiletechguru.com/blog"
        },
        {
          "@type": "ListItem",
          "position": 3,
          "name": "Agent Harness Control Plane",
          "item": "https://agiletechguru.com/blog/agent-harness-control-plane-build-buy-lock-in"
        }
      ]
    }
  ]
}