Architecture Firms Need an Agent Harness

The next question

Architecture Studio started with a simple question: what happens when Claude is structured for architectural work?

Not prompted. Structured.

That question builds on a broader shift in agentic AI for AEC: the useful system is not a generic model, but a managed workflow that can use context, tools, memory, and review. It also changes how firms should think about their AI stack, because model access alone is not enough.

A zoning task needs sources. A workplace strategy task needs assumptions. A specification task needs format. A sustainability task needs evidence. An FF&E task needs products, quantities, dimensions, finishes, prices, substitutions, and review states. These are not vibes. They are professional workflows with rules, artifacts, and consequences.

That is why Architecture Studio was built around agents, skills, plugins, source expectations, and review patterns. It proved that AI becomes more useful to architects when the model is surrounded by domain structure.

Norma came from the next question: what should those agents remember?

Product and material knowledge does not live in one clean catalog. It lives in schedules, quotes, PDFs, vendor pages, emails, finish cards, substitutions, comments, and project history. Norma turns that mess into private, cited, reusable studio memory.

So the next question is not whether architects will use AI.

They already are.

The next question is: what runs all of this inside a real architecture firm?

Not a chatbot. Not a prompt folder. Not a single SaaS interface.

A harness.

What a harness does

An agent harness is the runtime around the model.

It decides where instructions live, which tools the agent can call, how sessions continue, how work gets delegated, how humans approve sensitive actions, how files are read and written, how state survives across turns, and how the same agent appears in a browser, Slack, Teams, email, or an internal tool.

The model is the engine. The harness is the practice environment around it.

That distinction matters because architecture work is not one request and one answer. A building project lasts months or years. It accumulates decisions, sources, constraints, exceptions, and partial knowledge. The useful system is not the one that gives a clever answer in a chat window. It is the one that can keep working with the project record as the project changes.

This is why Vercel’s eve is interesting.

eve is a filesystem-first framework for durable agents. An agent is laid out as ordinary files: instructions, tools, skills, channels, subagents, sandbox rules, hooks, and configuration. The directory tells you what the agent can do before it runs.

That sounds small, but it is the right primitive.

Architecture firms do not need more opaque AI products. They need agent systems they can inspect, adapt, govern, and connect to the way their teams already work.

AI agents for architecture firms

For architecture firms, the useful question is no longer whether to use AI tools. It is how to run AI agents safely across project research, zoning analysis, specification writing, FF&E schedules, material libraries, and design documentation.

That shift changes the architecture of the software. A firm does not need one generic assistant with access to everything. It needs a controlled system of specialists: a site research agent, a zoning agent, a workplace programming agent, a product and materials researcher, an FF&E schedule manager, a sustainability reviewer, and a spec-writing workflow.

Each agent needs the same basic contract: clear instructions, bounded tools, source expectations, review states, and a place to write durable project memory. Without that contract, “AI for architecture firms” stays at the level of ad hoc chat. With it, agentic AI becomes workflow automation the firm can audit.

That is the role of the harness.

Firms are already agent systems

A design studio already works like a multi-agent system.

A project has specialists. The zoning lead checks the envelope. The workplace strategist studies the program. The designer develops room packages. The FF&E lead manages product selections. The spec writer turns decisions into documentation. The project manager remembers what changed. The principal remembers why.

Each role has its own sources, vocabulary, judgment, and failure modes.

Software usually flattens this into one interface. AI products often flatten it further into one chat box.

That is the wrong shape.

A useful architecture agent should be able to delegate. It should know when a task belongs to a zoning specialist, a materials researcher, a workplace strategist, or an FF&E schedule manager. It should keep those specialists narrow enough to be reliable. It should give them tools appropriate to their work. It should preserve the source trail when they return.

eve makes that shape natural.

The root agent can route work. Subagents can carry specialist identities. Skills can load only when needed. Tools can connect to project systems. Channels can meet the team where they already communicate. Sessions can persist beyond one turn.

This is the missing layer between “I have a good Claude prompt” and “my firm has useful AI staff.”

Architecture Studio becomes the studio agent layer

Architecture Studio already contains the domain structure.

It has agents for architectural tasks. It has skills for due diligence, programming, specifications, sustainability, materials, presentations, and FF&E workflows. It has rules about sources, uncertainty, review, and output quality. It has project dossiers and decision logs so work does not restart from zero every session.

In Claude Code, that makes Architecture Studio a powerful professional workbench.

With eve, the same logic can become firm infrastructure.

A studio could run an agent that knows how the firm works, which workflows are available, which tools are allowed, what project files exist, what needs approval, and which specialist should handle a request.

A designer could ask for an FF&E schedule cleanup. The root agent delegates to the FF&E specialist. The specialist normalizes product names, flags missing dimensions, catches duplicate SKUs, preserves uncertainty, and prepares a clean schedule.

A project manager could ask what changed since the last client review. The agent checks the project dossier, decision log, schedule, and source history.

A principal could ask why a material substitution was accepted. The agent retrieves the decision record, quote context, lead-time constraint, and approved alternative.

A new team member could ask what the project already knows.

That is the shift: Architecture Studio stops being only a catalog of Claude-native skills. It becomes the studio agent layer.

Norma becomes the material memory layer

If Architecture Studio is the agent layer, Norma is the product and material memory underneath it.

Agents can parse, clean, enrich, audit, stage, and draft. But without memory, they keep rediscovering the same facts.

Norma gives those agents a private product memory to consult and improve:

• Products the studio has specified.
• Finishes the studio has approved.
• Vendors the studio has worked with.
• Quotes the studio has received.
• Lead times that changed.
• Substitutions that were accepted or rejected.
• Stale source links.
• Missing fields.
• Project-specific decisions.
• Studio-specific preferences.

This is not a traditional material library.

A traditional material library assumes humans will maintain the database. Someone has to upload the cut sheet, tag the product, update the price, remember the quote, remove the discontinued SKU, and connect the selected finish back to the project.

That work rarely happens cleanly because the project is moving.

An agent-first material library works differently. The library is built as agents do useful work. A schedule cleanup becomes memory. A quote review becomes memory. A substitution becomes memory. A corrected dimension becomes memory. A client-approved finish becomes memory.

The library is not upstream of the work.

It is the residue of the work.

The interface is not the work

The temptation is to ask what the app looks like.

That is usually the least interesting question.

The agent might appear in a web chat when a designer wants a focused session. It might appear in Slack when a project team asks a quick question. It might run on a schedule before every client meeting to flag stale sources. It might update a spreadsheet. It might draft a spec-book section. It might read a project folder. It might use Norma as the review surface for product facts.

The surface changes. The agent, tools, memory, and rules stay consistent.

This matters for architecture firms because work does not live in one place. A project is spread across drawings, schedules, PDFs, folders, emails, spreadsheets, models, decks, and conversations. A useful AI system has to operate across those surfaces without forcing every artifact into a new dashboard first.

The screen is not the work.

The work is the project record, the decisions, the sources, the constraints, and the people reviewing them.

What this enables first

The first useful workflows are not magical.

They are the boring, high-friction tasks studios already do:

• Clean an FF&E schedule.
• Normalize product rows with product data cleanup.
• Flag missing dimensions, finishes, prices, and lead times.
• Trace products back to sources.
• Compare quotes.
• Prepare procurement exports.
• Draft room packages.
• Audit stale product data.
• Maintain a project dossier.
• Capture a decision record.
• Prepare a spec section with the spec writer.
• Summarize unresolved review items.

The value is not that any one of these tasks becomes faster, though many will.

The value is that the task leaves something behind.

A checked schedule leaves reviewed product facts. A quote leaves pricing context. A substitution leaves a decision. A source refresh leaves a timestamp. A corrected row teaches the system how the studio wants that product represented.

That is how a practice compounds.

The stack we are building toward

For ALPA, the shape is becoming clear.

Architecture Studio is the domain layer: agents, skills, workflows, and professional rules for architecture and design.

eve is the harness: the durable runtime that lets those agents run as an application, connect to channels, call tools, delegate work, preserve sessions, and operate inside a controlled environment.

Norma is the memory layer: the private product and material library that accumulates from real project work.

The project folder remains the record: schedules, dossiers, decisions, sources, exports, and review artifacts the studio can keep, inspect, and move.

This is not another drawing tool. It is not another product database. It is not another wrapper around a model.

It is a way to give a studio durable AI staff with memory.

Mess as infrastructure

The built environment runs on data nobody indexed.

That does not mean the industry is waiting for one universal schema to clean everything up. The mess is not just a defect. It is evidence of how the industry actually works: local practices, vendor relationships, jurisdictional rules, project exceptions, private pricing, client preferences, and accumulated judgment.

Architecture firms do not need AI systems that pretend the mess is gone.

They need agents that can work inside it, preserve sources, ask for review, remember decisions, and make the next project easier because the last project happened.

That is why the harness matters.

Without a harness, AI stays trapped in the chat window.

With a harness, agents can become part of the practice.

Architecture Studio gives those agents architectural judgment. Norma gives them product and material memory. eve gives them a runtime.

That is the next layer we are building.

For the background, read Introducing Architecture Studio, Architecture Studio at Three Months, and Introducing Norma.

---

Architecture Studio and Norma are built by ALPA - research, strategy, and technology for the built environment.