Architecture RFP Response: Reuse Past Proposals With AI, Without Copying

Turn past proposals into an answer library instead of a folder to copy from. Strip each answer of client names, project details, fees and unpublished design information, record where it came from, then have the AI adapt library answers to the new RFP's scoring criteria. Search the final draft for anything client-specific before you submit it.

The usual shortcut is to open last year's winning proposal, paste it into an assistant and say "adapt this for the new client". It is also the quickest way to send one client's name, fee or unbuilt scheme to another client's evaluators. The method below keeps the speed and removes that risk by changing what the AI is allowed to see.

Follow me on Instagram@sagnikteaches

Reuse the evidence and the structure, never the sentences

What your practice has learned is reusable: how you phase work in an occupied building, how you keep a team together from bid to handover, how you test energy performance at concept stage. The sentences describing it are tied to a client, a site and a moment. A reusable answer is the lesson written fresh, with the identifying material taken out and the proof points kept.

Connect on LinkedInSagnik Bhattacharya

Start by agreeing what counts as client-specific. This table is a starting list; your contracts and any non-disclosure terms may add to it.

Subscribe on YouTube@sagnikteaches

Then add a three-level label for every library entry. Level 1 is public: material already published through your website or an approved case study. Level 2 is anonymised: the lesson and proof points with every identifier removed. Level 3 is restricted: anything under a non-disclosure agreement or where the client has asked for silence. The rule that follows is simple. The AI sees Level 1 and Level 2 only. Level 3 stays in the project archive, and if a bid needs that experience, a person writes it fresh.

If a project would add real weight to a bid but sits at Level 3, ask the client. A short message is enough, as long as it says exactly what you want to use:

We are preparing a submission for a similar project and would like to describe our work on [project] in anonymised terms, and to name you as a referee if the evaluators ask. We would not share drawings, fees or your own documents. Please reply yes or no to each of these: anonymised description; named project; named referee. We will record your answer and honour it.

Record the reply in a permissions register, so the next person building a bid does not have to ask again or, worse, guess.

Build the answer library in a day from seven proposals

An answer library is a single document or spreadsheet of short, approved answers, one per question type, each with its source and review date. Pick five to eight of your best proposals, the ones that won or scored well, and work through them in this order:

1. List the questions each proposal answered: approach, team, relevant experience, sustainability, quality assurance, programme, risk, fee basis, social value.
2. For each question type, pull out the generic core: what you do, how, and why it works.
3. Sanitise it (the next section shows how).
4. Add the proof points, each marked as public, anonymised or "verify before use".
5. Give it an ID, an owner, an approval date and a review date 12 months out.

Seven proposals at about 45 minutes each, plus an hour of review, is a working day, and it yields roughly 30 entries. Here are three of them, filled in:

Note the "verify before use" tags. A library that holds unverified numbers will recycle them for years. Each proof point either has a source you can show or carries the tag, and the draft is not submitted while a tag remains.

Sanitise with the AI, then check by hand

The assistant is good at the first pass of sanitising, but it only removes what looks like a name. Use this prompt on one past answer at a time, in an account where your content is not used for training by default:

Below is a paragraph from one of our past proposals. Rewrite it as a reusable
answer for our library.
Remove or generalise: client and project names, codenames, towns and addresses,
dates, fees and budgets, exact numbers of homes, rooms or square metres (use
"fewer than 50", "several"), named consultants and contractors, quotes, and any
detail that would let a reader work out which project it is. Keep: the method,
the reasoning and the lesson. Do not add any fact that is not in the original.
Then list every detail you removed or generalised, so I can check the list.

PARAGRAPH:
[paste]

A worked example shows why the second step, your own check, cannot be skipped. This is the original, with the identifiers shown in square brackets: "For [client name]'s housing department we delivered [project name], a 48-home scheme on the former bus depot in [town], keeping 12 households in place during phase one. The director said it was the smoothest consultation the department had run."

A typical first pass from the assistant reads: "For a public-sector housing client we delivered a 48-home scheme on a former depot site, keeping 12 households in place during the first phase." Every name has gone, but "48-home", "former depot site" and "12 households" together would let a procurement officer who knows the area identify the scheme in seconds. The version that goes in the library reads: "For a public-sector housing client we delivered a scheme of fewer than 50 homes on a brownfield site, keeping existing households in place during the first phase and running consultation alongside design." The director's quote is gone because it belongs to the client.

The assistant's list of removals is the control. Keep it separate from the library, as an internal redaction log, and read it against the original. Then ask a colleague who did not work on the project to read the sanitised entry and say which project it describes. If they can guess, the entry is not anonymised enough.

Win themes: three ideas the evaluators should remember

A win theme is a point you want the evaluators to remember after reading five or six responses in a row. Choose three. Each one needs evidence from the library, and two proof points are better than one. It should recur in the summary, the approach, the team section and the risk section so it reads as a thread rather than a slogan.

Take an illustrative RFP for a community library refurbishment. Reading its stated objectives, you decide that the evaluators care most about service continuity, long-term running costs and certainty of delivery. Your themes and their evidence become:

The assistant can propose themes if you give it the RFP's objectives and the list of library entry titles. It will offer generic ones: "innovation", "collaboration", "added value". Reject any theme that no entry supports. A theme with no proof behind it is the sort of empty claim evaluators have read a hundred times.

Turn the scoring criteria into a checklist before drafting

Copy the evaluation scheme from the RFP into a table before you write a word, and never let the assistant choose the weights; copy them. Then allocate pages in proportion. For a 20-page limit, with example weights:

The last column is the point of the exercise. It shows, before drafting starts, which parts of the bid can come from the library and which have to be written fresh for this client. Notice that "understanding of the brief" has no library entries at all: it is the one section where copying is worst, because it is the evaluators' test of whether you read their document.

The assistant earns its place here by building the checklist from the RFP text: paste the evaluation section and ask for a table of criteria, weights, page or word limits, mandatory forms and deadlines. It will occasionally misread a weight, so check each number against the document. If the RFP needs a formal compliance matrix as well, the tutorial on win themes and a compliance matrix for engineering firms covers the method, and the construction tender tutorial on drafting against scoring shows the check from the evaluator's side.

The adaptation prompt: library entries in, tailored answers out

With the checklist done, the assistant adapts library entries to each criterion. The prompt tells it what it may use, makes it cite its source, and leaves placeholders where only a person can supply the project-specific facts.

You are drafting one section of an architecture practice's RFP response.

CRITERION (copy from the RFP, with its weight and word limit):
[paste]

LIBRARY ENTRIES YOU MAY USE (nothing else):
[paste only Level 1 and Level 2 entries, with their IDs]

Rules:
- Use only the library entries. Do not add facts, numbers, names or claims.
- Tag every claim with the ID of the entry it came from, e.g. [LIB-004].
- Where this project needs a specific detail, write [INSERT: what is needed].
- Mirror the RFP's own wording for the criterion. Lead with evidence.
- Stay within the word limit.
- At the end, list any claim you could not support from the entries.

A typical output for the "delivery and risk" criterion begins: "To keep [INSERT: the building] in use during the works, we phase the programme around [INSERT: the occupier's key dates] [LIB-004]. Noisy work is scheduled around the occupier's calendar, and a weekly look-ahead meeting with the occupier's representative keeps escape routes and entrances clear [LIB-004]. The project lead named in this bid remains in post through to handover [LIB-011]."

These are the faults to look for:

• Specifics that are not in the library. "Our dedicated community liaison officer" appears from nowhere. If it has no tag, it goes.
• Generic filler. "We have extensive experience" with no proof is a sentence to delete or to back with an entry.
• Tags that do not match. A claim tagged LIB-011 that is really from LIB-004. Spot-check five tags per section.
• Placeholders left in. Search for "[INSERT" and "[verify" before the document leaves your desk.

The tagging is also a defence against the more serious problem that the tutorial on made-up figures in AI-drafted proposals describes: a plausible number with no source. Every number in the draft should trace to a tag or a person.

Where the AI runs matters as much as what you paste

Using a business plan lowers one risk. Anthropic's privacy centre says that by default it does not use inputs or outputs from its commercial products, which include the Claude for Work plans (Team and Enterprise) and the API, to train its models, unless you choose to share them, for example by sending feedback (page dated 18 August 2026). ChatGPT Business follows the same no-training default. A consumer account usually has a model-training setting you should switch off. None of that makes confidential material safe to share. Your client contracts may restrict disclosure to third-party processors, so read the confidentiality clauses of your appointments before you decide what the AI may see, and let the sanitised library do the work. For a wider policy covering drawings and client data, see the AI policy checklist for drawings and client data, and for the copyright side the copyright and client data tutorial.

The RFP also arrives with its own confidentiality terms. Check them before pasting any of it into a tool, and check whether the instructions to bidders say anything about AI use: some procurers set rules or ask for disclosure. If they do, follow them; if they are silent, keep a short record of how AI was used on the bid.

A practical set-up is a project or workspace that holds the library and nothing else, so each new RFP chat starts from the same sanitised entries. Claude Projects are available to all users, including free accounts, and sharing a project with colleagues is a Team or Enterprise feature according to Anthropic's help article. ChatGPT has an equivalent in its Projects. Either way, the library file is the only document attached, and original proposals stay out.

The scrub before you submit

However careful the sanitising, run a final scrub, because leaks tend to be mundane. They hide in footers, text boxes and file properties, not in the headline paragraphs.

1. Search the whole document for a banned list: every previous client's name, project names and codenames, sub-consultants, addresses and towns, and the names of staff who have left.
2. Accept all tracked changes and delete every comment, then check the document again for text that was hidden by them.
3. Check headers, footers, text boxes, figure captions and image alt text.
4. Check file names and document properties: author, title, "last saved by".
5. Use Word's compare feature (on the Review tab) against the proposal each answer came from, to see how much text has been carried over unchanged.
6. Copy five distinctive sentences from the draft and search your old proposals folder for them.
7. Ask a colleague who was not on any of the source projects to read it and say whether it reads as written for this client.
8. Export to PDF and check the PDF properties as well.
9. For every claim tagged with a library ID, confirm the proof point is still true and still permitted.

A realistic failure: a response goes out with a previous client's name in the footer of one appendix, because the appendix was copied from an old file and the footer was never in the body text anyone read. The procurement team notices on page 17. The fix is step 3, run every time, plus a check of the PDF as the recipient will see it.

Joint bids, CVs and images: where reuse goes wrong quietly

Three places catch practices that have the main library under control. Joint bids: when you bid with another practice or a consultant, their material is theirs. Their past project descriptions, fee information and CVs need their written agreement before they go into your documents, and nothing from a joint bid should flow into your own library without it. CVs and team biographies: staff should agree how their experience is described, and the entries age quickly. Put a review date on every CV entry and check that nobody who has left the practice is still named as available. Images: project photographs sit under the photographer's licence, and drawings or renders of unpublished schemes belong to the client. Do not paste them into an AI tool, and do not reuse them in a bid unless the permissions register says you may; describe the approach in words instead.

The images that are safe to reuse are the ones where you hold a written licence and the client has agreed to publication. Keep that list next to the library, not in anyone's memory.

Hours on a 20-page response, before and after

Say the last response of this size took 55 hours of copying, rewriting and reformatting. With the library in place, the breakdown looks like this:

That is about 23 hours saved, on the assumption that the library already exists. The first bid pays for the library: expect the day it takes to build to come out of the first response's savings. The 14 hours for project-specific content is where the quality sits, and it should not shrink much. A library speeds up the parts of a bid that were always the same. It does nothing for the parts that should be different.

None of those hours help if the bid was never winnable. Before the checklist stage, put the RFP through a bid or no-bid decision, so the 32 hours go to bids you have a real chance of winning.

When dedicated RFP software is worth paying for

Dedicated RFP and answer-library products exist, and they add approvals, expiry dates and permissions. They are worth considering when several people contribute answers, you respond to RFPs most months, or you need to prove who approved what. Before buying any, ask each vendor the same five questions: where is our data stored; is our content used to train models, and can that be switched off; can we delete everything on exit; can it show the source of every answer; and how are permissions set between people on the same bid. Check whether the vendor publishes its pricing, and read the contract term and exit terms before you commit. Until then, a shared document and a disciplined review date will carry a small practice a long way.

Checking that reuse stays safe over time

Three measures keep the method honest. Count the client-specific items found at the pre-submission scrub on each bid; the number should trend to zero, and a rise means the library needs another pass. Once a year, ask someone outside the practice to read the library and say which clients they can identify. And keep a short permissions register beside it: which projects may be named, which may be quoted, and which referees have agreed to be contacted, each with a date. If a client asks you to stop naming them, the register tells you which entries to change, and the review date on every entry means no answer stays in circulation for longer than a year without a person looking at it again.

Further reads

• Can AI Help a Small Business Respond to Tenders and RFPs? — The wider tender and RFP process for any small business.
• Can AI Write a Catering Tender Response? What to Keep Confidential — The same confidentiality problem, seen from a catering firm.
• How Architects Use AI for Fee Proposals, Briefs and Paperwork — Keep fee and scope wording consistent across your proposals.
• How to Mention AI Use in Client Contracts and Proposals — How to mention AI use in client contracts and proposals.
• AI for Meeting Planners: Venue Shortlists and RFP Replies — From client brief to venue shortlist to proposal reply: prompts, a scoring grid and a figure-check table for independent planners and small agencies.
• AI Marketing for Architects: Case Studies, Website Copy and LinkedIn — Turn a site-visit voice note into a case study, service-page copy and LinkedIn posts that sound like your practice, with permission and claims checks.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Anthropic's privacy centre article on model training for commercial products (dated 18 August 2026) and its help article on Projects, checked October 2026. The answer-library method is a practical approach written for this tutorial.