How Can AI Help Architects? Briefs, Planning Notes, Consultant Chasers

AI can condense a client's brief, organise site and planning notes into a first draft, and write consultant chase emails from a tracker. A registered architect must read anything that states a requirement, a policy position or a fact about the design, and AI should never make design decisions or sign off compliance.

The sorting rule is simple: AI may reshape information the practice already holds, and it may not supply information the practice does not hold. A chase email repeats facts from your tracker, so a skim is enough. A planning note that says which policy applies is a claim, so the architect checks it against the source. Treat every output as a keen junior's first draft: quick, tidy and unreliable on specifics.

Follow me on Instagram@sagnikteaches

Sort every admin job by who must read the output

Three review levels cover almost everything a practice does with AI. Decide the level before you write the prompt, because it tells you how much instruction the job needs and how long the check will take.

Connect on LinkedInSagnik Bhattacharya

• Level 1, skim then send. The output restates facts you supplied and states no requirement. A mistake is embarrassing, not costly.
• Level 2, the architect reads every line. The output organises or interprets. A mistake could mislead a client or a consultant.
• Level 3, not delegated. Decisions and judgements that rest on professional registration, or anything that goes out as a statement of fact under the architect's name.

Your professional body and your insurer set the real limits, and both can change them. Read their current guidance and your policy wording, because no tutorial can tell you what applies to your registration. The longer reads on writing a practice AI policy and what to tell your insurer help you set the rules down once.

Subscribe on YouTube@sagnikteaches

A client's brief in one page: prompt, output and what to fix

Clients often write briefs as emails: long, repetitive, and sometimes contradicting themselves between paragraphs. A one-page summary lets the whole team start from the same understanding. The prompt matters more than the tool, because a summary's main risk is tidying up the client's mess instead of showing it.

Summarise the client email below into a one-page brief for the design team.
Use these headings: Aims; Must-haves (quote the client's own words);
Preferences and maybes; Budget as stated; Programme as stated;
Constraints mentioned; Contradictions or gaps; Questions for the next meeting.
Rules: use only what the email says. If a number, date or name is not in the
email, write NOT STATED. Do not suggest design solutions. Do not resolve
contradictions: list them with both quotes.

Here is an illustrative client email, shortened, that you might paste under that prompt:

We'd like to open up the back of the house so the kitchen and dining room are one room, with doors onto the garden. Budget is around $250,000 including everything, but my husband thinks we should stay nearer $200,000. We'd like to start in spring if we can. Mum may move in next year so we might need a bedroom downstairs, though we haven't decided. The neighbours on the right have objected to things before.

A well-instructed model returns something like this:

The common first-draft errors are worth knowing, because they look helpful. A model told only to "summarise" tends to report one budget figure and drop the other, to promote the maybe-bedroom into the must-haves, and to invent a completion date because the heading exists. Each of those changes the brief without anyone deciding to change it. The "list contradictions, do not resolve them" rule and the NOT STATED rule exist to stop all three. After the summary comes the check: read the original email once, with the summary beside it, and tick every number, date and quoted phrase.

If the client sends a long thread rather than one email, add a second pass: "List every statement in this thread that conflicts with another statement, with both quotes and the dates." The practice then raises the conflicts at the next meeting rather than finding them at drawing stage. For the step after the brief, room data sheets from a client brief picks up where this one stops.

Planning notes: organise facts, list topics, state no policy

A planning note, as used here, is the internal record a practice keeps for a project: what you know about the site, what the authority said on the phone, which policy topics need checking, and what is still open. It is not the statement that goes with an application. That is a different document with a different review rule, covered in where to draw the line on planning applications.

The note is a good AI job because the raw material is messy and the output is internal. The danger is a model that "helpfully" tells you which policies apply. It has not read your authority's current documents, so it names plausible ones. Keep the model to organising what you wrote, and ask for topics to check rather than conclusions.

Organise my raw notes under these headings: Site facts (from my notes);
What the authority said (as I recorded it, unconfirmed); Topics to check in
the policy documents (topic names only); Open questions; Not known.
Rules: do not name any specific policy, code section or standard. Do not say
whether the proposal complies with anything. Mark anything I wrote with a
question mark as UNSURE. Keep my wording for anything the authority said.

site visit + call with authority
- attached house? yes I think. rear garden approx 12m. two-storey addition next door (left)
- big tree at back boundary, whose? protected??
- call: contact said fine "in principle" for single storey at rear; two storey "needs care re neighbours' light"
- heritage designation? didn't ask
- one parking space at front, no change planned
- need written confirmation of what contact said

Run on those notes, the output might look like this (illustrative):

Now read it as the architect. Three drifts are common even with those rules. "Fine in principle" can harden into "the authority supports a single-storey extension". "Needs care" can become "advised against". And the model may slip in a line such as "likely to need a daylight assessment", which nobody said. Each makes the note sound more certain than your call was. Strike the line, or move the idea into the topics list where it belongs.

When you do want help with policy wording, reverse the flow. The architect opens the authority's own published documents, copies the relevant paragraphs into the chat, and asks for a plain-English summary of those words only. The architect then reads the summary beside the paragraphs. That is a Level 2 job with a source on the table, and it works. Asking the model to recall policy from memory is a Level 3 mistake in disguise.

Consultant chasers: a tracker row in, a polite email out

Chasing is where hours can disappear without anyone noticing. Each chase means finding the thread, remembering what was asked, and writing a message that is firm without being rude. Move the facts into a tracker once, and the writing becomes a paste.

Write a chase email from [your name] to [first name] about the row below.
Use only the facts in the row. One ask, one date. Courteous and specific.
Do not mention fees, appointment terms, fault or delay. Under 90 words.

Item: Beam sizes at kitchen opening | Consultant: [first name], structural engineer
Asked: 3 Feb | Needed by: 20 Feb | Blocks: drawing issue for client sign-off
Last chased: 12 Feb (friendly reminder)

Illustrative wording from a good run: "Hi [first name], we are holding the drawing issue for the kitchen extension until we have the beam sizes at the rear opening. Could you send them by 20 Feb? If something is blocking you, tell me what and I will see whether we can unblock it from our side. Thanks, [your name]". Compare that with the version most of us write at the end of a long day: "Hi, any update on the structural info? Cheers". The second message does not say which information, by when, or why it matters, so it earns a reply that says "will do".

Check the draft for three habits models bring to a chase. They open with "I hope this finds you well" (cut it). They cite "our appointment" or "the agreed programme" (cut it, unless you have checked the wording). And they imply blame with phrases such as "your delay" (cut it, because the next email you need from that consultant is easier to get if this one was neutral). Send one email per consultant, never a round-robin to everyone, so nobody can wait for someone else to reply first.

Agree a ladder in the practice, so the same item is not chased differently by each person:

1. On the due date: a friendly reminder with the item and the date.
2. Three working days later: the same ask, plus what it blocks.
3. Six working days later: a phone call, then a two-line email recording what was agreed on it.
4. Ten working days later: the principal decides whether to escalate. An AI draft should not write any letter that cites appointment terms or consequences.

A quick sum shows why this is worth an afternoon. Take an illustrative four-person practice with six live projects and about five open consultant items on each, so 30 items. Writing one chase per item per week by hand takes about 8 minutes (find the thread, recall the detail, write, send), so 4 hours a week. With a tracker and a pasted row, it takes about 3 minutes (paste, skim, send), so 1.5 hours, plus about 30 minutes a week to keep the tracker current. The saving is around 2 hours a week, which is the figure to time for yourself over two weeks before you believe it. The bigger gain is often that nothing is forgotten, because the tracker shows the late items without anyone remembering them. If the practice runs on Microsoft 365, Microsoft Learn says Copilot Chat in Outlook works on the inbox without the paid licence, so the same prompt can run inside the mailbox.

Smaller jobs that follow the same rules

Once the three sorting levels are in your head, other admin falls into place. These are the next candidates, each with its check.

• Meeting action lists (Level 1). Paste the minutes and ask for actions as owner, task and date, with NOT STATED where a date is missing. Check that no action has been assigned to the wrong party, which is a common error. The tutorial on recording, summarising and issuing minutes covers the full routine.
• Drawing issue covering notes (Level 1). Paste the sheet numbers and revisions from your register and ask for a transmittal note. Check every revision letter against the register itself, since a wrong revision on an issued note causes real confusion. Keeping an issue register and transmittal log goes further.
• Fee proposal first drafts (Level 2). The model can arrange your scope and exclusions into a clean letter. The fee, the stages and what is excluded stay yours, and a solicitor should see any change to terms.
• Client progress letters (Level 2). Give the model your programme and last meeting's actions and ask for a plain-English update. Check every date against the programme and remove any promise you did not mean to make.
• Manufacturer and supplier queries (Level 1). A short email asking for a data sheet or a lead time. Nothing in it is a requirement, so the skim is enough.

Work AI must not do in a practice

Some jobs stay out of the chat window altogether, and not because the model cannot generate text for them. The text is the least of it. These jobs exist because someone with a registration, an insurance policy and a duty to the client has to make the call.

• Choosing between design options. A model can list options; the choice, and the reasons for it, are what the client pays for.
• Compliance conclusions. Whether a layout meets fire, access, energy or structural rules is a judgement against current codes and the particular building. A fluent paragraph asserting compliance is worse than no paragraph, because it reads as checked.
• Certificates and sign-offs. Anything signed or stamped, and any statement of fact to an authority or a contractor.
• Appointment and contract wording. Legal terms belong with a solicitor, not with a draft from a chat.

OpenAI's usage policies make a related point in the vendor's own words: its rules are "no substitute for legal requirements, professional duties, or ethical obligations that should influence how people use AI". Your duty to the client and to your registration body does not move to the tool. If a document would be relied on by someone else under your name, a person with the right registration reads and owns every line.

Client data and drawings: what goes in a chat

Briefs and planning notes carry names, addresses, family circumstances and budgets. Decide what may be pasted before anyone does it from habit.

• Replace names and addresses with initials or "the client" and "the site" for any job that does not need them. The summary works just as well.
• Prefer business plans. OpenAI says it does not train its models on ChatGPT Business, Enterprise or API data by default. Claude Team and Enterprise, Microsoft 365 Copilot and Gemini in Workspace take the same default position in their documentation. Consumer plans for ChatGPT and Claude have a switch that stops your chats being used for training, and it is the practice's job to check that it is off.
• Know the price of the safer route. ChatGPT Business and Claude Team both need at least two seats. ChatGPT Business Standard seats list at $25 a user a month, or $20 on annual billing, and Claude Team's standard seats list at the same figures. A one-person practice would use an individual plan with the training switch off.
• Keep drawings with security detail out. Alarm layouts, safes and anything a client has asked you to protect stay out of the chat, whatever the plan.
• Read the confidentiality clause in your appointment and any client NDA before pasting a brief. If it forbids third-party processing, the answer is no until you have written permission.

Settings labels change often, so check the current privacy page of whichever tool you choose rather than relying on a screenshot from last year.

A two-week trial on one live project

Do not roll this out across the practice in one go. Pick one live project with at least two consultants and run a short trial with measures, so the decision to continue rests on your own numbers.

1. Week one: chasers and notes. Build the tracker, write every chase from a pasted row, and organise one site visit's notes. Record minutes per task before and after.
2. Week two: brief and actions. Summarise one client email with the NOT STATED rules and produce one action list from minutes.
3. Log every error you catch. A wrong date, an invented line, a softened or hardened quote. The log tells you how much checking each job really needs.

For the illustrative four-person practice from the chaser sum, the log at the end of the fortnight might read like this:

Read the errors column before the minutes column. The chaser error came from the tracker, not the model, so the fix is a habit rather than a prompt. The notes drifted the same way twice, so that job keeps its line-by-line read however quick the draft becomes, and its saving stays modest on purpose.

At the end of the two weeks, keep the jobs that passed, drop the ones that did not, and write the rules into your practice policy so a new starter follows them.

Questions practices ask before trying this

Can AI write a planning statement for me?

It can organise your own notes into a draft, but the architect writes the design rationale, checks every policy reference against the source and signs. The tutorial on planning applications sets out exactly where that line sits. For internal planning notes, keep the AI to facts and topics to check, never conclusions.

Do I have to tell clients that I use AI?

There is no single answer. Check your appointment terms, your professional body's guidance and your insurer's wording, because duties differ. A plain sentence in the appointment letter saying that client information may be processed by an AI service under a business plan costs nothing and avoids surprises.

Which assistant is best for this admin?

Any current assistant can do these jobs, so choose on data terms and on where your email already lives. A practice on Microsoft 365 can start with Copilot Chat in Outlook, which works on the inbox without the paid licence. Others can use ChatGPT, Claude or Gemini on a business plan rather than a personal account.

How do I stop AI inventing facts in a brief summary?

Tell it to use only the text supplied, to write NOT STATED for anything missing, to quote the client's own words for must-haves, and to list contradictions without resolving them. Then compare every number, date and name in the summary with the source email before it goes into the project file.

Further reads

• Can AI Help a Small Architecture Practice? Where It Saves Time — Where AI saves time across a whole small practice.
• What AI Is Good for Architects? Six Jobs for a Small Practice — Six jobs for a small practice, with limits.
• Copyright and Client Data Risks of AI in Architecture Practices — Copyright and client-data risks in more depth.
• How Architects Use AI for Fee Proposals, Briefs and Paperwork — Fee proposals and paperwork, with the same review rules.
• Architect Site Visit Report: Notes and Photos to a Clear Report With AI — Site visit notes and photos into a clear report.
• Claude vs ChatGPT vs Gemini for Architects: Which to Pay For — Which assistant to pay for in a practice.
• How to Use Claude AI in Architecture: Specs and Planning Reports — Summarise specifications and planning documents with Claude, check every clause against the original, and keep client material out with a never-paste list.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: OpenAI usage policies and enterprise privacy page; vendor privacy statements for business plans; Microsoft Learn on Copilot Chat in Outlook; ChatGPT Business and Claude Team pricing pages.