The person most likely to get real leverage from an AI agent is not the person who knows the most prompts. It is the operator who knows what finished work should look like, where the source of truth lives, which exceptions matter, and when the answer is unsafe to use. In a building business, that knowledge usually sits with an estimator, designer, project manager, purchasing lead, controller, or owner who has already lived through the expensive edge cases.

Two recent studies point in the same direction. OpenAI reports that agent use is expanding from engineering into legal, finance, recruiting, operations, and other nontechnical work, including longer tasks and work outside a person's formal job description. Anthropic's analysis of roughly 400,000 Claude Code sessions found that people generally made more of the planning decisions while the agent made more of the execution decisions, and that greater domain expertise was associated with higher success. These studies examine AI-company and coding-agent usage, not construction firms, so their numbers should not be treated as a building-industry forecast. Their operating lesson is still useful: better execution increases the value of better direction.

Execution is getting cheaper. Judgment is not.

An agent can assemble a bid table, draft a client update, compare product documents, organize meeting notes, or prepare a purchasing packet much faster than a person starting from a blank page. Speed does not tell the agent which drawing revision governs, whether an allowance was approved, why one vendor exclusion changes the comparison, or which promise should never appear in a client email.

Those are domain decisions. When the cost of drafting falls, the scarce work moves toward framing the assignment, selecting the evidence, defining acceptance, and reviewing exceptions. The experienced operator does not disappear from the workflow. That person becomes its control layer.

Turn expertise into a reusable job standard

Most expert knowledge is trapped in corrections: the estimator who notices a missing alternate, the designer who catches an incompatible finish, the project manager who rewrites an update because it promises too much. Capture those corrections as operating rules the next run can use.

  • Define the deliverable: name the exact table, checklist, draft, comparison, or approval packet the agent must produce.
  • Name the sources: specify the project folders, revisions, system records, policies, and examples that govern the work.
  • List the exceptions: document the conditions that require a warning, a missing-information request, or human escalation.
  • Set the acceptance test: identify required fields, citations, calculations, tone rules, and reviewer checks.
  • Record the correction: save why a draft was rejected or changed so the failure becomes a future evaluation case.

Use the operator before, during, and after the run

Before the run, the operator defines the artifact and the boundaries. During the run, the agent should show progress, source use, unresolved questions, and current state instead of disappearing behind a spinner. After the run, the operator reviews the high-consequence fields and approves, corrects, or rejects the work.

For a bid comparison, the estimator might define the scope matrix and governing documents before the run, answer ambiguity questions during it, then review exclusions, alternates, totals, and unsupported assumptions afterward. For a selections update, the designer might define the approved schedule and client-facing tone, resolve conflicts while the agent works, then approve every availability or price statement before sending.

Measure whether expertise became leverage

Do not judge the workflow by how much text the agent produced. Track first-pass acceptance, reviewer correction time, missing-field rate, unsupported claims, escalation quality, cycle time, and downstream rework. Compare those measures with the old process. If the expert spends less time assembling routine work and more time resolving consequential exceptions, the agent is creating leverage.

Also watch for a bad trade: faster drafts that create more review burden. An agent that generates ten packets while the only qualified reviewer can inspect two has increased work in progress, not capacity. Limit concurrency to the team's real approval bandwidth and keep the queue visible.

Train experts to supervise systems, not chase prompts

The practical training agenda is workflow literacy: how to specify a deliverable, attach governing sources, define tool permissions, write acceptance cases, inspect evidence, handle uncertainty, and approve an action. Prompt technique helps, but it is a small part of the operating system.

This also changes the first hiring or pilot question. Do not ask which employee is most enthusiastic about AI. Ask which recurring workflow has a knowledgeable owner, a reviewable output, accessible sources, repeated volume, and a measurable definition of good. That is where an agent and an expert can compound each other.

Publish the evidence behind the method

Google says AI Overviews and AI Mode do not require special AI-only schema. Helpful, original, technically accessible content and structured data that matches the visible page remain the foundation. For a building-industry business, the non-commodity proof is the workflow itself: the sources used, the expert rules, the acceptance standard, the exceptions caught, and the measured reduction in rework.

Continue with the operating system

Sources Read

Next step, if this note maps to a problem on your desk: Private Training — a private working session for your team ($1,500+).

Related Field Notes