Module 16: AI Agents, Orchestration, and Engineering Automation

Learning Objectives

  • Distinguish assistants, tool-using agents, orchestrators, subagents, and interoperable multi-agent systems.
  • Define agent harnesses, task state, context, memory, skills, tools, permissions, asynchronous execution, stopping conditions, and approval gates.
  • Decide when one well-equipped agent is preferable to multi-agent orchestration.
  • Design parallel and asynchronous workflows with bounded ownership, explicit handoffs, idempotent operations, retries, and checkpoints.
  • Measure reliability, cost, latency, tool behavior, and safe-failure performance before production automation.

AI Agent

An AI agent is a software system that can pursue a defined objective through multiple steps by planning, using permitted tools, observing results, updating its state, and continuing until it reaches a stopping condition or requires human intervention.

Agent Harness

An agent harness is the runtime layer that manages an agent's context, tool calls, files, execution environment, intermediate state, retries, subagents, and lifecycle around the underlying AI model.

Subagent

A subagent is a bounded agent delegated a narrow portion of a larger objective, with its own scope, inputs, tools, outputs, and stopping criteria. Subagents should reduce cognitive and operational scope rather than duplicate the orchestrator's entire authority.

Human Approval Gate

A human approval gate is a required checkpoint at which an authorized person must review the available evidence and explicitly permit an agent to perform a consequential action or continue to a higher-risk stage.

Least Privilege

Least privilege is the control principle of giving an agent only the minimum data, tools, write permissions, and action scope required to complete the current task.

From Prompt to Controlled Workflow

A single prompt normally produces one response. An engineering agent may instead:

  1. receive approved project files or data;
  2. validate required schemas and revisions;
  3. request or flag missing information;
  4. search approved sources;
  5. run code or spreadsheet analysis;
  6. compare results against supplied criteria;
  7. prepare a draft artifact;
  8. perform an internal consistency audit;
  9. stop for engineer review;
  10. record approval, rejection, or next action.

This sequence resembles a controlled engineering procedure more than a chat conversation.

Bounded Asynchronous Task Orchestration

Treat this as a control pattern for client-managed tools and agents. Each logical task has a stable orchestrator task ID, named owner, scoped inputs and tools, output contract, dependencies, deadline, retry limit, and idempotency policy. Each asynchronous call attempt may have its own call ID for tracking. Keep waiting and retrying as separate actions: while pending, wait on the existing task handle/original call ID and continue only independent work; never resubmit a pending or completed task. Start a new attempt only after a transient failure, while within the retry budget, and when duplicate side effects are ruled out or deduplicated. Keep the task ID stable, use a new call ID for each new attempt, and do not confuse either ID with an idempotency key. Reuse the same idempotency key for a retried side-effecting operation only when the tool supports that guarantee; after an ambiguous outcome without deduplication, check authoritative task/result state or stop rather than replaying the operation. Validate provenance and reconcile results before use. Preserve partial results and route discrepancies to a named owner for bounded correction; keep release blocked until correction restarts at dependency and evidence checks and passes. Hand consequential actions to an authorized human.

Bounded Asynchronous Task OrchestrationTreat this as a control pattern for client-managed tools and agents. Each logical task has a stable orchestrator task ID, named owner, scoped inputs and tools, output contract, dependencies, deadline, retry limit, and idempotency policy. Each asynchronous call attempt may have its own call ID for tracking. Keep waiting and retrying as separate actions: while pending, wait on the existing task handle/original call ID and continue only independent work; never resubmit a pending or completed task. Start a new attempt only after a transient failure, while within the retry budget, and when duplicate side effects are ruled out or deduplicated. Keep the task ID stable, use a new call ID for each new attempt, and do not confuse either ID with an idempotency key. Reuse the same idempotency key for a retried side-effecting operation only when the tool supports that guarantee; after an ambiguous outcome without deduplication, check authoritative task/result state or stop rather than replaying the operation. Validate provenance and reconcile results before use. Preserve partial results and route discrepancies to a named owner for bounded correction; keep release blocked until correction restarts at dependency and evidence checks and passes. Hand consequential actions to an authorized human.. Receive bounded engineering objective and approved policy → Define task IDs, owners, permissions, inputs, outputs, dependencies, deadlines, and retry limits; Define task IDs, owners, permissions, inputs, outputs, dependencies, deadlines, and retry limits → Hand scoped contracts to owners; dispatch only independent tasks in parallel; Hand scoped contracts to owners; dispatch only independent tasks in parallel → Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result; Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result → Are all required task results complete?; Are all required task results complete? — Yes → Freeze required results with task IDs, owners, revisions, and timestamps; Are all required task results complete? — No → Is this task pending before its deadline?; Is this task pending before its deadline? — Yes → Wait on the existing task handle and original call; continue only independent work; Wait on the existing task handle and original call; continue only independent work → Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result; Is this task pending before its deadline? — No → Is failure transient, within retry budget, and duplicate-safe?; Is failure transient, within retry budget, and duplicate-safe? — Yes → Start a new attempt; keep task ID, use a fresh call ID, and reuse a supported idempotency key; Start a new attempt; keep task ID, use a fresh call ID, and reuse a supported idempotency key → Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result; Is failure transient, within retry budget, and duplicate-safe? — No → Log the terminal reason, preserve partial results, and notify the task owner; Log the terminal reason, preserve partial results, and notify the task owner → Stop until the owner resolves or re-scopes the task; Freeze required results with task IDs, owners, revisions, and timestamps → Confirm each result matches its declared dependency and predecessor revision; Confirm each result matches its declared dependency and predecessor revision → Validate each result's owner, scope, output schema, provenance, and required evidence; Validate each result's owner, scope, output schema, provenance, and required evidence → Cross-check results against source evidence and independent checks; Cross-check results against source evidence and independent checks → Are outputs traceable, consistent, and accepted by all required checks?; Are outputs traceable, consistent, and accepted by all required checks? — Yes → Would the next action alter authoritative data, communicate externally, or affect safety/contract?; Are outputs traceable, consistent, and accepted by all required checks? — No → Hold release; correction must restart at dependency and evidence checks; Would the next action alter authoritative data, communicate externally, or affect safety/contract? — No → Close with the draft artifact and complete task record; Would the next action alter authoritative data, communicate externally, or affect safety/contract? — Yes → Hand traceable evidence and the proposed action to an authorized human; Hand traceable evidence and the proposed action to an authorized human → Does the authorized human approve?; Does the authorized human approve? — Yes → Authorized human performs the approved action and records the result; Does the authorized human approve? — No → Stop; record the human decision and retain the audit trail

Receive bounded engineering objective and approved policy → Define task IDs, owners, permissions, inputs, outputs, dependencies, deadlines, and retry limits; Define task IDs, owners, permissions, inputs, outputs, dependencies, deadlines, and retry limits → Hand scoped contracts to owners; dispatch only independent tasks in parallel; Hand scoped contracts to owners; dispatch only independent tasks in parallel → Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result; Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result → Are all required task results complete?; Are all required task results complete? — Yes → Freeze required results with task IDs, owners, revisions, and timestamps; Are all required task results complete? — No → Is this task pending before its deadline?; Is this task pending before its deadline? — Yes → Wait on the existing task handle and original call; continue only independent work; Wait on the existing task handle and original call; continue only independent work → Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result; Is this task pending before its deadline? — No → Is failure transient, within retry budget, and duplicate-safe?; Is failure transient, within retry budget, and duplicate-safe? — Yes → Start a new attempt; keep task ID, use a fresh call ID, and reuse a supported idempotency key; Start a new attempt; keep task ID, use a fresh call ID, and reuse a supported idempotency key → Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result; Is failure transient, within retry budget, and duplicate-safe? — No → Log the terminal reason, preserve partial results, and notify the task owner; Log the terminal reason, preserve partial results, and notify the task owner → Stop until the owner resolves or re-scopes the task; Freeze required results with task IDs, owners, revisions, and timestamps → Confirm each result matches its declared dependency and predecessor revision; Confirm each result matches its declared dependency and predecessor revision → Validate each result's owner, scope, output schema, provenance, and required evidence; Validate each result's owner, scope, output schema, provenance, and required evidence → Cross-check results against source evidence and independent checks; Cross-check results against source evidence and independent checks → Are outputs traceable, consistent, and accepted by all required checks?; Are outputs traceable, consistent, and accepted by all required checks? — Yes → Would the next action alter authoritative data, communicate externally, or affect safety/contract?; Are outputs traceable, consistent, and accepted by all required checks? — No → Hold release; correction must restart at dependency and evidence checks; Would the next action alter authoritative data, communicate externally, or affect safety/contract? — No → Close with the draft artifact and complete task record; Would the next action alter authoritative data, communicate externally, or affect safety/contract? — Yes → Hand traceable evidence and the proposed action to an authorized human; Hand traceable evidence and the proposed action to an authorized human → Does the authorized human approve?; Does the authorized human approve? — Yes → Authorized human performs the approved action and records the result; Does the authorized human approve? — No → Stop; record the human decision and retain the audit trail

  • Receive bounded engineering objective and approved policy: terminator
  • Define task IDs, owners, permissions, inputs, outputs, dependencies, deadlines, and retry limits: process
  • Hand scoped contracts to owners; dispatch only independent tasks in parallel: subprocess
  • Track task owner, queued/running/pending/completed/failed state, dependencies, attempts, deadline, and result: data
  • Are all required task results complete?: decision
  • Is this task pending before its deadline?: decision
  • Wait on the existing task handle and original call; continue only independent work: process
  • Is failure transient, within retry budget, and duplicate-safe?: decision
  • Start a new attempt; keep task ID, use a fresh call ID, and reuse a supported idempotency key: process
  • Log the terminal reason, preserve partial results, and notify the task owner: process
  • Stop until the owner resolves or re-scopes the task: terminator
  • Freeze required results with task IDs, owners, revisions, and timestamps: data
  • Confirm each result matches its declared dependency and predecessor revision: process
  • Validate each result's owner, scope, output schema, provenance, and required evidence: process
  • Cross-check results against source evidence and independent checks: process
  • Are outputs traceable, consistent, and accepted by all required checks?: decision
  • Hold release; correction must restart at dependency and evidence checks: terminator
  • Would the next action alter authoritative data, communicate externally, or affect safety/contract?: decision
  • Hand traceable evidence and the proposed action to an authorized human: document
  • Does the authorized human approve?: decision
  • Close with the draft artifact and complete task record: terminator
  • Authorized human performs the approved action and records the result: terminator
  • Stop; record the human decision and retain the audit trail: terminator

Current Agentic Tooling — September 24, 2026

Current platforms demonstrate increasingly similar architectural patterns even when product names differ:

  • OpenAI GPT-6 Astra, Sol, and Luna: different capability/cost profiles within the GPT-6 family. Current developer guidance includes reasoning-effort selection, asynchronous tool calling, mid-turn steering, and explicit subagent guidance.
  • OpenAI agent and work environments: illustrate long-running context, files, code, connected tools, browser/computer interaction, artifact creation, and human steering during execution.
  • Google Gemini 3.8 systems: illustrate high-speed agentic reasoning and live multimodal interaction.
  • Anthropic Claude Opus 5.5, Fable 5.1, Sonnet 5, and Claude Code: illustrate long-running work, tool use, coding, subagent delegation, and cost/capability trade-offs.
  • MCP and A2A: represent complementary interoperability patterns: agents to tools/data and agents to other agents.

The engineering design rule remains vendor-neutral: use the minimum architecture required to meet the objective, evaluate it on representative cases, and constrain permissions independently from model intelligence.

Six-Layer Engineering Agent Architecture

A practical architecture for production-oriented engineering agents.

The harness surrounds the model with context, tools, state, validation, and governance; the model alone is not the agent system.

1
Objective and policy
2
Context and evidence
3
Orchestration and state
4
Tools and execution
5
Verification and evaluation
6
Observability, approvals, and governance

Agent Architecture for Civil Engineering

A robust engineering agent can be designed as six interacting layers:

  1. Objective and policy: engineering goal, consequence class, acceptance criteria, prohibited actions, and decision owner.
  2. Context and evidence: controlled files, data, standards, model revisions, project memory, and provenance.
  3. Orchestration: plan, task decomposition, subagent delegation, checkpoints, and handoffs.
  4. Tools and execution: research, code, spreadsheets, databases, BIM/GIS/CAD, messaging, or other approved systems.
  5. Verification and evaluation: deterministic checks, independent calculations, source validation, test cases, and error detection.
  6. Observability and governance: logs, tool-call history, cost/time limits, exceptions, rollback, approvals, and retained artifacts.

A capable model without these layers is not a production-ready engineering agent.

Orchestrator and Subagent Roles

A decomposed project-control example with independent responsibilities.

Subagents should reduce scope: each receives only the evidence, tools, and deliverable needed for its bounded responsibility.

Orchestrator: plan and reconcile
Schedule subagent: logic review
Data subagent: quantity reconciliation
Research subagent: source verification
Reviewer subagent: challenge findings
Human owner: consequential approval

Orchestrator and Subagent Pattern

Use subagents when a workflow contains separable specialties or evidence domains. For example, a project-control orchestrator might delegate:

  • schedule logic review to a schedule subagent;
  • quantity reconciliation to a data subagent;
  • specification research to a source-restricted research subagent;
  • report consistency checking to an independent reviewer subagent.

The orchestrator should define each subagent's exact scope, inputs, allowed tools, deliverable, and stop conditions. Do not give every subagent broad write/send permissions. A reviewer subagent should be independent enough to challenge the producing subagent rather than merely restate its output.

Permitted Versus Prohibited Agent Actions

Tool access should match the bounded engineering objective.

Least privilege means the agent gets support capabilities without automatically receiving authority to change or issue engineering records.

Often appropriate
  • Read approved files
  • Run check scripts
  • Create draft artifacts
  • Flag discrepancies
Requires explicit human authority
  • Modify authoritative models
  • Send contractual instructions
  • Certify accomplishment
  • Approve safety-critical decisions

Engineering Agent Prompt Pattern

OBJECTIVE
Prepare a draft weekly construction progress audit.

ALLOWED TOOLS
Read approved schedule, progress spreadsheet, and site-report folder.
Run calculation scripts. Create a draft report.

PROHIBITED ACTIONS
Do not modify source files.
Do not certify accomplishment.
Do not send instructions to contractors.
Do not make contractual decisions.

WORKFLOW
Validate revisions -> reconcile quantities -> check schedule status -> flag discrepancies -> draft report -> audit draft.

STOP CONDITIONS
Stop if required files are missing, revisions conflict, a calculation check fails, or measured progress cannot be reconciled.

APPROVAL GATE
Engineer must approve findings before issue.

AUDIT RECORD
Log source IDs, tools/actions, generated artifacts, exceptions, and human approvals.

Evaluation Before Automation

Before production use, create a small evaluation set containing:

  • known-correct normal cases;
  • edge cases near engineering limits;
  • missing or conflicting inputs;
  • stale or superseded sources;
  • unit and sign traps;
  • malformed files or schema errors;
  • unauthorized-action attempts;
  • cases where the correct behavior is to stop and request human review.

Measure not only answer accuracy but also source fidelity, tool selection, stop-condition compliance, reproducibility, and whether the agent remains inside its permission boundary.

Good Automation Candidates

Prefer tasks that are repetitive, structured, reversible, and reviewable, such as:

  • file classification;
  • data validation;
  • schedule consistency checks;
  • report assembly;
  • spreadsheet reconciliation;
  • standards research preparation;
  • issue-register maintenance;
  • test-result summaries;
  • repetitive coding or post-processing;
  • generation of checklists from verified requirements.

Higher-risk design or acceptance decisions should retain stronger human control and independent analysis.

Automate the Procedure, Not the Professional Responsibility

An agent can automate evidence collection, calculation steps, comparison rules, formatting, and draft generation. It should not be granted unrestricted authority to approve designs, accept nonconforming work, certify payment, issue safety-critical instructions, or make contractual decisions without authorized human review.

Tool Access Multiplies Consequences

A hallucinated statement in chat may be caught before use. The same error inside an agent with write, send, execute, or modify permissions can propagate immediately. Apply least privilege, explicit scopes, immutable source records, reversible operations, logs, stop conditions, and approval gates.

Failure-Safe Agent Design

A controlled engineering agent should stop or escalate when:

  • required evidence is missing;
  • source revisions conflict;
  • authoritative sources disagree;
  • a calculation or validation check fails;
  • a tool returns an error or incomplete result;
  • an action would alter an authoritative engineering record;
  • uncertainty exceeds the defined workflow tolerance;
  • the next action changes the consequence class of the task.

Failing safely is more important than completing every workflow automatically.

Agent Evaluation and Release Loop

Release is gated by evidence, not by one successful demonstration.

Production readiness requires repeated evaluation against known-good, edge, failure, and unauthorized-action cases.

Evaluation-gated engineering agent
Build test set
Run workflow
Inspect failures
Fix controls
Rerun and approve release
↺ repeat when checks fail

Worked Use Cases and Reusable Prompts

The companion Worked Examples contains prompts for document-review agents, data-pipeline agents, weekly reporting, source-restricted research, model-checking scripts, approval-gated quantity workflows, fail-safe stop conditions, and agent audit records.

Single Agent Before Multi-Agent

Multiple agents add coordination cost, duplicated context, additional failure surfaces, and harder debugging. Use one agent with the required tools when the workflow is sequential and tightly coupled. Introduce subagents when work is genuinely separable, parallelizable, requires independent review, or benefits from distinct permission boundaries.

Asynchronous Tool Use Changes Workflow Design

Modern agent runtimes can continue useful work while a slow tool is pending. Design asynchronous workflows with a stable internal task ID, a call ID for each asynchronous attempt, explicit pending states, timeout behavior, and bounded retries. While a task is pending, wait on its existing task handle and original call; do not resubmit it. Start a new attempt only after a transient failure, while the retry budget remains, and when duplicate side effects are ruled out or deduplicated. Keep the task ID stable and assign a new call ID to each new attempt. Reuse an idempotency key for a retried side-effecting operation only when the tool supports that guarantee; the key is distinct from task and call IDs. After an ambiguous timeout, query authoritative task/result state or stop rather than replaying a possibly completed side effect. Define what independent work may continue without the outstanding result, and never let a pending critical check be bypassed because another branch completed.

Mid-Turn Steering Should Preserve Auditability

Some current agent systems allow users to correct scope or priorities while execution is in progress. Treat steering as a new instruction event: record what changed, invalidate dependent work when necessary, and re-run affected checks. A mid-turn correction should not create an untraceable mixture of old and new requirements.

Skills and Progressive Context Loading

Reusable skills are most effective when narrowly triggered and loaded only when relevant. Keep descriptions concise, make the root skill a router when supporting material is large, and avoid loading every procedure into every task. Review skills as models improve because obsolete scaffolding can waste context or create conflicting instructions.

Observability Must Cover More Than Final Answers

For production engineering agents, capture enough telemetry to answer:

  • which evidence and revision were used;
  • which tools were called and with what scope;
  • which tasks ran in parallel or asynchronously;
  • what retries, failures, and timeouts occurred;
  • what subagent produced each artifact;
  • what verification passed or failed;
  • what cost and elapsed time were incurred;
  • which human steering or approvals changed the execution.

This turns agent operation into a reviewable engineering process rather than an opaque conversation.

Key Takeaways
  • Engineering agents combine models, context, tools, execution environments, and state, so they require stronger controls than ordinary chat.
  • Orchestrators and subagents should have narrow scopes, explicit handoffs, and least-privilege permissions.
  • Evaluation sets should test normal cases, edge cases, failure cases, and unauthorized-action attempts before production use.
  • Input validation, observability, stop conditions, rollback, and approval gates should be designed before automation begins.
  • Automation should support engineering procedures without transferring professional responsibility to the AI system.

References