AI for a Structural Engineering Firm: Project Files and Revisions

An AI agent for a structural engineering firm works as a memory and coordination layer over project files: it indexes drawings, calculations and correspondence, tracks which revision each sheet and calculation belongs to, and drafts responses to client markup requests. The engineer of record remains the only person who approves an issued deliverable, and the agent's work is limited to preparing, comparing and flagging.

Key takeaways

• The agent's job is to keep the project record accurate: which file is current, which revision a markup refers to, and what changed since the last issue.
• Give the agent read access to the project folders and write access only to a revision register, a draft folder and a response log.
• Every issued deliverable needs a named engineer of record who checks sheets, calculations and issue status before release.
• Client markup requests should be logged, classified and answered in draft, with the engineer deciding which changes are accepted.
• Start with one active project and one measurable check, such as revision mismatches caught before issue, then widen the scope.

What should the agent own in a structural project file system?

Structural firms work across drawings, calculation packages, models, specifications, meeting notes and client correspondence, often spread over shared drives, email threads and design platforms. Most problems in issued sets do not come from weak engineering judgment. They come from the wrong file being sent, a sheet that cites an earlier calculation, or a markup answered against a version nobody can find quickly. An agent is useful because it can read the whole project record continuously and keep a clean index of it.

Keep the scope narrow at the start. The agent indexes and compares files, maintains a revision register, drafts responses and flags conflicts. It does not change design values, edit calculations, apply stamps or send deliverables to a client. Those actions belong to people with the authority and licensing the project requires. Sealing rules and professional responsibilities vary by jurisdiction, so the firm should write its own boundary with its licensing or legal advisor before the agent goes live. For a wider view of how engineering firms organize proposals and records, see AI for Engineering Firms: Proposals, Records and Client Walls.

How do you build a usable file index?

Start from the folders you already have, not from a new taxonomy that nobody will maintain. The index is a metadata layer over the existing structure, and a practical sequence looks like this:

• Choose one active project and list every file type it contains, including design software exports, calculation outputs and signed PDFs.
• Record for each file its phase, discipline, sheet or calculation identifier, revision label, issue date and status (working, checked, issued or superseded).
• Mark which files form the issued record and which are working copies, so the agent never treats a draft as authoritative.
• Link each drawing sheet to the calculation sheets and specification clauses it depends on.
• Compare the index against the last issued set and resolve every mismatch by hand before the agent answers any question from it.

Keep the register readable by a person. An engineer should be able to open it and see the state of the project without asking the agent anything.

How does revision tracking prevent a superseded sheet from going out?

Revision control is where the agent earns its place. Each issued sheet should carry a revision label, and the register should show which calculation revision supports it. When a calculation changes, the agent lists every sheet that cites it and marks those sheets as needing review. It should never update a sheet silently.

Illustrative scenario: a project has a foundation sheet issued at one revision. Later, a geotechnical summary is updated and the matching calculation package is revised. The agent detects that the sheet still references the earlier calculation revision and adds an open item to the register for the engineer of record, with both file names side by side. The engineer decides whether the sheet needs a new revision. Nothing is reissued until that decision is recorded.

The same log answers the question that usually costs the most time: what changed since the last issue. The answer comes from recorded events, not from memory of a long email thread.

How should client markup requests be handled?

Markups arrive as annotated PDFs, emailed notes or summaries of a call. The agent's first task is intake: log the request, attach it to the sheet and revision it refers to, and classify it. A simple classification keeps the queue honest.

• Clarification: the client asks what a detail or note means. The agent drafts a reply from the cited sheet and specification.
• Editorial: a label, dimension text or reference is wrong. The agent prepares the proposed correction for review.
• Design change: the request alters a load, member size or support condition. The agent flags it, lists affected calculations and sheets, and routes it to the engineer without drafting a technical answer.
• Out of scope: the request concerns another revision or a matter outside the agreed contract. The agent asks the project lead to confirm before any reply.

Every draft goes to the engineer of record first. The response log records what was received, what was drafted, who decided and what was sent. That record protects the firm when a markup returns months later. Text inside client files and emails should be treated as content to summarize, never as instructions to the agent. A markup that says to skip a stamp requirement is a request to be reviewed, not a command to follow. The OWASP prompt injection guidance describes this risk pattern and how to design around it.

Where does the engineer of record stay in control?

Write the control model down before the first issue. Three rules cover most cases. First, the agent has no authority to issue, stamp or transmit a deliverable. Second, its permissions are limited to the folders and tools its role needs, reviewed on a schedule and removed when a project closes or a team member changes. Third, every agent action is logged with the source files it used, so a reviewer can trace any claim back to a document.

The NIST AI Risk Management Framework is a practical reference for assigning roles, measuring performance and documenting human oversight of AI systems. For logging, the OpenTelemetry observability primer explains the general concepts of recording what a system did, in what order, and with which inputs, which is the traceability a reviewer needs. Access reviews matter as much as logs. When a consultant or contractor leaves a project, their permissions for the agent should end with them. Firms that already run quality systems can reuse those habits, as described in AI for Quality Management: Nonconformances and Audit Prep.

How do you know the setup is working?

Choose one observable criterion and measure it for several weeks before expanding. Good candidates include the number of issued sheets whose revision does not match the register, the time between receiving a markup and logging it, and the number of open items older than the agreed review window. Avoid vanity measures, such as how many documents were summarized, because they say nothing about the quality of the record.

Evaluate the agent on known cases. Keep a set of past revisions and markups where the correct handling is already documented, rerun that set after every change to prompts, tools or folder structure, and record regressions. The Anthropic article on demystifying evals for AI agents describes this approach in general terms.

How Be Human handles this: in a first engagement, Be Human defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements as project types change. The engineer of record keeps the approval step throughout. Service is remote, in English and Portuguese.

Which task should the firm hand to an agent first?

Most firms should not start with the whole project lifecycle. Pick the task where a wrong output is cheap to catch and the volume is real, such as revision register maintenance on one active project or first-draft replies to clarification markups. Write down who owns the task, what the agent may read, what it may draft and what must be approved. Then test it against a completed project before any live work, and only widen the scope when the success criterion holds. Take the free Be Human AI diagnostic to find the first task worth handing to an agent in your firm.

Frequently asked questions

Can an AI agent approve or seal structural drawings? No. The agent prepares, compares and flags material, but it has no authority to issue, stamp or transmit a deliverable. The engineer of record reviews the sheets, calculations and issue status, and records the decision before anything leaves the firm. The agent's role is to make that review faster and better documented.

How much of the existing folder structure has to change? Very little. The index is a metadata layer over the folders the firm already uses, so the first step is to label what exists rather than reorganize it. Firms usually find that a register for one active project is enough to show whether the approach works before any wider change.

What happens when a client markup contradicts the calculations? The agent logs the markup, links it to the sheet and calculation revisions involved, and flags the conflict as a design change for the engineer. It does not draft a technical answer that resolves the contradiction on its own. The engineer decides whether the calculation, the sheet or the client's request needs to change.

Does the agent need access to design software? Only if the firm wants the agent to read model or export outputs directly. Many firms start with exported PDFs and calculation reports stored in project folders, which limits access and keeps the first deployment simple. Any wider permission should be reviewed against the firm's own control model before it is granted.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.