AI for Engineering Firms: Proposals, Records and Client Walls

AI for engineering firms works best as a records and proposals assistant: an agent that finds relevant past work, drafts from approved material and shows where every statement came from. The value comes from memory organized by project, client and permission, so a lesson learned on one job can help the next without the first client's drawings, data or fees travelling with it. Start with one narrow role, such as proposal support, and let access rules decide what the agent may read.

Key takeaways

• Most of an engineering firm's reusable knowledge already exists in proposals, memos, transmittals and closeout notes. The problem is finding it and knowing whether it is safe to reuse.
• Client separation must be enforced by the system that retrieves documents, not by an instruction in a prompt.
• Use two tiers of memory: private to the engagement, and firm-reusable material that a named reviewer has cleaned and approved.
• The agent drafts and cites. Engineers and principals decide scope, fees, schedule commitments and anything that carries professional responsibility.
• A first engagement should cover one role, one set of sources, clear approval points and a success measure that a reviewer can observe.

Why do engineering consultancies lose knowledge between projects?

The knowledge is rarely missing. It is scattered across project folders, email threads, calculation packages, technical memos, proposal archives and personal drives. A senior engineer remembers that a similar site had a groundwater problem. A newer colleague writing a proposal never hears about it.

Proposals suffer in a particular way. They are usually written from the last proposal someone can find. That brings along stale scope language, old assumptions, outdated team descriptions and, occasionally, another client's name in a footer. Nobody intends to leak anything. The process just rewards copying.

There are two failure modes, and a memory layer has to address both. In the first, nothing is reused, so every proposal starts from a blank page and every project repeats earlier questions. In the second, too much is reused carelessly, and client-specific details cross boundaries they should never cross. A useful agent reduces the first without causing the second.

What counts as usable memory, and what should stay out?

Not every document deserves to be memory. Usable memory is material with a clear author, a known status and a defined purpose. For a consultancy, the main categories are these:

• Proposals: scope wording, exclusions, assumptions, team structure and schedule logic, each marked with whether the proposal was submitted, won, lost or withdrawn.
• Technical memos: the question asked, method used, assumptions, conclusion, stated limits and the reviewer.
• Project records: transmittals, requests for information, site observations, change notices and closeout notes.
• Lessons learned: short statements written after delivery about what worked, what surprised the team and what to check next time.
• Firm standards: templates, quality procedures, approved boilerplate and verified qualifications.

Each item needs metadata so the agent can filter before it reads. Useful fields are project, client, discipline, document status, author, reviewer, date, confidentiality level and a plain flag stating whether the item may be reused outside its engagement. Without these fields, retrieval returns plausible text with no way to judge it.

Some material should stay out entirely: drafts that never got reviewed, superseded calculations, documents under restrictive contract terms, and anything whose status nobody can establish. A smaller, clean memory beats a large, uncertain one.

The usual technical pattern is retrieval: the agent searches the firm's own documents at question time and answers from what it finds, rather than learning the documents into a model. The AWS comparison of retrieval and fine-tuning explains why this suits changing, permissioned content. Documents stay where they are, can be updated or removed, and can be filtered by who is asking. Training a model on client work makes removal and separation far harder.

How do you keep one client's work away from another?

The separation has to live in the retrieval system. An instruction such as do not reveal other clients' information is a request, not a control. A system that never returns the document in the first place is a control.

A workable design uses several layers together:

• Engagement partitions: each project is its own store, and a session can search only the partitions that the requesting person is staffed on.
• Inherited permissions: the agent acts with the rights of the person asking, never with a broader service account. The OWASP authorization guidance on least privilege and deny-by-default applies directly.
• Two memory tiers: engagement-private material and firm-reusable material. Content moves from the first tier to the second only through a named reviewer who removes client identifiers, site details, fee information and distinctive design content.
• Contract flags: non-disclosure terms, public-sector security restrictions and joint-venture limits mark records as no reuse, and the retrieval layer honors the flag.
• Retrieval logs: every search records who asked, what was returned and from which source, so a partner can review access after the fact.

One more risk deserves attention. Documents arriving from clients, contractors and suppliers are untrusted input. A pasted email or a PDF can contain text that reads like an instruction. The agent should treat retrieved content as material to read, not commands to follow, and it should have no ability to send or publish anything without approval. The OWASP guidance on prompt injection prevention covers the defensive patterns.

The cleaning step in the second tier is where human judgment matters most. Removing a client name is not enough if the memo still describes a unique site condition that anyone in the region would recognize. The reviewer decides whether a lesson can be stated generally. For example, an observation that older buried pipe in a certain soil type often differs from record drawings is reusable. The exact location and client are not.

How should an agent help with proposals?

Proposal work is a strong first role because the inputs are bounded and the output is reviewed before it leaves the firm. The agent can do the following:

• Read the request for proposal and list every requirement, deadline and evaluation criterion.
• Search the reusable tier for comparable work by scope type, discipline and site conditions, not by client.
• Assemble a first draft from approved scope language, with each paragraph linked to its source.
• Flag assumptions that need an engineer's confirmation and gaps where no approved language exists.
• Prepare team and qualification sections from verified profiles.
• Check the finished draft against the original requirements and report anything missing.

The agent should not set fees, commit to schedules, describe a staff member's credentials beyond verified records, or modify limitation-of-liability and indemnity wording. Those belong to principals and, where relevant, counsel. For the contract side of that boundary, the guide on AI agents for in-house legal teams shows how requests and approvals can be structured.

Subconsultant and supplier quotes are a natural second step. Chasing quotes and comparing them against a scope is the same recurring work described in AI agents for procurement teams, and it can reuse the same engagement boundaries.

Professional responsibility does not move. A seal, a certification or an opinion of record stays with the licensed engineer. The agent prepares material and cites sources. A person reviews and owns the result.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a description of a real client or result.

A mid-sized consultancy that handles water infrastructure and structural assessments receives a request for proposal to rehabilitate a pump station. A project manager asks the agent for a first draft. The agent reads the request and lists the required sections, including condition assessment, options analysis and a phased construction support plan.

It then searches the firm-reusable tier. It finds approved scope language for condition assessments, two cleaned lessons about verifying as-built conditions before specifying replacements, and a qualifications paragraph for the relevant discipline. Each is shown with its source and reviewer.

The agent also detects that a highly relevant technical memo exists in a private engagement the project manager is not staffed on. It does not display the memo. Depending on the firm's policy, it either says nothing about it or sends a request to that engagement's lead asking whether a cleaned lesson could be added to the reusable tier. The project manager receives a draft built only from what they are allowed to see.

The draft marks three assumptions for engineer confirmation and leaves the fee section empty. A principal reviews, edits and approves. Later, the engagement lead reviews the restricted memo, writes a general lesson without identifying detail and adds it to the reusable tier, so the next proposal benefits.

What is a sensible step-by-step plan for the first engagement?

The aim is one useful role with limits that everyone understands. This sequence works for most consultancies:

• Step one, choose the role: proposal drafting support or technical memo search, not both at once.
• Step two, list the sources: name the folders, archives and systems the role needs, and exclude everything else for now.
• Step three, define the tiers: decide what counts as engagement-private and what can become firm-reusable, and who reviews the move.
• Step four, tag the records: add project, client, status, reviewer and reuse flag to the first set of documents, starting with the most recent and best organized.
• Step five, set permissions: connect the agent to staffing records so access follows project assignments, and confirm it uses the requester's rights.
• Step six, set approval boundaries: list the actions the agent may take alone, the ones that need a reviewer, and the ones it must never take.
• Step seven, define a success measure: for example, reviewers can trace each statement in a draft to a valid source, and no draft contains restricted material.
• Step eight, test with known cases: use past proposals where the correct answer is known, and include deliberate tests that try to retrieve material from a project the tester is not on.
• Step nine, run, review and adjust: read the retrieval logs regularly, remove weak sources and add new ones in small batches.

The NIST AI Risk Management Framework is a useful reference for the governance side: define who is accountable, how the system is measured and how problems are handled. For how to structure what the agent sees at each step, Anthropic's writing on context engineering for agents explains why a small, relevant set of material works better than a large one.

Firms with field operations will recognize similar patterns in AI for construction companies, where site records feed the same kind of memory. Teams that must show evidence of review will find overlap with AI for compliance teams. Design-led practices can compare notes with AI for architecture studios.

How does Be Human handle this?

Be Human designs, implements and operates the agent for the firm. A first engagement defines one role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The firm keeps control of what the agent can read, what it can do and who approves its work.

Frequently asked questions

Can an agent produce engineering deliverables that need a professional seal? It can help prepare drafts, summarize references and check documents against requirements, but it should not certify anything. The licensed engineer reviews the work and takes responsibility for it. The firm should record that review so the chain of ownership is clear.

Should we train a model on our past projects? For most consultancies, retrieval from permissioned documents is the safer choice. It keeps files in place, allows updates and removals, and lets the system filter by who is asking. Training on client work makes it difficult to separate or withdraw one client's material later.

What if a client contract forbids AI processing of its documents? Treat that as a contract flag on the engagement, so the agent never indexes or retrieves from it. Keep the flag in the record metadata, and review the contract terms with counsel when you are unsure. Lessons written by engineers without client content can still enter the reusable tier if the contract allows it.

Where should we start if our records are disorganized? Start small with the proposals and memos that are recent, reviewed and clearly owned. Tag them well, test retrieval on them and expand in batches. Cleaning the entire archive first usually delays the work without improving the result.

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