AI Technology Brief

Which LLM and coding agent should a construction business use? Start with the operating role

StructuredLayer evaluated an architecture for selecting language models and coding agents according to the business task, authoritative context, permitted tools, deployment boundary, cost, failure consequence, and human approval. This is architecture evaluation, not a claim that one model has been deployed across a client. A model can draft or reason; a coding agent can inspect repositories and execute tools; neither becomes the company's source of truth or accountable decision-maker.

Published by StructuredLayerImplementation guidance22 July 202627 min read

StructuredLayer AI Technology Brief showing an approved construction business task routed through a governed model and coding-agent registry into source-linked answers or tested code, validation, security review, exceptions, and human-approved business use. — Conceptual StructuredLayer architecture showing an approved construction business task routed through a versioned LLM and coding-agent registry into source-linked answers or tested code, deterministic validation, security review, exceptions, and accountable approval.

01 / Independently verifiable claims

Begin with what the technology and standards actually support.

Claude Fable 5 is an official Anthropic model and is available through Claude and Claude Code. Claude Opus 4.6, Claude Sonnet and Haiku 4.5, Claude Sonnet 4, Claude 3.7 Sonnet, and Claude 3.5 Haiku are different generations and tiers with lifecycle and cost implications.
OpenAI officially documents GPT-5.6 Sol, Terra, and Luna, GPT-5.2, GPT-5, GPT-5 mini and nano, GPT-4.1 and its mini and nano variants, GPT-4o and mini, o1, o1-mini, and o4-mini, and open-weight GPT-OSS 20B and 120B families. Exact availability and recommendations change.
Google officially documents Gemini 3.1 Pro Preview, Gemini 3 Pro, Gemini 2.5 Flash, and related model lifecycle. Preview aliases require change control.
DeepSeek R1, V3, and V3.1; Qwen3 235B MoE instruction models; Kimi K2.5; IBM Granite 3.3 and Granite Speech 4.1; Llama 3 and later families; Gemma; StableLM; FLAN-T5; and LLaVA represent reasoning, instruction, speech, open-weight, legacy, or multimodal roles with different licences and deployment requirements.
Claude Code and Codex CLI can operate against local repositories, edit files, and run tools installed on the user's machine. Codex Cloud is a separate delegated environment rather than the same execution boundary.
OpenAI distinguishes Chat for conversational help, ChatGPT Work for longer research, analysis, document, spreadsheet, presentation, report, and site tasks, and Codex for software engineering and technical work. These are different task surfaces rather than one universal agent mode.
OpenAI defines a skill as reusable instructions and resources, an app as a connection to external data or actions, and a plugin as a distributable workflow package that can contain skills, apps, and app templates. Installation does not replace source-system permissions, workspace administration, or action approval.
OpenAI documents remote access to Codex from ChatGPT mobile while execution remains on the connected trusted laptop, devbox, SSH host, or managed environment. Files, credentials, permissions, and local setup remain on the execution machine; remote control does not turn that machine into a cloud sandbox.
OpenAI documents Codex local execution, remote-machine execution, and isolated cloud execution as distinct boundaries. Each requires its own filesystem, identity, credential, network, approval, logging, and recovery assessment.
Anthropic states that Claude Code runs locally but sends prompts, model outputs, relevant code or file contents, and other required context over the network to the configured model provider. Local tool execution does not mean on-device model inference or that all project information remains on the computer.
Claude Code Auto Mode can automatically approve tool calls classified as lower risk and block or escalate calls classified as potentially destructive. Provider classification is useful triage, not a complete company authorization policy or permission to perform a consequential business action.
Claude Code Channels is a research-preview route for pushing messages, alerts, webhooks, and chat events into a running session and supporting replies through configured channels. Sender authorization, session and project routing, message provenance, duplicate and replay handling, tool permissions, remote approval, reply authority, expiry, and recovery remain deployment responsibilities.
Claude Code, OpenAI Codex, Gemini CLI, GitHub Copilot cloud agent, Cursor, Devin Desktop or Cascade, Aider, and Cline are coding applications or agents. They can read repositories, modify files, execute commands, call tools, and sometimes use networks; they require stronger controls than chat-only use.
Catalogue run counts and labels such as most intelligent, best for coding, fastest, flagship, leading, or on par are not independent construction or software-delivery benchmarks.

OpenAI task and execution surfaces · reviewed 12 August 2026

Chat, Work, Codex local, remote, and cloud are different operating boundaries.

OpenAI now documents broader knowledge-work capability alongside Codex software delivery. Buyers still need to select the correct surface by task, source access, execution location, permissions, actions, evidence, and review rather than treating every interface as one agent.

Discuss

Chat

Use for bounded questions, searches, and brainstorming with approved context. A conversation does not establish repeatable workflow state, source authority, or accepted business action.

Produce

ChatGPT Work

Use for longer research, analysis, documents, spreadsheets, presentations, reports, and sites. Generated files remain drafts until sources, formulas, claims, formatting, rights, and release are reviewed.

Build

Codex on a trusted machine

Codex can use local or SSH-hosted files, repositories, terminals, tools, credentials, and permissions. Mobile access can control that session, but execution and its authority remain on the connected machine.

Delegate

Codex Cloud

Cloud tasks run in a separate isolated hosted environment. Repository access, setup, internet policy, identities, secrets, logs, review, handback, and recovery require separate configuration.

Connect

Apps and plugins

Apps connect external data or actions; plugins package skills, apps, and templates. Source-system permissions and workspace controls still govern what can be read or changed.

Repeat

Skills and automations

Skills package reusable procedure and resources; automations schedule or trigger work. Version, dependencies, execution availability, limits, approvals, monitoring, interruption, and ownership remain explicit.

02 / The practical distinction

Choose the interface from the task, context, permissions, evidence, and operating responsibility.

No personal usage ratio establishes the right interface for a construction business. Compare source volume, read and write scope, duration, repeatability, deterministic tooling, audit evidence, review capacity, deployment boundary, and maintenance ownership.

Narrow

Chat

Useful for a bounded question with limited approved inputs. Context is manually assembled, repeatability is weak, and uploaded content follows provider controls.

Deliverable

ChatGPT Work

Prepares research, analysis, documents, spreadsheets, presentations, reports, and sites. Review sources, formulas, revisions, file integrity, rights, and release before business use.

Build

Codex local or remote

Uses files, terminals, Git, tests, packages, apps, plugins, skills, and sometimes networks on an approved execution machine. Remote mobile control does not change that machine's authority boundary.

Delegate

Codex Cloud

Runs a task in a hosted isolated environment. Treat repository access, setup, internet, credentials, results, and handback as a separate controlled deployment.

Repeat

Governed workflow

Runs recurring work through stable records, deterministic rules, queues, validation, approvals, exceptions, monitoring, recovery, and operating ownership.

Persistent

Automation

Performs scheduled or event-driven activity over time. Identity, execution availability, source permissions, separate read and write authority, spending limits, interruption, audit, and recovery must be explicit.

03 / Operating architecture

Use one governed registry for models, coding agents, tools, and approved tasks.

StructuredLayer's evaluated pattern routes each task to an eligible capability and preserves enough evidence to replace the model or application later.

Approved task

Business purpose, user, workflow, source records, documents or repository, expected output, consequence, and human owner.

Model and app registry

Official model ID, coding application, version, context, tools, deployment, data controls, lifecycle, licence, cost, and approved task.

Controlled execution

Permission-aware retrieval, prompt, schema, sandbox, tool allowlist, network policy, secrets boundary, limits, tests, and logs.

Reviewed outcome

Sources, answer or diff, validation, test results, security review, exception, approval, release, monitoring, and rollback.

04 / Required records

Every answer or code change needs source, configuration, validation, and ownership.

Task request

Workflow, purpose, requester, project, sources, repository, output, deadline, consequence, reviewer, and release condition.

Model selection

Official ID, version, tier, reasoning, context, deployment, region, retention, training setting, tools, limits, and cost.

Agent environment

Chat, Work, Codex local, SSH, managed remote, or cloud surface; execution machine; repository; branch; sandbox; filesystem; network; apps; plugins; skills; MCP servers; commands; packages; identities; credentials; and secrets policy.

Run record

Prompt, retrieved sources, tool calls, files read, commands, network actions, output, diff, tokens, duration, warnings, and cost.

Validation

Schema, citations, business rules, tests, lint, type checks, security scans, peer review, acceptance, and exception state.

Release

Approved answer, record, pull request, workflow, deployment, owner, timestamp, monitoring, rollback, documentation, and handover.

05 / Construction example

Approve the rules, specification, plan, and tasks before the coding agent implements.

These four versioned artifacts reduce improvisation and make scope reviewable. They remain implementation controls, not proof that the requirements or resulting software are correct.

Approve project rules

Define simplicity, accessibility, data handling, security, dependency, testing, and ownership rules that every feature must follow.

Specify behavior

State users, required behavior, acceptance scenarios, edge cases, prohibited actions, and explicit non-goals without prescribing implementation.

Clarify

Resolve ambiguity around identity, authority, integrations, data, failure behavior, and acceptance before code is prepared.

Approve the plan

Define architecture, data, interfaces, dependencies, security, migration, tests, rollback, and how the plan complies with the project rules.

Approve the tasks

Break the plan into dependency-ordered, reviewable work linked to requirements and acceptance cases.

Implement incrementally

Prepare small code, test, documentation, and configuration changes in a bounded branch or environment.

Verify independently

Run deterministic tests, security checks, source checks, human review, and end-to-end acceptance cases.

Release and converge

Approve separately, monitor, compare the system with the specification, and record gaps, corrective work, or rollback.

06 / Deterministic controls

Treat coding agents as privileged automation with a developer-sized blast radius.

Sandbox by default

Use disposable environments, nonprivileged identities, restricted filesystem, resource limits, and default-deny network access.

Keep secrets inaccessible

Exclude environment files, private keys, production credentials, cloud profiles, client data, and unrestricted tokens; use short-lived task identities.

Allowlist tools and MCP

Approve commands, packages, repositories, network destinations, APIs, and MCP servers; validate tool arguments and configuration changes.

Treat reusable procedures as environment-specific

Version the instructions, templates, examples, schemas, commands, tools, permissions, dependencies, and tests required by each approved agent environment. A procedure package that can be opened elsewhere is not automatically interoperable or behaviorally equivalent.

Approve the plan before execution

Review scope, non-goals, files, data sources, transformations, dependencies, migrations, commands, tests, rollback, and release boundary before allowing implementation. A generated plan that no accountable person reads is not a control.

Control packages and generated artifacts

Pin approved dependencies, verify provenance and licence, install only inside the authorized environment, inspect generated files and configuration, and prevent automatic commits or broad accept-all actions from becoming release approval.

Review data transformations semantically

For SQL, pipelines, metrics, reports, or notebooks, inspect grain, joins, filters, sources, definitions, null handling, cardinality, reconciliation, and downstream effects. Compilation and passing configured tests do not establish correct business meaning.

Keep authorization outside Auto Mode

Treat automatic approval as provider risk triage inside a narrower external policy. Independently enforce repository, path, command, network, credential, spending, production, and business-action limits, and test allowed, blocked, ambiguous, indirect, and chained actions.

Govern persistent Channels

Authorize senders and channel adapters, bind every event to the correct organization, project, session, and work item, preserve message and reply provenance, reject duplicates and replay, constrain tools, expire stale sessions, and require explicit authority for external replies or consequential actions.

Assume prompt injection

Treat issues, comments, documents, websites, terminal output, dependencies, and repository instructions as untrusted content.

Independent testing

Do not allow the agent to weaken tests or define its own acceptance. Require human review for security, auth, infrastructure, dependencies, and CI/CD.

No direct production authority

Block production systems, payments, building controls, operational technology, client records, deployments, and consequential decisions without explicit approval.

Re-verify every release

Confirm the exact model, harness, access route, lifecycle, pricing, data terms, tools, and supported execution boundary from current primary documentation. Treat rankings and demonstrations as investigation signals, not task acceptance.

07 / Failure analysis

The strongest model can still act on the wrong source, tool, permission, or acceptance rule.

Confident unsupported answer

The response can be fluent while using stale, incomplete, conflicting, or unauthorized context.

Wrong model alias

Preview and latest aliases can change behavior, context, cost, safety, and tool support without an obvious workflow change.

Prompt injection

Repository files, tickets, websites, documents, dependencies, tool output, channel messages, alerts, and webhook payloads can manipulate the agent into unsafe actions.

Approval misclassification

A nominally lower-risk tool call can have destructive or consequential effects through arguments, current state, chained actions, credentials, indirect writes, or the wrong project context.

Persistent-session confusion

A delayed, duplicated, replayed, unauthorized, or misrouted channel event can act on stale state or the wrong repository, project, work item, user, or recipient.

Secret exposure

An agent can read files ignored by Git, echo credentials to logs, transmit sensitive context, or include secrets in code and commits.

Plausible broken code

Generated code can pass superficial review while failing edge cases, permissions, concurrency, migration, security, or recovery.

Green pipeline, wrong meaning

Generated SQL or transformations compile and pass configured tests while duplicating values, using the wrong grain, applying incorrect filters, selecting the wrong authority, or redefining a business metric.

Self-repair becomes assurance

An agent diagnoses and changes its own failed implementation, then labels the pipeline reliable without independent review, representative regression cases, reconciliation, monitored operation, or accepted recovery evidence.

Automation of the wrong process

A correct implementation can still encode unclear ownership, bad records, weak approval, or unsupported business rules.

Vendor and tool dependency

Agent applications, models, extensions, MCP servers, cloud environments, pricing, and terms can change or disappear.

Authority confusion

A generated estimate, contract interpretation, safety recommendation, design response, or payment decision may be mistaken for professional approval.

08 / Deployment and cost

Choose hosted, open, or hybrid models separately from the coding application.

Hosted frontier models

Fable, Claude, GPT, Gemini, Kimi, and other services can provide broad capability; review exact model, region, retention, training, tools, price, availability, and exit.

Open and private models

GPT-OSS, DeepSeek, Qwen, Granite, Llama, Gemma, StableLM, FLAN-T5, and related models add hardware, serving, licences, security, evaluation, and maintenance.

Local coding applications

Claude Code, Codex CLI, Gemini CLI, Cursor, Aider, Cline, and Devin Desktop can operate against local repositories and tools. Local access still needs sandboxing, permissions, network, provider-data, and secrets controls.

Cloud coding agents

Codex Cloud and Copilot cloud agent can work in isolated hosted environments and create pull requests; repository access, setup, internet access, identities, secrets, and review remain critical.

Input, output, cached, reasoning, image, audio, tool, search, and long-context usage
Coding-application plans, cloud environments, parallel agents, repository indexing, storage, and network
Open-model GPU, serving, scaling, weights, licences, monitoring, patching, and support
Source preparation, retrieval, schemas, prompts, tests, evaluation, security review, and human correction
Sandboxing, secrets, identities, MCP governance, dependency review, CI/CD, audit, and incident response
Integration, deployment, monitoring, rollback, documentation, training, handover, model replacement, and exit

09 / Evaluation

Measure accepted construction outcomes and software changes, not model reputation.

Answer accuracy, source coverage, citation correctness, conflicts, unsupported additions, and abstention
Structured-field accuracy, schema validity, business-rule results, and exception routing
Code correctness, tests, type checks, lint, security scans, migration safety, performance, and recovery
Tool-call accuracy, permission enforcement, prompt-injection resistance, secrets handling, and network behavior
Human correction time, reviewer agreement, critical errors, and accepted output rate
Latency and complete cost per accepted answer, record, pull request, workflow, or deployment
Repeatability and regression after model, alias, prompt, tool, MCP, package, repository, or source change
Production incidents, rollback, monitoring, documentation, client ownership, and provider portability

10 / Controlled pilot

Prove the operating boundary before expanding it.

1. Define the problem

Name intended users, business decision, expected result, failure consequence, source boundary, prohibited actions, and explicit non-goals before generating an interface or code.

2. Build a bounded prototype

Use synthetic or explicitly approved test data in an isolated environment with no production credentials, live external actions, or assumption that generated architecture is production-ready.

3. Observe representative users

Record workflow sequence, missing information, confusing states, repeated actions, accessibility barriers, operating context, and recovery behavior through appropriately selected real participation.

4. Create a discovery register

Connect each observation to source evidence, affected role and step, proposed requirement, reviewer, decision, rationale, owner, status, and next test. Mark requirements accepted, rejected, deferred, or unresolved.

5. Specify invisible controls

Add separation of duties, restricted fields, cross-project boundaries, duplicate prevention, calculations, concurrency, migration, retention, security, incident, and recovery requirements that a user walkthrough may not expose.

6. Convert requirements into tests

Define allowed, prohibited, boundary, wrong-user, wrong-project, missing-approval, duplicate, failed-integration, interruption, rollback, and regression cases before implementation acceptance.

7. Approve the implementation plan

Review files, components, data model, dependencies, integrations, migrations, security controls, testing, monitoring, rollback, tasks, and release boundary before execution.

8. Implement incrementally

Prepare small reviewable changes linked to approved requirements and tasks. Preserve deviations, diffs, tool calls, test results, errors, retries, corrections, and unresolved exceptions.

9. Verify independently

Separate development from functional, security, data, permission, accessibility, operational, and representative-user acceptance. The agent does not define or approve its own release evidence.

10. Authorize production separately

Approve production architecture, credentials, live data, migration, users, tools, integrations, monitoring, training, support, incident response, rollback, and named release authority as a distinct decision.

11 / StructuredLayer recommendation

Prototype quickly to discover the workflow. Specify what was learned. Test what users cannot see. Verify independently. Authorize production separately.