AI for Architecture Studios: Project Memory and Client Briefs

AI for architecture studios works best as a project memory, not as a design tool: an agent that records client decisions, tracks revisions against the brief, and answers questions about what was agreed and why. Designers keep the drawings and the judgment. The agent keeps the trail, so nobody has to rebuild it from email threads, meeting notes and chat messages.

Key takeaways

• The most useful first job for an agent in a studio is remembering, not drawing: briefs, decisions, revisions and open questions for each project.
• Keep memory outside the design files. The agent should point to drawings and models, not copy them or sit inside the working folders.
• Every decision record needs four things: what was decided, who decided it, why, and where the evidence is.
• The agent proposes and summarizes. Anything that changes a record, reaches a client or touches a consultant goes through a named person first.
• Start with one project type and one team, run the agent beside the team for a while, and expand only when the answers are reliably right.

Why do studios lose project memory in the first place?

A building project runs for a long time and passes through many hands. The client brief is written in the first weeks, then reinterpreted at every design review. Decisions are made in meetings, confirmed in an email, adjusted on a site visit and sometimes reversed by a phone call. Staff rotate between projects. A consultant joins late and asks why a wall sits where it does.

The information is rarely missing. It is scattered. The reason a client rejected the second facade option lives in one person's notebook. The approval for a material change sits in a thread nobody remembers the subject line of. When someone asks "did we agree to this?", the honest answer is often a half hour of searching, followed by a guess.

This is a memory problem, and it is a good fit for an agent for a specific reason: the cost of a wrong answer is high, but the task itself (find, compare, summarize, cite) does not require creative judgment. A well-built agent can do the retrieval and organization, and a person can verify the result in seconds because every answer points to its source.

What should an agent remember about a project?

Resist the urge to feed the agent everything. A studio that pours every file, message and sketch into one pile gets an assistant that is confidently vague. Decide what kinds of records matter and give each one a shape.

Four records cover most of the value:

• The brief: the client's goals, constraints, program, site conditions and priorities, written in plain language and versioned when the client changes them.
• The decision log: one entry per decision, with the decision, the person who made it, the reason, the date, and a link to the evidence such as an email, meeting note or marked-up drawing.
• The revision history: a short narrative of what changed between design stages, why it changed, and which decision triggered it.
• Open questions: items waiting on the client, a consultant or an authority, with an owner for each.

Notice what is absent. The agent does not hold the models or the drawing sets. It holds a structured account of the project and references to where the real files live. That separation matters for the rest of this article.

If your source material is messy, the groundwork is the same as for any knowledge system. The guide on preparing company documents for an AI agent covers naming, ownership and cleanup in more detail.

How do you keep memory from cluttering design work?

Design teams protect their working space for good reasons. File structures, naming conventions and model hygiene took effort to establish, and a tool that scatters notes or auto-generated files through them will be rejected within a week.

The principle is simple: the agent has its own place, and the design workspace stays untouched. In practice that means three rules.

First, the agent reads from the places where decisions already happen (the project mailbox, meeting notes, a shared tracker) and writes only to its own memory store. It does not save files into project folders.

Second, memory entries link to originals instead of duplicating them. A decision about the entrance canopy points to the review minutes and the relevant sheet. If the sheet is superseded, the link and the entry show that.

Third, the agent is asked questions where people already ask them, such as a message to the project channel, rather than through a new dashboard every architect must learn. A short answer with citations beats a portal.

How much the agent loads into its working context for a given question is also a design decision. Loading the whole project history for a simple query makes answers slower and less precise. The article on context engineering for business agents explains why a small, relevant slice of memory beats a large one, and the same idea appears in Anthropic's own guidance on effective context engineering for agents.

Retrieval is the usual mechanism. The agent searches the project's records, pulls the passages that match the question, and answers from them with references. AWS gives a clear overview of retrieval-augmented generation if you want the underlying pattern explained.

What is a practical plan to set this up for one project?

Pick a live project that is mid-stage, big enough to have real history but not so large that the setup becomes its own project. Then work through these steps in order.

• Name an owner. One project lead is responsible for the memory of this project and signs off on what goes in.
• Write the current brief in plain language and have the lead confirm it. If the client changed the brief during the project, record both versions and the date of the change.
• Collect the decisions that still matter. Go back through the project mailbox and meeting notes and write the decision log entries for the choices that constrain today's work. Skip trivia.
• Define the shape of an entry. Decision, decided by, reason, evidence link, status (active, superseded, reversed). Keep the format identical across projects.
• Connect the sources with read-only access. The agent reads the project mailbox and notes, and has no ability to send, delete or move anything. Anthropic's guidance on harnesses for long-running agents is a good reference for how an agent should keep a clear progress record across sessions.
• Set the approval boundary. The agent may draft a log entry or a client summary. A person approves it before it is stored as fact or sent anywhere.
• Test with real questions. Ask ten questions the team actually asks, such as "what did the client say about the north elevation?", and check each answer against the evidence.
• Review weekly. The lead skims new entries, fixes errors and retires superseded decisions.

The point of the narrow start is the same as in other domains: a small workflow you can prove beats a large one you cannot judge. The piece on choosing your first AI workflow goes deeper on sizing that first step.

What does this look like when a client changes their mind?

The following is an illustrative scenario, not a real project.

A studio is midway through a house renovation. Months into the work, the client writes that they would like the kitchen window moved back to its original position. The project architect asks the agent: "What do we have on the kitchen window?"

The agent answers from the decision log. The window was moved at a design review because the client wanted morning light on the dining table. The client's partner confirmed the change in an email, which the agent cites. A note from the structural engineer mentions that the new opening needed a different lintel. The agent also reports what it cannot find: there is no record of the cost or schedule effect of the original move, and it marks that as an open question rather than inventing an answer.

The agent then drafts a short summary for the architect: the original decision, who approved it, what it triggered downstream, and what a reversal would likely touch. It does not email the client and does not edit the log. The architect reads the summary, corrects one detail, discusses it with the client, and the decision is then recorded as reversed, with a link to the new instruction.

The value is not speed alone. The client hears a calm, accurate account of what was agreed, and the team avoids reopening a settled question by accident.

What should the agent never do on its own?

Project records carry weight. A wrong entry can turn into a dispute about scope, a missed approval or a design that quietly drifts from the brief. Set the boundaries early and in writing.

A useful rule is to separate three levels of permission: reading, drafting and sending. The agent can read project sources. It can draft summaries, log entries and meeting recaps. It should not send anything to a client or consultant, or change a stored decision, without a person approving. The article on read, draft and send permissions explains why these are different grants, and where an agent should stop and ask offers a way to decide the stopping points.

Two more boundaries deserve attention:

• Access follows the project. An agent working on one client's project should not be able to retrieve another client's brief. This is an authorization question, and the OWASP authorization guidance is a sound reference for designing least-privilege access.
• Memory goes stale. A decision that was superseded must not be quoted as current. Assign each entry a status and have the agent prefer active entries. The guide on stopping stale context from misleading an agent covers the review routine that prevents this.

Also decide what the agent says when it does not know. A good answer in this domain is often "I found no record of this", followed by where it looked.

How does a managed approach handle this?

Be Human designs and operates this kind of setup as a defined role: one agent with a clear job (here, project memory), its own identity and accounts, the specific sources and tools it needs, and approval boundaries agreed with the studio. After launch, managed operations cover monitoring of answers, recurring checks against real questions, maintenance of the connections to mailboxes and trackers, periodic review of what the agent can access, and controlled changes when the studio's process evolves. The studio keeps ownership of the records and the decisions about what the agent may do. For studios that also coordinate with contractors on site, the article on AI for construction companies shows where the neighboring workflows begin.

Frequently asked questions

Does the agent need access to our CAD or BIM files? Usually not, and it is safer if it does not. Most of what a project memory needs is in the text around the drawings: briefs, emails, review notes and approvals. The agent can reference sheet names and versions in its entries without opening the models.

Will it replace project coordinators or junior architects? No. It takes over the searching and summarizing that consumes their time, but deciding what a client's request means for the design, and what to tell the client, stays with people. Teams usually find that the coordinator becomes the owner of the memory, which is a more useful role than the one who digs through threads.

How do we know the agent is remembering correctly? Require every answer to cite its source, and spot-check on a schedule. Keep a short list of real questions with known answers and run them regularly, especially after any change to the setup. If an answer cannot be traced to an entry or a document, treat it as unreliable.

How should we handle client confidentiality? Treat each project as its own boundary. Limit the agent's access to the sources needed for the project it serves, keep a record of what it can read, and ask where the data is stored and processed before connecting anything. Clients with specific confidentiality terms should be told how project records are handled.

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