Digital room cutaway with retained enclosure edges and a revised internal partition. — Concept image (AI): architectural visualization for this research question.

Agent-Augmented Practice

How can an architect review, correct and take over a task prepared by an AI agent?

Design Knowledge & Workflows08 - TIMEResearch note

Study period: 2025-2026
Note updated: October 2026

The research question

An architectural task is rarely finished when a tool stops running. A drawing index must match the issued set; a layer-cleanup proposal must preserve meaning; a revision comparison must expose the changes that matter. This study examines the handoff between an agent and a human reviewer.

The proposed pilot uses one bounded office task with fixed source files and permitted changes. It compares a conventional brief with a short task instruction that includes inputs, checks and a reviewable output. Missing drawings, conflicting revisions and unavailable tools are intentional test cases.

We will measure the work required to accept the result, including preparation, review and reopened issues. Fraktal’s internal software practice informs the questions, but it does not establish a benchmark for architectural offices.

Source set. Three drawing records enter the same index task. The brief must define which revision belongs in the output.

Revision conflict. A02 arrives with a conflicting revision. The conflict remains in the task record instead of being silently resolved.

Reviewed handoff. The reviewed index travels with its source revisions and check record. Another person can see what was accepted and continue from that state.

Authored workflow example. No agent runs in this diagram. Document IDs are illustrative; completed checks refer to this example, not a live project.

Ideas and methods

Architectural Intelligence traces earlier experiments with computation and interaction in architecture. That history helps situate the agent as part of a design process. SWE-bench offers a contemporary example of task-based evaluation, while architectural acceptance still needs its own criteria and reviewers.

Read the sources ↓

Current work and the next experiment

On this page: A schematic brief, revision conflict and reviewed handoff sequence.
Planned output: A permission-cleared office task, a baseline workflow and independent records of review and repair.

How we will test it

Start from the same task: Record the manual workflow first, then compare a plain agent instruction with a versioned context and review checklist. Keep input files, permitted changes and acceptance conditions fixed across all options.
Count review and repair: Record task time, reviewer time, rejected changes and reopened issues separately. A fast first draft is useful only if the complete workflow benefits.
Test a cold handoff: Ask another person or a fresh session to continue from the recorded state. Identify missing assumptions without giving them the original conversation.

What remains open

A written handoff only carries the information it records. Missing assumptions or outdated decisions can be misinterpreted in the next session.
Review requires time and an explicit owner. Some decisions can be checked automatically; design intent, public claims and project commitments need the appropriate human judgment.
A successful build does not establish design quality. Layout, proportions, usability and architectural intent require their own review criteria.
The questions arise from Fraktal’s software practice. An architecture-office pilot still needs to test the method with different files and responsibilities.
This note reports no measured productivity result for an architecture office. The planned trial will examine total effort to reach an accepted output before considering first-draft speed.

Next output

The next output is a small set of office task cards with sample files cleared for use, expected checks and anonymised failure examples. We would test one workflow with an architecture office before treating the format as reusable. Fraktal’s contribution is the architectural context and review method that make an agent’s work legible.

Discuss the research Back to Lab →

Sources and method notes

Jimenez et al., SWE-bench (2023) ↗
Primary paper on evaluating repository changes through real software tasks. Its software benchmark is not an architectural quality measure.
MCP specification: Tools ↗
Tool definitions and invocation boundaries, specification 2025-11-25; checked 15 September 2026.
Molly Wright Steenson, Architectural Intelligence (2017) ↗
Historical account of architectural experiments with cybernetics, computation and interaction; MIT Press.

Research connections to our products

AI Systems: office workflows Pilot
The AI Systems pilot applies these questions to an architecture office: which information is needed, which tasks can be delegated and how the outputs will be reviewed. Scope is defined with the office before implementation.
AI Systems →
The products themselves Daily use
Our software projects provide practical contexts for trying this workflow. Their development status and available features are described on their respective product pages.
Products →