Module 3: Agentic Engineering Architecture and Prompt Framework

Learning Objectives

  • Translate a civil engineering objective into a controlled agentic workflow specification.
  • Define evidence, context, tools, permissions, state, outputs, verification, stop conditions, and human approval explicitly.
  • Distinguish instruction, evidence, tool, execution-state, evaluation, and decision-authority layers.
  • Design reusable workflow contracts with schemas, bounded memory, tool boundaries, and machine-checkable outputs.
  • Establish traceability for repeated professional and automated engineering workflows without confusing model memory with authoritative project records.

Agentic Engineering Workflow Specification

An agentic engineering workflow specification is a controlled description of an engineering objective that defines the approved evidence, assumptions, tools, permissions, methods, outputs, verification requirements, stop conditions, and human authority governing the AI-assisted process.

Civil Engineering Prompt Framework

The Civil Engineering Prompt Framework is the instruction layer of an agentic engineering workflow. It expresses the task through ten core elements: discipline, objective, known data, source authority, assumptions, required method, output format, verification requirements, limitations, and human approval.

The Ten-Element Framework

Use the following sequence:

1. ROLE / DISCIPLINE
2. ENGINEERING OBJECTIVE
3. KNOWN DATA
4. GOVERNING STANDARD / SOURCE AUTHORITY
5. ASSUMPTIONS ALLOWED AND PROHIBITED
6. METHOD / CHECKS REQUIRED
7. OUTPUT FORMAT
8. VERIFICATION REQUIREMENTS
9. LIMITATIONS / STOP CONDITIONS
10. HUMAN APPROVAL / FINAL DECISION OWNER

The framework is vendor-neutral and can be used with a conversational model, research system, code agent, connected workspace, or multi-step agent.

Agentic Engineering Workflow Specification

The prompt framework sits inside a larger controlled engineering workflow.

Follow the workflow from a bounded engineering objective through evidence, tools, verification, and human ownership.

Agentic Engineering Workflow SpecificationThe prompt framework sits inside a larger controlled engineering workflow.. Bound the engineering objective → Identify approved evidence and source authority; Identify approved evidence and source authority → Write prompt and agent contract; Write prompt and agent contract → Execute approved methods and tools; Execute approved methods and tools → Verification and stop conditions satisfied?; Verification and stop conditions satisfied? — Yes → Decision owner approves consequential use; Verification and stop conditions satisfied? — No → Correct evidence, assumptions, or workflow; Correct evidence, assumptions, or workflow → Identify approved evidence and source authority

Bound the engineering objective → Identify approved evidence and source authority; Identify approved evidence and source authority → Write prompt and agent contract; Write prompt and agent contract → Execute approved methods and tools; Execute approved methods and tools → Verification and stop conditions satisfied?; Verification and stop conditions satisfied? — Yes → Decision owner approves consequential use; Verification and stop conditions satisfied? — No → Correct evidence, assumptions, or workflow; Correct evidence, assumptions, or workflow → Identify approved evidence and source authority

  • Bound the engineering objective: terminator
  • Identify approved evidence and source authority: data
  • Write prompt and agent contract: process
  • Execute approved methods and tools: process
  • Verification and stop conditions satisfied?: decision
  • Correct evidence, assumptions, or workflow: process
  • Decision owner approves consequential use: terminator

The Six-Layer Agentic Engineering Architecture

A production-oriented engineering workflow should separate six layers:

  1. Instruction layer: objective, constraints, method, output contract, and stop conditions.
  2. Evidence and context layer: approved files, datasets, drawings, standards, provenance, revisions, and task-relevant context.
  3. Tool and execution layer: calculators, code, spreadsheets, search, BIM/GIS/CAD interfaces, databases, and other connected systems.
  4. State and control layer: permissions, least privilege, working state, retries, checkpoints, rollback, and action logging.
  5. Evaluation and verification layer: deterministic validators, independent calculations, source checks, failure cases, and release criteria.
  6. Decision and approval layer: the qualified person or role that accepts, rejects, escalates, or authorizes consequential use.

This separation prevents a well-written prompt or a capable model from being mistaken for a complete engineering control system.

Six-Layer Agentic Engineering Architecture

A complete workflow separates instructions, evidence, execution, state/control, evaluation, and human authority.

The five layers separate wording from the evidence, execution environment, controls, and final decision authority.

1
Instruction layer
2
Evidence and context layer
3
Tool and execution layer
4
State and control layer
5
Evaluation and verification layer
6
Decision and approval layer

Prompt Versus Agent Contract

A prompt tells the AI what to do. An agent contract additionally defines what the system may access, what actions it may execute, how it records state, when it must stop, which checks must pass, and who must approve the result.

For simple low-risk work, the ten-element prompt framework may be sufficient. For connected or multi-step work, extend it with:

  • allowed and prohibited tools;
  • read/write/execute/send permissions;
  • source and revision allowlists;
  • maximum action scope or iteration budget;
  • required checkpoints;
  • rollback and recovery behavior;
  • audit-record fields;
  • named approval authority.
Prompt Versus Agent Contract

Use the stronger contract whenever the system can take multi-step actions or use tools.

A prompt defines the task; an agent contract also defines operational permissions and lifecycle controls.

Prompt controls
  • Objective
  • Inputs
  • Method
  • Output format
Agent contract adds
  • Tool permissions
  • State and context
  • Stop conditions
  • Audit and rollback
  • Approval gates

Role, Objective, and Decision Boundary

The first elements define the discipline, the bounded objective, and the decision the output will support.

Weak objective:

Analyze this bridge.

Stronger objective:

Review the supplied preliminary girder calculations for arithmetic consistency,
unit consistency, missing load cases, and unsupported assumptions.
Do not redesign the member and do not claim code compliance unless the governing
requirements are supplied and verified.

A prompt is stronger when it identifies what the AI must not decide.

Ten Elements Grouped for Review

The ten-element framework can be reviewed as four practical control groups.

Use these framework groups as a checklist when translating a vague request into an auditable engineering specification.

Role and objective
Known data and provenance
Source authority and assumptions
Method and checks
Output and verification
Stop conditions and human approval

Known Data, Provenance, and Source Authority

Known data should identify provenance whenever possible:

  • drawing number and revision;
  • survey date and source;
  • laboratory report and sample identifier;
  • spreadsheet tab, range, or data export;
  • approved schedule revision;
  • rainfall, traffic, or sensor-data source;
  • governing code, manual, specification, contract document, or official issuance and edition.

Source authority should also be explicit. A current official source should control over an uncited secondary summary when a requirement is consequential.

Assumptions, Method, and Stop Conditions

Assumptions should be classified as:

  • given: explicitly supplied by the engineer;
  • derived: calculated from verified inputs;
  • temporary: permitted for sensitivity or preliminary exploration;
  • prohibited: information that must not be guessed.

The method section should state required equations, workflow, comparison basis, software logic, or checks when material to the task.

Stop conditions should require the AI to halt or return an evidence gap when inputs are missing, authoritative sources conflict, a tool fails, or a requested action exceeds the permitted consequence level.

Output, Verification, and Approval Contract

A strong prompt defines how the result will be reviewed. Typical output sections include:

  • input table;
  • assumptions register;
  • source list;
  • equations or method;
  • intermediate results;
  • governing result with units;
  • sensitivity or alternative cases;
  • unresolved items;
  • independent verification checklist;
  • named human approval or decision owner.

This turns the response into an auditable engineering artifact rather than a persuasive paragraph.

Reusable Master Template

ROLE / DISCIPLINE
[Discipline and workflow]

ENGINEERING OBJECTIVE
[Specific decision, review, calculation, or deliverable]

KNOWN DATA
[Verified inputs, units, and provenance]

GOVERNING STANDARD / SOURCE AUTHORITY
[Exact sources, editions, revisions, or approved documents]

ASSUMPTIONS ALLOWED / PROHIBITED
[Permitted temporary assumptions and information that must not be guessed]

METHOD / CHECKS REQUIRED
[Equations, workflow, comparisons, units, governing cases, and checks]

OUTPUT FORMAT
[Tables, sections, equations, CSV, checklist, memo, or code]

VERIFICATION REQUIREMENTS
[Independent arithmetic, unit, source, consistency, and reproducibility checks]

LIMITATIONS / STOP CONDITIONS
[Missing data, uncertainty, conflicting sources, tool errors, or prohibited actions]

HUMAN APPROVAL
[Named role responsible for consequential use]

A Reusable Prompt Is Only One Controlled Component

For repeated engineering work, version the prompt like a checklist or calculation template, but also version the connected tools, validation rules, source requirements, permissions, and approval gates when they materially affect the result. Agentic workflows fail when teams version the wording but not the execution environment.

Do Not Hide Project-Specific Judgment in a Generic Template

Reusable prompts should standardize the workflow, not force every project into the same assumptions. Site conditions, geometry, contract requirements, hazards, material properties, governing standards, and consequence level must still be supplied for each actual case.

Specification Verification Loop

Agentic engineering treats failure as a controlled return path.

A failed check should route the workflow back to evidence, assumptions, or methods rather than being hidden in polished prose.

Auditable engineering specification
Specify
Execute
Check evidence
Test result
Revise or approve
↺ repeat when checks fail

Worked Use Cases and Reusable Prompts

The companion Worked Examples applies this framework to structural, geotechnical, hydrology, transportation, construction, materials, BIM, and organizational prompt-template workflows.

Add an Output Contract and an Evaluation Contract

The ten-element prompt framework is stronger when two machine-checkable contracts surround the generated work:

  • Output contract: required fields, schema, units, identifiers, precision, missing-data representation, and allowed status values.
  • Evaluation contract: checks that determine whether the output is acceptable, including deterministic validators, source requirements, numerical tolerances, prohibited actions, and escalation conditions.

Natural-language prose may still be part of the deliverable, but critical engineering state should use structured fields whenever practical so downstream validation does not depend on interpreting free text.

Working State Is Not an Authoritative Record

Agents may maintain temporary state, summaries, or memory to continue a workflow. Those representations can be incomplete, compressed, or stale. Preserve authoritative engineering records separately with stable identifiers, revision metadata, and provenance. When the workflow resumes, re-ground critical decisions from the authoritative source rather than assuming remembered context is current.

Context Budget Is an Engineering Resource

Treat the context window as a constrained resource. Prioritize the smallest set of current evidence and instructions needed for the next decision. Summaries can reduce token load, but a summary should never silently replace a primary source when exact clauses, dimensions, units, revisions, or acceptance criteria matter.

Key Takeaways
  • The ten-element framework converts vague AI requests into controlled engineering instructions.
  • Agentic engineering adds evidence, tool, control, and decision layers around those instructions.
  • Data provenance, source authority, permissions, assumptions, and stop conditions are as important as prompt wording.
  • Reusable prompts and agent workflows should be versioned when they support repeatable professional work.
  • Project-specific engineering judgment and human approval cannot be generalized away by a template or agent.

References