Wrong vocabulary costs you two agent contracts instead of one

A new Hugging Face glossary for AI agent terminology landed quietly last week, and it's more useful as a procurement filter than as a tutorial. If your team can't agree on what layer a vendor actually sells, you will buy overlapping infrastructure — and you probably already have. The vocabulary gap between "harness," "scaffold," and "runtime" is where duplicate spend hides.

What changed in how the industry defines agent infrastructure

The Hugging Face agent glossary draws hard distinctions between terms that the industry had been using interchangeably. A harness is a testing and evaluation wrapper — it runs your agent through scenarios and measures behavior. A scaffold is the structural layer that sequences agent steps, manages tool calls, and handles control flow. A runtime is the execution environment: memory management, concurrency, state persistence. These are three different problems, three different vendor categories, and three different build-vs-buy decisions.

The confusion is not accidental. Most vendors selling "agent platforms" bundle two or three of these layers without labeling them separately. A vendor pitching an "agent orchestration platform" may be selling you a scaffold, a runtime, or both — and their sales deck will not volunteer the distinction. The same conflation shows up in open-source projects: frameworks like LangGraph, AutoGen, and CrewAI each emphasize different layers, which is why teams that adopt two of them discover significant overlap only after integration is underway.

The glossary also clarifies two adjacent terms: tool use (the mechanism by which an agent calls external APIs or functions) and agent memory (short-term context versus long-term retrieval). These are capabilities, not layers — they live inside the scaffold or runtime depending on implementation. Treating them as layers leads to a third category of redundant purchasing: buying a "memory solution" from a vendor when your scaffold already ships with one.

Why this changes the math on agent ownership for a 50–500 FTE team

At your company size, you are not building everything from scratch and you are not buying a monolithic enterprise suite. You are assembling. That means the build-vs-buy line is not one decision — it is three decisions made at three different layers, and they have different risk profiles.

The harness layer is almost always a buy or open-source decision. Evaluation frameworks are commodity infrastructure; building a custom one is rarely justified unless your domain has compliance requirements that off-the-shelf tools can't satisfy. The runtime layer is high-stakes: state management, persistence, and concurrency failures surface in production, not in demos. This is where most teams underestimate build cost. A scaffold, by contrast, is where your business logic lives — the sequencing of steps that reflects how your process actually works. That logic is often worth owning, even when the runtime underneath it is not.

The practical consequence: when a vendor proposes to "handle your agent infrastructure," the right question is not "how much does it cost" but "which of the three layers does this cover, and what does the contract say about the others?" Teams that skip that question buy a scaffold from vendor A, discover they still need a runtime, buy that from vendor B, and find six months later that vendor A's scaffold has an opinionated runtime embedded that now conflicts. We have seen this play out across multiple client engagements. The vocabulary is the due diligence.

Talk to Domani AI about building this →

What a CTO does this week to stop buying infrastructure twice

Run a 90-minute internal audit before your next vendor call. The goal is a one-page layer map: what do you currently own or operate at the harness, scaffold, and runtime layers? Most teams discover they have partial coverage at two layers and nothing at the third. That gap is what your next vendor call should address — specifically and only that gap.

Then apply this decision tree to any vendor proposal in your pipeline:

• Does the vendor clearly label which layer(s) their product covers? If not, require it in writing before the next call.
• Do you already have partial coverage at any layer they're selling? If yes, ask for a scoped contract that excludes what you already own.
• Is the vendor's scaffold opinionated about the runtime? If yes, that is a lock-in risk. Get the decoupling terms in the contract or price in the migration cost.
• Is your core business logic embedded in the scaffold? If yes, own that layer. Contract the harness and runtime.
• Is this primarily a testing/evaluation need? Then you need a harness, not a platform — and you can likely satisfy it with an open-source tool in under 2 weeks.

If you are currently mid-evaluation with an agent vendor and have not mapped their product to these three layers, pause the commercial conversation and do the mapping first. One hour of internal alignment saves 6 months of re-architecture.

What this costs — and what it saves

The mapping exercise costs roughly 4 hours of a senior engineer's time and 90 minutes of yours. If you engage an outside architecture reviewer, expect half a day of billable time. That is the full cost if you do it before signing. If you do it after, the cost is the duplicate contract, the integration work to reconcile two runtimes, and the engineering time lost to a migration you could have avoided — typically 3 to 8 weeks of a small team's capacity, based on what we see in post-mortem engagements.

The save is not just money. It is optionality. Teams that own their scaffold layer and contract everything else retain the ability to swap runtime vendors when pricing changes or when a better option ships. Teams that buy a bundled platform without understanding the layers tend to discover they own nothing separable — and renegotiate from a weak position. In a market where agent infrastructure pricing is still volatile and vendor consolidation is ongoing, that optionality has compounding value.