Superintelligence Prep for Web Design Studios: Tracking Client Revisions

A web design studio can use an AI agent today to log each revision request, link it to the agreed scope and record every client approval before the next build step starts. The agent does not decide what the client means or sign off on anything for the studio. It keeps the revision trail complete and flags conflicts for the project lead, which is where rework usually begins.

Key takeaways

• Log every revision request with its source, requester, affected page or component, and the scope item it touches before anyone starts the change.
• Let the agent summarize, classify and flag, but keep approvals and scope changes in a step a named person owns.
• Store each approval as evidence: the asset version, the exact wording the client used, the channel, and the date.
• Build project memory from structured facts about scope and decisions, not from a pile of chat transcripts.
• Write one success criterion you can check every week, such as whether every open request has an owner and a status.

Why revision rounds drift off the record

Revisions arrive through email threads, chat messages, comments on staging links and phone calls. Each channel works on its own. Together they produce a familiar situation: a change was requested on a call, nobody wrote it down, the designer built it, and the client believes the original version is still under review. When the page goes live, the studio and the client remember different agreements.

The problem is rarely carelessness. A busy project lead cannot reread every thread before each build session, and a project coordinator cannot know whether a new request contradicts a decision made three rounds earlier. The gap is a missing record that connects requests, decisions and approvals to the same scope baseline. An agent is useful here because it can read every channel, apply the same fields to every message and keep the log current without getting tired of the repetition.

What an agent can track today

A revision log that an agent maintains should be simple enough that a person can audit it in a few minutes. For each request, the record should hold the following:

• The request in the client's words, with the original message or call note linked.
• The source channel and the date it was received.
• The page, section or component the request affects.
• The scope item it links to, or a flag that no scope item matches.
• A status: received, clarified, accepted for build, built, awaiting approval, approved or rejected.
• Approval evidence, meaning the client message or confirmed action, tied to a specific asset version.
• Open questions and the person responsible for answering them.

The agent's job is to fill these fields accurately and point out gaps. The lead's job is to decide what a status means and to move a request into the next stage. Keeping those two jobs apart is what makes the log trustworthy when a client later asks what was agreed.

A setup plan for a revision log

A first version does not need many integrations. It needs a clear baseline and a few rules that everyone follows.

• Step 1: Write the scope baseline for one active project. List the pages, sections, features and content owners, and give the document a version number.
• Step 2: Choose one intake channel to start, usually the shared project inbox or the chat space where clients already write.
• Step 3: Give the agent read access to that channel and to the scope document, and write access to the revision log only. It should not send client messages or publish anything at this stage.
• Step 4: Define the statuses in writing and name the person who moves a request from accepted to approved.
• Step 5: Run a weekly review in which the agent lists open requests, unlinked requests and requests with no movement for a set period. The lead decides what happens to each one.
• Step 6: Check the success criterion each week. For example, every new request should have a scope link or a flag within one working day of arriving.

Once this works on one project, extend it to the next project using the same fields. Changing the structure for each client makes comparison impossible.

Illustrative scenario: a homepage change

The following scenario is illustrative and does not describe a real project. A studio is building a website for a local service business. During a call, the client asks to replace the hero image and to add the phone number to the site header. The agent, working from the call notes, creates two revision entries. It links the hero request to the approved homepage design, and it links the header request to the contact details the client already approved. Because the header change touches approved content, the agent flags it and sends the project lead a short summary asking whether this needs a new approval round. The lead decides. The agent does not reply to the client, and the approval status does not change until the client confirms the new header in writing.

The value of this example is not speed. It is that the disagreement about the header becomes visible before the build, while the cost of changing course is still small.

Where the approval boundary belongs

Approval rules should be enforced by the systems the agent uses, not only by instructions in its prompt. Authorization guidance from OWASP recommends checking permissions outside the model, so that a request the agent cannot justify is blocked by the tool rather than trusted by the agent. In practice, the agent's credentials should allow it to write to the revision log and create drafts, while sending messages, changing invoices and publishing pages require a human action in the relevant tool.

Client messages also need careful handling. A client may paste text that looks like an instruction to the agent, for example a note asking it to mark everything approved. The agent should treat client content as data to be recorded, not as commands. Any status change that depends on client text should be shown to a person for confirmation, with the original message attached.

What a more capable agent would need from project memory

A more capable agent could take on more of the coordination. It might draft change summaries for clients, compare each new request against every prior decision, and prepare the approval packet for a round of sign-off. To do that reliably, it needs memory it can check, not a long conversation history it has to interpret each time. Retrieval-based designs ground answers in current documents, which is why the project record should be the source the agent reads from, not its own recollection.

For a web studio, the project memory should contain:

• A versioned scope baseline, with the date each version was agreed.
• Decision records that state what was decided, who decided it, the date and the source message.
• Approval evidence tied to the exact asset version the client saw.
• Superseded decisions marked as superseded, so an old instruction cannot quietly return.
• Open questions with an owner and a due point in the project.

The same principle appears in other fields. Our notes on project memory for engineering firms describe how structured records make later answers traceable. The discipline is identical here: the agent is only as dependable as the facts it can cite.

Before granting a more capable agent more responsibility, test it against real past revision threads from your own projects. Evaluation guidance from OpenAI describes turning real cases into test sets with clear pass and fail conditions. Ask whether the agent links a request to the right scope item, whether it catches a contradiction with an earlier approval, and whether it leaves the approval status alone when the client's message is ambiguous.

Where to start

Be Human designs and operates this kind of setup as a managed service. A first engagement defines one useful role for the agent, the memory and tools it needs, the approval boundaries and one observable success criterion for the revision log. Managed operations then cover monitoring, recurring evaluations, permission review when a connected tool changes, and controlled improvements to the agent's instructions. Decisions about scope and client approval stay with the studio throughout.

If you want to know which part of your studio's work should go to an agent first, take the free Be Human AI diagnostic to find the first task worth handing over.

Frequently asked questions

Can an AI agent approve a client's revision for a web design studio? No, and it should not be configured to. The agent can record an approval the client gave in writing, attach the evidence and the asset version, and flag a message as ambiguous. The change to an approved status should be made by a named person or through a confirmed action in the approval tool.

What access does an agent need to track revisions? It needs to read the intake channel and the scope document, and to write to the revision log. It should not hold permission to send client messages or publish pages during this stage. Keep the permission list short and review it whenever a connected tool changes.

How is project memory different from a chat history? A chat history is a transcript, while project memory is a set of structured facts with a source, a date, an owner and a status. A future agent can answer a question such as what the client approved for the header only when that decision is recorded as a fact linked to a specific asset version. A transcript alone makes the same answer slow and easy to get wrong.

How should a studio judge whether the agent is working? Judge it by the success criterion written down before the setup began, not by how capable the model seems in a demonstration. Check whether every new request has a scope link or a flag, whether contradictions with earlier decisions are caught, and whether ambiguous client messages leave approval statuses untouched. If the agent misses any of these, adjust the fields, the rules or the test cases before extending its role.

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