Superintelligent Agents for Engineering Firms: Submittals and Field Notes

An AI agent for an engineering consulting firm works best as one bounded role: it tracks submittal status, files field notes against the right project, and drafts updates that a licensed person reviews before anything reaches a client, contractor or agency. It does not approve submittals, decide design questions or send messages on its own. For a small firm, the first useful agent covers one register and one note flow, with written approval boundaries and a success criterion that someone can check.

Key takeaways

• Start with one register, such as the submittal log for one active project, and one note flow, such as site visit notes, before adding anything else.
• Every entry an agent writes should carry a source reference to the specification section, drawing, email or note it came from.
• Clients, contractors and agencies receive nothing from the agent until a named engineer has approved it.
• Permissions should be read-first, with write access limited to log fields and a drafts folder, and no send permission at all.
• Judge the agent by fewer missed follow-ups and faster reviews, checked against a short recurring evaluation rather than impressions.

What does a submittal log need to track?

A submittal is a contractor's package of product data, shop drawings or samples sent for review against the project specifications. For a small firm, the log is the working record of what was sent, which specification section it answers, when it arrived, who holds it and what review status it carries. A late or lost submittal usually becomes visible only when a crew is waiting for material, which is why the log matters more than the inbox where the package first landed.

A useful log entry holds the following fields:

• Submittal number and the specification section it responds to
• Item description and the contractor or supplier who submitted it
• Date received, date returned and the reviewing person
• Status: received, under review, returned with comments, resubmit or approved
• Downstream dependency, such as the procurement date or the installation activity it gates
• Open questions raised in the review comments, linked to the original file

The agent's job is to keep these fields current and to point out the entries that are overdue relative to the schedule. The decision about what a returned submittal means stays with the engineer. Firms that already track proposals and project records in a structured way will recognize this pattern, and the same discipline is described in AI for engineering firms: proposals, records and client walls.

Turning field notes into records someone can use

Field notes are often typed on a phone in a truck, in shorthand, with photos and measurements that will make sense only to the person who took them. A project file needs something more reliable: the observation, where it happened, when, who saw it, what was measured, and whether it may affect scope, schedule or conformance. An agent can do much of the sorting, but only if the note template defines what a usable note looks like before the agent touches it.

A workable template separates facts from interpretation:

• Project, site area, date and author
• Observation, written in plain words of what was seen
• Measurements or readings, always with units
• Photos referenced by file name rather than embedded in the text
• Action requested, with the responsible party named
• Flag for a possible change, a safety concern, or a question for the engineer of record

When the agent receives a note that does not fit the template, it should ask for the missing element rather than fill it in. A measurement without a unit, or a photo without a location, is a gap to report, not a detail to guess. This is a small rule, and it prevents most of the errors that make a field record unusable later.

Where the review gate belongs

The rule that holds up in practice is simple. The agent may read broadly and write to internal records and drafts, but nothing leaves the firm without a named person approving it. A status email, a transmittal, a request for resubmittal, or a note telling a contractor that a field observation may affect scope is external communication the moment it is sent. The NIST AI Risk Management Framework is a useful reference for thinking about this kind of accountability, because it treats the people who govern a system as part of the system's design.

A decision guide for most engineering teams looks like this:

• Internal log update with a source reference: the agent may write directly.
• Internal summary for the project lead: the agent drafts, and the lead reads it.
• Letter or email to a contractor about a returned submittal: the agent drafts, and the engineer approves and sends.
• Any statement of a design position, approval or code conclusion: only the engineer of record decides, and the agent does not draft the conclusion.
• Any matter touching fees, schedule commitments or scope change: a human decides, and the agent may only gather the facts.

The same gate logic applies to quality events. When a field observation could become a nonconformance, the agent flags it and assembles the record, while the quality owner decides. The approach is parallel to the one in AI for quality management: nonconformances and audit prep.

Which tools and permissions should the agent have?

An agent that reads submittal packages and field notes needs access to the project folder, the shared submittals inbox and the log, plus a drafts folder. It does not need the ability to send email, approve items in a document system or delete records. Grant each permission separately, and review them on a schedule, because access granted for one project has a habit of remaining after the project ends. The OWASP authorization guidance describes this principle of granting only what a task requires and checking that the grant still applies.

Documents are a second concern. A contractor's PDF or a scanned transmittal is data, not instruction, and it can contain text that tries to steer an AI system, whether by accident or on purpose. The OWASP guidance on prompt injection recommends treating externally sourced content as untrusted and keeping the agent's instructions separate from the material it reads. In practice, that means the agent summarizes a document rather than acting on what the document says it should do.

In Be Human's managed approach, the first engagement defines the single role, the register and note flow it covers, the memory it keeps, the tools it may call, the approval boundaries and an observable success criterion. Ongoing operations can include monitoring, permission reviews, maintenance of the connections to the mail and file systems, incident response when something goes wrong, and controlled changes to the agent's instructions. The point of those later steps is that scope stays where the firm put it, even as the team's needs change.

An illustrative week with a steel connection submittal

The following scenario is illustrative and does not describe a specific firm or project. On a Monday, a fabricator sends a submittal for a steel connection detail. The agent logs it against the relevant specification section, attaches the file, sets the status to under review and places it in the reviewing engineer's queue with the installation date taken from the current schedule.

On Wednesday, a site visit note records that a connection was modified in the field to clear a duct. The agent files the note under the correct area, flags it as a possible change, and drafts a question for the engineer of record asking whether the modification needs a request for review. The engineer reads the draft, decides the modification does require a formal request, rewrites the wording and sends it to the contractor. The agent does not decide what the modification means.

On Friday, the weekly review shows the steel submittal still under review, with installation scheduled for the following week. The agent drafts a reminder to the project lead that lists the item, the dependency and the open comment. The lead moves the item up the review queue. Nothing in that week left the firm without a person reading it first, and every entry can be traced to its source.

A step-by-step plan for the first rollout

A first rollout should be small enough to check by hand. The following sequence works for most firms with one or two active projects:

• Choose one register and one project. Pick the submittal log for a single active job rather than the whole portfolio.
• Write the field note template and agree on it with the people who will file notes.
• Map the sources. List every mailbox, folder and file location the agent will read, and confirm who owns each one.
• Define the gates. Write down which outputs the agent may write directly, which it may only draft, and which are reserved for a named person.
• Grant permissions separately. Start with read access and add draft and log-write access only when the earlier steps are stable.
• Run in shadow mode. The agent produces its entries and drafts while the team keeps its usual process, and the two are compared each week.
• Review the differences. Each mismatch is classified as a missing reference, a wrong status, an invented detail or a correct catch the team had missed.
• Expand only when the success criterion holds. Add a second project or a second note flow only after the first one has been stable for long enough to trust.

The shadow period is the most valuable part of the plan. It reveals whether the template is clear enough, whether the source folders are complete and whether the reviewers have the time the gates assume.

How do you tell whether the agent is working?

The firm needs a success criterion that someone other than the builder can check. A practical one is a fixed set of past submittals and field notes whose correct outcomes are already known. Run the agent against that set at regular intervals, and score it for correct status, correct source references and the absence of details that appear nowhere in the source material. The Anthropic guidance on evals for AI agents describes this pattern of testing against realistic tasks, and the OpenAI evals guide covers the same idea from a different angle.

Record what the agent does in a way that can be reviewed later, including which files it read, which entries it wrote and which drafts it produced. OpenTelemetry's concepts for observability describe the general practice of capturing that kind of trace, and it makes incidents easier to investigate when a log entry turns out to be wrong. A monthly look at the evaluation results, the permission list and the incident notes is usually enough to keep the system honest.

If you want to find the first task worth handing to an agent in your firm, the free Be Human AI diagnostic is a practical place to start.

Frequently asked questions

Can an AI agent approve a submittal on our behalf? No, and it should not be set up to try. The agent can log the submittal, track its status, check it against the schedule and draft a review comment for an engineer. The approval decision belongs to the engineer of record, who is accountable for it under the firm's contracts and professional obligations.

Do we need to connect the agent to our project management software? Not on the first pass. Many firms begin with a shared submittals inbox, the project folder and a log that the agent can read and write in a controlled way. Deeper integrations can follow once the gates and the success criterion are proven, and each new connection should receive its own permission review.

What about photos on site that show workers or members of the public? Field photos can contain personal data, so the agent should reference photos by file name and should not copy identifiable images into summaries or drafts. Access to the photo folder should be limited to the people who need it, and the firm should confirm its retention and privacy obligations with its own advisors. The agent's permissions should reflect the same restriction.

Do we need a dedicated person to supervise the agent? Someone must own it, but the role does not have to be full time. The owner reviews the drafts that go external, checks the weekly evaluation, approves permission changes and decides when the scope expands. Many firms assign this to a project engineer or an operations lead who already understands the submittal process.

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