An Agent Can Find the Button. Who Decides Whether It Should Press It?

A procurement assistant finds the correct product, fills the order fields and reaches the final action. From a software demonstration’s perspective, the hard part appears to be over. From the project manager’s perspective, the important questions have barely started.

Is this the approved specification? Is the quotation still valid? Does the selected delivery date suit the installation sequence? Has somebody already ordered the same item? Is the person using the agent authorised to commit that amount?

This hypothetical example is why business experience belongs in AI system design. The interface can be technically clear while the decision remains commercially wrong.

WebMCP changes the interface, not the need for judgement

Our earlier article, WebMCP and the New Digital Citizen, examines websites exposing structured actions to agents. “Digital citizen” is a metaphor for delegated software, not a legal status or an independent right to act.

Chrome’s WebMCP documentation describes a proposed web standard through which sites expose structured tools, using JavaScript and annotated HTML forms. It remains important to distinguish the proposal from universal browser support. WebMCP should also not be treated as interchangeable with every server-side MCP integration.

The opportunity is a clearer interaction contract. The business still has to decide which actions it exposes, what evidence they require and how permission is checked. A tool description is neither a substitute for authentication nor an approval to spend money.

The happy path is an incomplete specification

A team can specify an order workflow that behaves perfectly when the supplier responds, stock exists and all information agrees. Real operations include stale quotations, conflicting revisions, duplicate requests and uncertain outcomes after a timeout.

An adviser who understands those situations can help engineers distinguish states that a generic “success” message would collapse. Prepared is not approved. Approved is not dispatched. Dispatched is not accepted. An unknown result is not automatically a failure that should be repeated.

In our illustrative order workflow, a sensible design might allow an agent to search approved items and prepare a draft. A separate server-side check would validate the user’s authority, current price and required approval before commitment. If the response is lost, the system should reconcile the existing request before retrying an action that might create a second order.

These are proposed engineering controls, not claims about automatic protections supplied by WebMCP or features already delivered by TEMRIK.

Turn experience into acceptance scenarios

Experience becomes valuable to an implementation team when it produces tests they would otherwise miss. Ask the commercial adviser, project manager and engineer to walk through the same task together.

Google’s WebMCP workflow-design guidance recommends mapping user journeys and walking through the interaction to find missing information and tools. The construction-specific scenarios above are an application of that approach. They need project-level design and testing rather than acceptance on the strength of a protocol name.

Learn from success without hard-coding yesterday’s assumptions

A difficult job teaches where control was missing. A successful job teaches which sequence, information and decisions helped the work proceed. Neither should be copied without examining its conditions.

A procurement method that worked with a reliable local supplier may need different checks for a long overseas lead time. A supervisor’s informal approval habit may be unsuitable when the organisation doubles in size. Capture the reason a method worked, its limits and the person responsible for reviewing it.

That is the qualification I would look for in construction AI advisors: the ability to turn delivery knowledge into explicit operating requirements, working with engineers who can enforce and test them. The useful combination is commercial experience, technical competence and honest evaluation.

From rules for peace to bounded tools

The TEMRIK Peace guide sets out construction principles around preparation, evidence and controlled disagreement. Its playbook structure separates inputs, checks, assistance, exceptions, human decisions, actions and retained evidence. That separation is a practical starting point for defining what an agent may prepare and what a person must authorise.

The public TEMRIK construction playbooks can be downloaded and examined. Their instructions do not enforce security by themselves. A connected implementation must supply actual tool restrictions, project permissions and approval checks.

The Failure Intelligence guide adds the commercial consequences: delay, margin pressure, poor information and other problems that a narrowly technical demonstration can overlook. These publications are educational resources, not evidence that a particular agent prevents disputes or business failure.

Judge the system by what it does under pressure

The NIST AI RMF Playbook offers voluntary, adaptable actions for managing AI risk. The CIOB AI Playbook adds construction-focused context. Neither endorses this article’s publisher or a particular product.

For the first pilot, measure successful authorised completions, review effort, missing evidence and unsafe attempts stopped. Include a recovery exercise. Ask a competent user whether the result is usable, rather than allowing the agent to grade its own work.

An agent-ready business needs more than discoverable tools. It needs the experience to define a worthwhile action, the engineering to enforce its boundaries and the discipline to learn from what happens next.