The vendor proposal sitting on your desk describes a system that "includes AI capabilities." Somewhere in the appendix, or maybe in the slide deck your IT director is reviewing on a second monitor, there is a diagram with an arrow pointing at a box labeled "AI Agent." The proposal says the system will automate intake, or flag anomalies in project cost data, or handle routine subcontractor communications. It sounds like a reasonable description of what you are purchasing. It is not quite that.

What you are actually purchasing, without the vocabulary to negotiate it, is the infrastructure that sits between that model and your firm's operations. That infrastructure has a name in the engineering community. It is called a harness, and the gap between how it appears in a vendor proposal and what it represents as a production system is where most mid-market technology implementations quietly go wrong.

Two Kinds of Agents, and Why the Distinction Is Not Semantic

There is a distinction that Mike Chambers, a senior AI specialist at AWS, draws clearly in a September 2026 practitioner talk, and it is one that almost never makes it into a vendor RFP response. He separates agents into two categories: agents we use, and agents we build.

Agents we use are tools like coding assistants and productivity software, systems designed to serve the person sitting at the keyboard. They are token-maximized, typically running on a single machine, and tuned for one user's workflow. When they behave unexpectedly, that person notices immediately and adjusts. The failure surface is narrow.

Agents we build are different in kind, not just in degree. These are production systems that serve multiple users across an organization, run at cloud scale, maintain state across sessions, and execute actions that have downstream consequences your team cannot easily review in real time. When a project manager queries your AI-assisted scheduling system and it makes a call to an external database, logs a decision, and sends a notification downstream, that is an agent we build. The consequence of a wrong answer is not an awkward conversation with yourself. It is a billing error, a missed submittal deadline, or a subcontractor notification that contradicts what your PM said on the phone last Tuesday.

When a vendor tells you that their system "uses AI," the question that almost never gets asked in the room is which kind. The answer has significant implications for what the implementation actually requires, and for what your contract should say about it.

The Harness: What You're Negotiating Without Knowing It

Chambers offers a definition that is useful precisely because it is mechanical rather than aspirational. Take an agent, he says, and remove the model from it. Everything that remains is the harness. Memory management, tools, MCP servers, loop control, scaling, observability, and evaluation: each one a separate component, each one a separately scalable failure surface, and none of them visible in a typical vendor diagram. (Chambers also references payments and identity as harness components in his full treatment of production deployments; those portions were not included in the excerpts available for this piece, so their specific context has not been independently confirmed here.)

This is not a minor distinction. The model itself, whether it is a frontier language model or a fine-tuned variant, is in many ways the least differentiating part of what a vendor is selling you. Models are increasingly commoditized, available from multiple providers, and swappable in ways that the harness components are not. The harness, by contrast, is the set of engineering decisions that determines whether your agent maintains coherent state across a week of project activity, whether it fails gracefully when an external API goes down, whether someone can audit what it decided and why, and whether it can serve fifty users without degrading to fifty users' worth of parallel confusion.

For a 150-person engineering firm with one person in IT and no dedicated engineering staff for this project, the harness is the implementation. It is what your vendor is actually building when they scope the engagement, and it is what will determine whether the system works the way the demo suggested it would. The demo, almost always, is running against clean data on a machine with no other load, with a harness that has been tuned for the presentation rather than for your operating conditions.

What mid-market AEC buyers rarely understand during procurement, and what the RFP process rarely forces vendors to articulate, is that each harness component represents a design decision the vendor is making on your behalf, usually before the kickoff meeting, often before the contract is signed.

The Components That Should Be in Your Contract

Memory management is where this tends to surface first, because memory is the component users interact with most directly without realizing it. When your project executive asks the system about a subcontractor's performance history and the system responds as though this is the first time anyone has mentioned that subcontractor, that is a memory design problem. Chambers distinguishes between long-term and short-term memory as separately deployed infrastructure components, each scaling independently from the running agent. Whether your vendor has designed those as distinct scalable layers, or collapsed them into a single context window that resets at session end, is a question your RFP almost certainly did not ask.

Loop control is less visible but equally consequential. An agent pursuing a task does not always know when to stop, and a poorly designed loop control mechanism will either halt prematurely, leaving tasks incomplete, or continue past the point where a human would have recognized a dead end and escalated. In a production system handling real project data, both failure modes are expensive. The question is not whether the vendor has thought about loop control. The question is whether they have designed it as a discrete, configurable component that you can observe and adjust, or whether it is baked into the model's prompting in ways that cannot be tuned without rebuilding the system.

Observability and evaluation deserve their own negotiation, because they are the components most likely to be treated as post-launch additions rather than foundational requirements. Chambers makes a specific point about infrastructure-as-code and observability standards: they should be built into the harness from the start to avoid what he calls "slop ops" at scale, a state where a production agent system is effectively unauditable because nobody built the logging infrastructure before deployment. For a firm that needs to demonstrate reasonable care in how it manages project data, an agent system with no audit trail is not a minor oversight. It is a liability question.

Evaluation is related but distinct. Evaluation is the mechanism by which you determine whether the agent's outputs are correct, and it requires separate design from the observability that lets you watch the agent run. A system can be fully observable, with complete logs of every decision, and still have no evaluation layer that tells you whether those decisions were right. Vendors who treat evaluation as a user-acceptance-testing phase, something that happens after go-live, are implicitly telling you that they have not built it into the harness design. That is worth knowing before you sign.

The Room Where the Decision Is Made

The structural problem in mid-market AEC procurement is not that principals and COOs make bad decisions. It is that the decisions with the highest architectural consequence get made before anyone with operational authority is in the room. Vendor scoping sessions, where these harness components get specified or quietly omitted, are usually attended by a sales engineer and whoever the vendor's implementation lead is. On the buyer's side, it is often whoever initiated the conversation: a principal who is interested in the technology, or an operations manager who was asked to evaluate the proposal. The person who will live with the memory architecture for the next three years is rarely there.

The way to change this is not to add more people to scoping calls. It is to arrive with better questions, specifically the kind that require a vendor to describe their harness design in terms you can evaluate before you sign anything.

What to Ask Before the Contract Goes Out

Ask the sales engineer to describe how the system manages memory across sessions, and listen for whether they distinguish between short-term and long-term memory as separately deployed components or describe it as a single context that the model maintains. The latter answer tells you something important about how the system will behave after six months of production use.

Ask what happens when the agent's loop encounters a task it cannot complete. A vendor with a thoughtful harness design will be able to describe the specific mechanism: how many iterations before escalation, how the system signals that it has stalled, and who receives that signal. A vendor without one will describe the model's general tendencies.

Ask how the system logs its decisions, and whether that logging is built into the harness from the start or added as a reporting layer after deployment. Then ask whether those logs are accessible to you, in what format, and whether they capture enough context to reconstruct why the agent made a specific choice on a specific date. Your answer to the liability question depends on theirs.

Ask whether evaluation is part of the initial implementation scope or a phase-two item. If it is phase two, ask what you are supposed to use to determine whether the system is performing correctly between go-live and phase two. The silence that follows that question is itself an answer.

Ask, finally, how the harness components scale independently. You are not asking because you expect a 150-person firm to be running at cloud scale on day one. You are asking because the answer tells you whether the vendor has actually built these as discrete components or has shipped you a demo harness with a production price tag.