Skip to content
AI,  BIM

OpenAI Dots for Architects: AI Follow-Ups Across Project Tools

By ArchiLabs

Date Published

OpenAI Dots can help architects track an unresolved project question, prepare follow-up drafts, and keep its source history together. A useful assignment has a defined owner, authorized sources, a finite schedule, and a stopping condition. The project team still confirms decisions before any information becomes an instruction to change a Revit model.

What are OpenAI Dots, and how do they differ from a chat?

Dots are ongoing cloud agents with a computer, browser, and connected tools. They can research, prepare materials, and continue work across sessions. OpenAI distinguishes messaging access, plugins, and computer access; enabling one does not automatically grant the others. Availability varies by account. These details were checked on November 4, 2026 against the Dots documentation.

For an architect, the useful distinction is an ongoing responsibility. A single chat might summarize a submittal thread once. A Dot can be assigned to revisit the question and prepare updates as information changes. Define that responsibility around a specific decision, rather than asking it to “manage the project.”

Set up a Dot to track an architecture project decision

Choose a question that already has an owner and a recognizable end state. A discrepancy between an equipment datasheet and an approved register is a good example: someone needs to confirm which reference should appear, and the answer should be supported by an identifiable decision record.

A hypothetical assignment could read:

“Track the model-reference discrepancy for AHU-4. Use the specified submittal thread, Datasheet v2, Equipment Register v5, and the supplied schedule excerpt. Prepare an update each weekday at 08:30 America/New_York for ten business days. The project architect owns the follow-up. Save the status note and message draft in the connected review folder; do not send or post. Flag new or superseding documents for review. Stop when the project owner confirms the authorized decision, the question is superseded, or the ten-day window ends. Confirm the schedule you created.”

Replace the illustrative file names and destination with exact accessible links. Confirm that the Dot can open the intended versions. If a connector cannot access an attachment, its absence from the summary must not become evidence that the attachment does not exist.

The draft-only instruction is a requested operating rule. Review the actual permissions and outputs before relying on it. For ideas on writing a precise clarification request, see AI-assisted RFI response workflows.

Cloud tasks vs local Revit work: what stays connected?

A Dot's cloud work can continue when your laptop is offline. Work involving a connected local computer requires that computer to remain online with the ChatGPT app open, according to Getting started with Dots.

This matters when the source package is split across locations. A cloud-accessible correspondence thread and a register saved only on a workstation are different dependencies. If the workstation goes offline, ask the status note to identify the last register version actually inspected. Continuing to read emails does not make the inaccessible register current.

The reviewed Dots documentation does not establish native Revit integration. A cloud agent's access to project files should not be treated as proof it can query or edit a running model. Prepare the decision record first, then pass the confirmed modeling task to the responsible author or an application-connected tool.

Example: follow an unresolved equipment submittal question

In this hypothetical case, a submitted datasheet names MODEL-PX120 while the equipment register names MODEL-PX110 for AHU-4. These are illustrative identifiers, not a recommendation to substitute equipment. The responsible designer must resolve the discrepancy and any implications.

First event: no decision is available. The requested status note identifies the two conflicting references, gives the source locations, and names the person responsible for obtaining clarification. The follow-up draft asks which reference is intended and requests the supporting decision. It does not decide that the newest file wins.

Second event: an ambiguous message arrives. Someone replies, “Looks okay to proceed.” The useful update preserves the exact message and identifies what remains unclear: which reference was considered, whether conditions apply, and whether the sender has the project's decision authority. The Dot should surface those questions for review rather than infer approval from wording or a job title.

Third event: the project owner confirms a decision. The authorized reviewer provides an explicit reference and any conditions; the project owner confirms how that decision is to be recorded. The requested output links to that evidence and marks the follow-up ready to close. Check that the recurring assignment actually stops as intended.

This sequence gives the team a state history: unresolved discrepancy, clarification requested, confirmed decision. Keep the source messages attached to that history. A summary saying “approved” without the scope or conditions is not an adequate modeling instruction.

Turn a confirmed decision into a Revit change brief

The handoff should identify the approved reference, decision source, affected records, responsible model author, and unresolved dependencies. Distinguish the equipment register from model parameters, tags, and schedules; they may display the same information through different fields.

Before changing a shared type parameter, the BIM author needs to understand which instances use that type. A request concerning one equipment item does not automatically authorize a change to every instance. Include that question in the brief if the source material does not resolve it.

ArchiLabs Desktop can assist with native Revit and AutoCAD work on Windows. Use the confirmed brief to evaluate the specific modeling task and its outputs. Keep the Dot's follow-up record connected to the completed model review, without treating a “done” message as proof that all displayed references changed correctly.

Start with one unresolved question. Compare the resulting status notes with the original thread, check the schedule and stopping behavior, and refine the assignment before giving a Dot responsibility for more project follow-ups.