Agents for Specifications

A specification is the written half of the contract documents: the part that defines quality, performance and workmanship where the drawings define geometry. It is organised, sectional and heavily patterned - most practices work from a master specification, a library of standard sections that get edited down to the project. That structure is exactly what an agent handles well: reading the model and schedules to see what has actually been specified, pulling the relevant master sections, editing them to match the project, and keeping the whole document internally consistent and aligned with the drawings.

So the agentic opportunity in specs is real and specific. An agent can draft sections from the model - if the schedule says these are the door types with these ratings, draft the corresponding door specification. It can maintain consistency: when a finish changes on the drawings, flag or update the spec section that still names the old one, so the two documents do not drift apart across revisions - a notorious source of site disputes. It can assemble and tailor from your master library faster than manual editing, and cross-check the spec against itself and the drawings for gaps, contradictions and orphaned sections. Handled well, this compresses a slow, error-prone chore and keeps the spec and the drawings coordinated as a living pair rather than two documents that agree only on the day they are issued.

But notice the shape of the danger even in the good cases. The agent's job here is to be grounded in trusted material - your master spec, verified product data, the actual schedules - and to edit and coordinate it, not to generate technical facts from its own memory. The moment an agent is asked to supply a figure, a standard or a product it has not been given - 'what fire rating does this partition need', 'which standard governs this', 'name a suitable waterproofing product' - it will answer fluently from a model that mixes real knowledge with plausible invention, and in a spec that is precisely the failure that hurts. The discipline, then, is to use agents to operate on trusted sources, and to treat anything they produce beyond those sources as a claim to verify.

Every lesson in this course insists on verification, but specifications concentrate the risk more than almost anything else an agent produces, for three reasons. First, the failure is invisible. A wrong number in a spec looks exactly like a right one - '60 minutes fire rating', 'U-value 1.6 W/m2K', 'to IS 2645' - all read as authoritative whether or not they are true. Unlike a drawing clash, a fabricated performance claim does not look wrong; it looks finished. Second, the claim is binding. A spec is priced and built against; a fabricated or outdated figure does not stay a document error - it becomes a mispriced tender, a rejected product, a system that fails its test, or a safety shortfall, all traceable to your commitment. Third, agents fail here in a specific, well-documented way: they hallucinate. A language model will confidently produce a standard number that does not exist, a product that was discontinued, a performance figure it has essentially guessed, and it will do so in the same fluent register as its correct output (Module 8.1).

Think about the concrete forms this takes. An agent asked to specify a product may name a real manufacturer but attach a model that does not exist, or a real product with an invented performance figure, or cite a standard by a plausible-but-wrong number, or reference a code clause that was superseded or withdrawn - the sort of thing that bites hard in India, where, for example, the NBC and many IS standards are periodically revised and an agent's training data may name an edition that is no longer current. Each of these is fluent, specific and wrong, and each becomes a real problem the moment it is issued.

The corrective is not to distrust the agent's writing - its prose and structure are genuinely useful - but to draw a hard line between language it composes and facts it asserts. The composition you can accept and edit; the facts you must verify, every one, against a real and current source: the manufacturer's own datasheet, the actual text of the standard, the live product listing. A spec claim that traces to a verified source is yours to make; a spec claim that traces only to the agent's confidence is a liability wearing the costume of a fact.

The way to get the benefit without the hazard is to change what you ask the agent to do: not 'write me a specification' but 'draft this specification from these trusted sources and flag anything you cannot ground.' Two techniques carry most of the weight. Grounding - giving the agent the real material to work from - and consistency-checking - using the agent to keep documents aligned rather than to originate facts.

Grounding means the agent works from your master specification, your verified product datasheets, the actual project schedules, and the current text of the standards you rely on, rather than from its own memory. This is retrieval-augmented generation applied to specs (Module 2.3): the agent retrieves from trusted, current documents and composes from them, so its output is traceable to a source you control instead of to a training-data guess. A well-grounded spec agent, asked for a product's fire rating, quotes the datasheet you gave it and cites where it found it; an ungrounded one invents a number. The difference is not the model's intelligence but what you put in front of it - and the practical upshot is to maintain a curated, current library of trusted spec sources and point the agent at it, refreshing it as standards and products change.

Consistency-checking is the other high-value, low-risk use. Because a spec and a drawing set must agree, and both change through a project, keeping them coordinated by hand is thankless and error-prone. An agent can continuously cross-check: does every finish on the drawings have a spec section; does every spec section correspond to something drawn; do the schedules, drawings and spec agree on ratings, types and quantities; has a revision left a stale clause behind. As with drawing coordination, these are prompts to look, not verdicts - the agent finds candidate discrepancies and you judge them. Even so, this is one of the most valuable things an agent does for a spec, because it catches the drift between documents that causes so many site disputes, while asking the agent to do what it is good at - reading and comparing existing material - rather than what it is dangerous at, which is asserting facts it was never given.

A specification is a commitment made under your name to a client, a contractor and, ultimately, the people who will use the building. That is the frame that decides how you use agents on it. The agent can accelerate the drafting and coordination enormously, but the transition from 'the agent wrote it' to 'we are promising it' has to pass through your verification, and specifically through the verification of every performance claim and product fact the document asserts.

Make that a real, structured step, not a skim. For each specified product, confirm it exists, is current and is available - a discontinued product in a spec is a change order waiting to happen. For each performance figure, confirm it against the manufacturer's own current datasheet, not the agent's paraphrase. For each cited standard or code, confirm the number and the edition are correct and in force - especially in the Indian context, check that an IS code or an NBC provision has not been superseded, because an agent will happily cite a withdrawn edition in the confident present tense. And for anything touching life safety - fire ratings, egress, structural performance - treat the agent's contribution as a first draft to be checked against the governing document and, where it matters, a qualified specialist, never as an answer to trust.

The deeper discipline is the same one that runs through the whole course, sharpened by the stakes: you must understand the spec you issue. A specification you cannot stand behind because you did not verify its claims is not a document you have delegated - it is a liability you have adopted blind. Use agents to carry the drafting, the assembly from your master, and the relentless consistency-checking against the drawings; lean on them to make the spec faster and better-coordinated than you could manage by hand. But hold the line exactly where it belongs: the words the agent composes are a draft; the facts it asserts are unverified until traced to a real, current source; and the promises in the finished document are yours, made under your name, verified by you before they bind.