Barnyard reaches Claude through Azure AI Foundry. Every turn, it mints an Azure AD bearer token, points the Anthropic SDK at a Foundry endpoint, and runs an agent loop we wrote ourselves. It works, and it has for months. It is not the path Anthropic builds for people running agents, and that gap is widening.
This compares the two paths: Barnyard’s current architecture, Anthropic’s managed agent stack, and what switching would gain and cost. Barnyard is an MCP-native platform. The loop is ours; underneath it sits a full Model Context Protocol fabric — a gateway, a fleet of first-party MCP servers, a registry that plugs external ones in, a Rust trust kernel, and a budget-aware research engine. What we rent is the model. What we own is the platform. Keeping those two straight is the whole point of the comparison.
What Barnyard does today
Barnyard’s model access is three parts. Its runtime — the fourth part, skipped in the “no MCP” framing — is the largest.
Transport. We use Anthropic’s official Node SDK (@anthropic-ai/sdk) but swap its baseURL to an Azure AI Foundry resource — https://<resource>.services.ai.azure.com/anthropic. Foundry exposes an Anthropic-compatible surface, so the SDK’s request shape survives the redirection. Claude Opus, Sonnet, and Haiku (the -4-8 snapshots) are addressed by model ID. In Barnyard this boundary is a single service — OpusService — so every model call in the platform funnels through one swappable seam.
Auth. Instead of an Anthropic API key, we use an Azure AD service principal: a token minted at login.microsoftonline.com against the cognitiveservices.azure.com/.default scope, cached in-process and refreshed five minutes before expiry. This is Microsoft’s identity plane. It provides Azure RBAC, tenancy, and billing. It costs a token exchange on every cold start.
The agent runtime. The loop is ours: OpusService calls Claude via the Foundry endpoint, and a streaming loop reads stop_reason, dispatches tool_use blocks, feeds back tool_result, enforces the 1:1 tool-use↔tool-result contract, and runs up to 25 tool rounds per turn. But the loop does not dispatch to hand-coded functions — it dispatches through an MCP Gateway, Barnyard’s central tool dispatcher, speaking JSON-RPC 2.0 over MCP Streamable HTTP. That gateway is MCP end to end: it aggregates six tool sources into one tools/list per tenant (an internal domain catalog maxsense_*/cvie_*, agent-as-tool wrappers ask_*, external agents over A2A ext_*, retrieval knowledge_search, infrastructure tools platform_*, and upstream MCP servers); its domain tools are first-party MCP servers, not functions (CNC.Mcp.Ingredient, CNC.Mcp.Scenario, CDS.Mcp.Optimizer, and more — .NET services on the Microsoft MCP SDK, each grant-gated); and it already composes with external MCP through an upstream registry that re-exposes any registered server by URL under a name prefix. MCP is Barnyard’s integration layer. What Barnyard does not use is Anthropic’s hosted MCP directory and server-side tools — a narrower gap, and the one this piece explores.
Under that gateway sits the platform the original never mentioned:
- BarnOS Kernel (Rust). A sidecar trust-and-resilience core: a circuit breaker, the
K1–K6trust gates (the SeptalGate governance layer), and mission tracking. When Foundry is unreachable the breaker trips and routes to a fallback — including a local model — rather than failing the turn. Governance is not a prompt; it is a kernel the tool calls pass through. - Maestro continuations. A budget-aware, event-driven research engine — not a chat loop. A continuation carries a
GoalFrame, wakes on data arrival (an overnight Redshift ETL), spends a token budget per tick, and writes findings to a persistent Journal that survives across sessions and canforkinto sub-investigations. Its context service assembles a four-channel field each tick — semantic (RAG), structured (KB), episodic (prior findings), and a live-data channel that auto-queries the warehouse — then reasons over it, calling MCP tools for depth. No managed harness ships this. - Headroom. A platform-wide, reversible context-compression buffer inserted at the gateway dispatcher — one boundary, all six tool backends inherit it — and itself an MCP server. Reversible by contract (originals are never destroyed; the model calls
headroom_retrievefor raw bytes) and built on the principle own the diff, rent the commodity: the compressor is vendored, the trust-governed policy is ours. - Journal Studio. A versioned artifact store (SQL, prompts, MCP tool defs) with a hot-reloading query catalog and promote/rollback — the “edit → test → promote” surface agents and authors share.
- A multi-cloud domain plane. Barnyard’s orchestration runtime runs on AWS EKS, not Azure compute. The model comes from Azure Foundry; the dairy domain data lives in AWS Redshift (the
dmax/ddw/dscvrwarehouse) plus Azure Cosmos and PostgreSQL. Barnyard is already multi-cloud, with a deliberate seam between model, orchestration, and data.
We built an MCP-native agent platform and rent a model to drive it, through Azure.
What Anthropic’s managed agent stack is
Anthropic offers a range from bring-your-own-loop to hosted execution, all first-party:
- Messages API with tool use — the raw primitive. You write the loop and get every capability the moment it ships.
- Claude Agent SDK — a maintained agent harness: tool-use loop, context management, subagents, memory, hooks, permissioning, updated by Anthropic.
- Model Context Protocol (MCP) — an open connector standard. Tools become servers you plug in rather than functions you hand-code, with a growing connector directory. (Barnyard already speaks this — see above.)
- Server-side tools — web search, code execution, and computer use that Anthropic hosts and runs, so the sandbox, browser, and interpreter aren’t yours to maintain.
- First-party platform features — prompt caching, extended thinking, the Batch API, the Files API, and priority-tier latency.
Some of this is an SDK you still run (the harness); some is machinery Anthropic runs (hosted tools, caching, batch). The right read of Barnyard is not that it “reproduces the first category by hand and forgoes the second.” Barnyard runs its own managed harness and its own MCP fabric, and forgoes only Anthropic’s hosted pieces — because a reseller sits between us and them.
The comparison
Advantages of the Foundry path
Enterprise identity and governance. Azure AD service principals, RBAC, tenant isolation, and a single Microsoft invoice matter for an org already on Azure. Data residency and compliance posture inherit from Azure’s regions and certifications.
One vendor pane. If the surrounding infrastructure is Foundry — other models, one billing relationship, one security review — adding Claude to it is less organizational friction than a second vendor.
No new trust boundary. We already trust Microsoft with the tenant. Routing Claude through it adds no vendor to the threat model.
A platform we already own, not just a loop. Barnyard’s agent loop does exactly what we specify — the Headroom compression proxy, depth-capped subagents, memory injection, and a fallback to a local Qwen model when Foundry is unreachable. But the differentiation isn’t the loop; it’s the whole platform under it: the MCP Gateway, the BarnOS trust kernel, Maestro continuations, Headroom, Journal Studio, and the multi-cloud domain plane. A managed harness would have to accommodate these or they would go — and most of them, continuations especially, are not things a generic harness has.
Disadvantages of the Foundry path
Feature latency. New Claude capabilities — model snapshots, extended thinking, computer use, the newest prompt-caching and batch behaviors — reach Anthropic’s first-party API first. Resellers follow on their own schedule, sometimes weeks or months later, sometimes with a subset of features or a different parameter surface. Time on the reseller path is time behind the frontier.
No hosted tools. Anthropic’s server-side web search, code execution, and computer use are first-party constructs, typically absent or degraded through a reseller. Barnyard hand-writes the equivalents to compensate, which means we own the sandbox, the security surface, and the maintenance.
Weaker caching and batch economics. Prompt caching cuts the cost and latency of long, tool-heavy runs — Barnyard’s workload. The Batch API halves cost for non-interactive jobs like the 7am briefing and the scheduled continuation ticks. Both are most current and reliable on the first-party gateway; a reseller may expose them late, partially, or not at all. Headroom and Barnyard’s own caching exist in part to compensate for this.
No hosted MCP directory — not “no MCP.” Barnyard has MCP: a gateway, first-party servers, and an upstream registry that already composes with external MCP servers. What it lacks is Anthropic’s hosted connector directory and the first-party server-side tools that ship as MCP. The gap is real but narrow, and additive rather than architectural: Anthropic’s hosted MCP servers register as upstream sources in the gateway Barnyard already runs. Integrations the ecosystem ships aren’t things we’d rebuild; they’re things we’d register.
We maintain the commodity harness. Anthropic’s Agent SDK is tested against every model release and patched for edge cases in the tool-use contract — max_tokens mid-output, orphaned-tool-use validation, the iteration limit — problems Anthropic has already solved. Ours are patched by us. But the harness is the commodity part; the continuations, the trust kernel, and the compression policy are not, and those are the parts worth owning.
What a switch would unlock long-term
Because Barnyard is already MCP-native, “switch” is nearly the wrong word — the honest question is what Anthropic’s managed layer adds, and where it plugs in. The answer is unusually clean, because the socket already exists.
Hosted tools become upstream MCP tools. Server-side web search, code execution, and computer use are the sandbox, browser, and interpreter Barnyard hand-rolls and secures today. Reached through a first-party path, they register in the MCP Gateway as one more upstream source and appear in tools/list alongside maxsense_* and cnc_* — consumed by the same agents and the same continuations, with no new dispatch code. This retires code we own and a surface we patch. It is the single largest concrete win.
The Agent SDK can take the commodity loop; continuations stay. The generic parts of Barnyard’s loop — the tool-use contract, context management, the iteration guard — are exactly what the Agent SDK maintains against every release. Adopt it for that inner loop and delete the edge-case patches, while OpusService remains the model seam and Maestro continuations remain the outer engine. The SDK does not know how to sleep-wake on an ETL, spend a token budget per tick, or write a forkable Journal — so it wraps the commodity, it does not replace the differentiation.
The connector directory arrives through the registry we already have. Every connector Anthropic (or the ecosystem) ships is an MCP server, and Barnyard’s upstream registry exists precisely to register MCP servers by URL and re-expose them. The directory becomes configuration in a system built to consume it — the tool registry gets bigger without getting bespoke.
First-party caching and batch, alongside Headroom. First-party prompt caching and the Batch API target Barnyard’s exact cost centers: long tool-heavy runs and scheduled, non-interactive jobs (the briefing, the overnight continuation ticks). They don’t retire Headroom — its reversible, trust-governed compression is a different, owned concern — but they take the commodity slice of the cost curve Headroom currently backfills, freeing it to refocus on novel compression.
Day-zero models and features, on release day rather than reseller-integration day. For a product whose value is agentic capability, being current is the product — and the OpusService seam means adopting a new snapshot or tool type is a base-URL and credential change, not a rewrite.
The through-line: none of this is a rip-and-replace. The MCP Gateway was built to aggregate upstream MCP servers; Anthropic’s hosted layer is a set of upstream MCP servers plus an optional harness for the commodity loop. The benefit is additive capability into an existing socket — the cheapest kind of upgrade there is. We keep what is genuinely ours — the memory model, the BarnOS trust kernel, the continuation engine, ecosystem integration — and rent the commodity parts.
Costs of the switch
- A new trust boundary. Anthropic-direct adds Anthropic to the threat model, a second vendor relationship, and a compliance review we don’t currently need.
- Data residency — but Barnyard is already multi-cloud. The framing “residency leaves Azure’s envelope” overstates it: orchestration already runs on AWS EKS and domain data already lives in AWS Redshift. The real constraint is narrower and per-workload — which calls may leave the governed in-tenant path. For those that must stay, Foundry remains the transport; for the rest, the model call already crosses clouds today.
- Lock-in shifts rather than disappears. MCP connectors, hosted tools, and the Agent SDK tie us to Anthropic’s platform the way we’re tied to Azure’s now. The question is which lock-in buys more capability — and MCP being an open standard softens this one, since a registered upstream server is portable in a way a proprietary binding is not.
- Custom behaviors need a home — and they are the keepers. The Qwen fallback, Headroom, depth-capped subagents, the BarnOS trust gates, and Maestro continuations each need re-expressing inside (or alongside) a managed harness or retiring. But these are precisely the differentiators — the “own the diff” half of the principle Barnyard already runs on. They are the reason to keep a runtime at all.
Recommendation
Barnyard’s current architecture was the right call to ship: owning the loop and routing through Azure produced a working agent inside a trusted identity plane, with no new vendor and no new review. And it was never only a loop — it grew an MCP fabric, a trust kernel, and a research engine underneath, which is why the “no MCP” framing was always a misread.
The direction of travel — Anthropic’s and the field’s — is toward managed agents: hosted tools, MCP connectors, maintained harnesses, and first-party features that reach the frontier before any reseller. Barnyard already owns an MCP fabric that these plug into; what it forgoes today is the hosted half.
The practical path is a hybrid, and the architecture makes it unusually natural. Keep Foundry as the governed, in-tenant transport for workloads that must stay in Azure. Open a first-party Anthropic path for the agentic frontier — hosted tools, caching, batch, the connector directory, day-zero models — and register it as an upstream source in the MCP Gateway that already exists, so the same agents and the same continuations consume it without a cutover. Adopt the Agent SDK where the loop is commodity; keep continuations, BarnOS, Headroom, and Journal Studio as the owned differentiators. Route each workload to the path that serves it. When feature latency on the reseller path costs a capability we can’t ship, the switch has already paid for itself — and because the socket is already there, the switch is a registration, not a rebuild.
We built the runtime out of necessity, and more of it turned out to be worth keeping than the earlier telling admitted. The long-term question isn’t whether to stop owning a runtime — it’s to keep owning the diff (the memory model, the trust kernel, the continuation engine, the domain plane) and let someone else run the commodity — the harness, the sandbox, the caches — sooner and for less.
Part of the Univrs research ecosystem:
- Research: metalearn.org · ardeshir.io · sepahsalar.org · univrs.io
- Creative: imagine.univrs.io
- Code: github.com/univrs · github.com/ardeshir