Your Pricing Model Lives in One Person's Head

What Is LLM Model Architecture?

LLM model architecture refers to how large language models are structured internally— specifically, the transformer-based system of layers that encodes inputs, processes relationships through self-attention, and generates outputs one token at a time. GPT, Claude, Gemini, and every other major AI model you've used runs on this same foundation¹.

The transformer was introduced in 2017 in a paper called "Attention is All You Need."² It replaced sequential word-by-word processing with a mechanism that handles entire text sequences simultaneously— letting the model understand the relationship between any two words regardless of how far apart they appear. That's the core innovation: parallel processing driven by attention.

Inside the transformer, each word (or "token") generates three vectors — a Query (what it's looking for), a Key (what it offers), and a Value (what it holds) — and the model uses these to weigh the relevance of every other word simultaneously². That's what lets it understand that "the bank I went to" and "the bank of the river" use identical words to mean completely different things.

Not all LLMs are built the same way. Three architecture types exist³:

Most of the AI tools your team uses daily— large language models like GPT and Claude— run on decoder-only architecture. They generate. They don't just analyze.

Transformer architecture enabled GPT, Claude, and Gemini— and the same architectural principles that make those models effective apply to how professional services firms can design their own knowledge systems. We'll get there. First: how do these models actually store what they know?

Two Ways an LLM Can Know Something

LLMs can "know" things in two fundamentally different ways: baked into their parameters (weights learned during training) or retrieved at runtime from an external knowledge base. The distinction matters enormously for how useful— and how risky— any AI system is.

Parameters (or weights) are the billions of numerical values adjusted during training as the model processes examples. Knowledge is distributed across those values, not explicitly stored anywhere you can point to³. You can't search a model's weights. You can't update them without retraining the entire system. If the training data is wrong or outdated, the model doesn't know it's wrong.

RAG (Retrieval-Augmented Generation) solves this by adding a retrieval layer. At inference time (when a user asks a question), the model pulls from an external knowledge base rather than relying solely on what was baked in during training⁴. The knowledge is updateable. It's auditable. And because the model grounds its responses in retrieved documents rather than statistical patterns, hallucination rates drop significantly.

Fine-tuning sits between these two approaches — updating weights with targeted examples rather than full retraining. But enterprise knowledge systems favor RAG because it's updateable and auditable without any training process at all.

Hold that mental model. We'll map it directly to your firm's pricing problem.

Your Firm's Pricing Logic Runs Like a Pre-RAG LLM

Most AEC firms price projects the same way a pre-RAG LLM "knows" things: all the logic is internalized by individuals, built up over years of experience, and not queryable by anyone else. When the person isn't available, the knowledge isn't available.

The American Institute of Architects and Archtoolbox confirm what most principals already know. As Archtoolbox states directly⁵:

"Every firm and every project manager have their own preferred worksheets for preparing a fee. These have been developed over years of experience and they understand the nuances of their preferred structure."

That's the pricing-parameters problem in plain language. The logic is baked into individual experience— not retrievable by anyone else.

The fee ranges vary (7-10% of construction costs for general projects, 8-15% for residential, 15-20% for renovations⁷), but the range itself isn't the issue. The issue is that arriving at any number in that range depends entirely on whoever is doing the calculation. About 67% of AEC firms use hourly billing as their primary fee method⁷— which means rate decisions, scope estimates, and phase allocations all live in specific people's heads, not in a shared system.

And here's the tell: the AIA recommends that no fee proposal goes to a client without thorough review by a second person⁶. That guidance isn't unreasonable. But notice what it reveals— the knowledge is so undocumented that even the trade body's recommended safeguard is a manual human check. No reference document. No shared logic. Just two people.

The same logic that drives an AI strategy for your firm applies here: you can't build on a system that only one person can access. The parallel isn't a criticism of how the industry developed— it's an observation about the risk that comes with it.

What Happens When the Model Walks Out the Door

Key person dependence in a professional services firm doesn't just create a coverage gap. According to Auxo Capital Advisors, an AEC M&A advisory firm, it directly compresses your firm's valuation when you go to sell⁸.

The risk shows up in three concrete scenarios:

• M&A event: Buyers assess transition risk during diligence. "Owner dependence and transition risk directly compress multiples when these firms are being valued or sold,"⁸ per Auxo Capital. A firm that can't demonstrate pricing processes independent of a specific individual gets repriced late in the transaction.
• Partner departure: When the person who holds the pricing logic leaves, that knowledge goes with them. "When they leave the firm, that tribal knowledge walks out the door with them,"⁹ per Spiral Scout. The firm can usually reconstruct it— but inconsistently and slowly.
• Coverage gap: It works until someone needs a proposal while the principal is unavailable. Either it waits, or someone else takes a run at it with less calibration. Neither outcome is good.

APQC's 2026 knowledge management research confirms this isn't just an AEC problem¹⁰. Leaders across industries recognize how risky it is to concentrate critical knowledge on a small number of employees— and the redundancy of knowledge is critical to any business strategy. But AEC's pricing complexity makes concentration especially acute.

The fix isn't a new hire. And the hidden costs of undocumented operational knowledge accumulate long before a departure or exit event triggers the crisis. You solve this architecturally: by making the knowledge retrievable.

Building Your Firm's Pricing Knowledge Architecture

The RAG parallel for your firm is straightforward: externalize the pricing logic from individual heads into a shared knowledge base anyone can query. You don't need a vector database to start. You need a pricing playbook— a documented source of truth for how your firm makes fee decisions.

The parallel isn't a technical equivalence. A pricing playbook isn't literally a vector database, and a senior partner isn't a transformer model. But the structural insight holds: separate the broad capability (the partner's judgment) from the specific retrievable knowledge (the documented framework), and you've built something durable.

Here's the four-step sequence:

Step 1: Capture the worksheets (months 1–2)

Pull fee worksheets from every project manager and principal who prices work at your firm. Don't normalize yet— capture the variation. The variation is data. Your goal at this stage is understanding what assumptions are built into each person's methodology.

Step 2: Extract the decision rules (months 2–3)

For each worksheet: what are the inputs? What decisions get made? Under what conditions does a principal override the formula? Those override conditions are where the expertise actually lives. Document them explicitly as questions and answers— not just numbers in a spreadsheet.

Step 3: Build the knowledge base (months 3–6)

Start with a pricing playbook: a shared document that captures fee ranges by project type, scope inclusion/exclusion logic, known risk adjusters, and historical calibration data from past projects. This is your RAG analog— retrievable by anyone at the firm, not just the person who built it. Systematic tracking of actual hours against phase allocations transforms fee estimation from guesswork into informed decision-making grounded in empirical project data⁷. At scale, this becomes the foundation for an AI-enabled fee estimation tool. The playbook works without AI.

Step 4: Build the review process (ongoing)

AIA already recommends second-person review for every proposal⁶. That review needs a reference point. The playbook is the reference. Use structured post-mortems: when actual project hours diverge from estimates, update the knowledge base. That's how the system learns without retraining.

Spiral Scout's CTO Anton Titov said it plainly⁹: "The model is the commodity. Everyone gets the same GPT, the same Claude. What you can't download is twenty years of a firm knowing which clause in a contract actually matters."

Document it, and you've built something competitors can't replicate. And you've built the foundation for building AI-ready processes inside your firm that will actually work.

The First Step Before Any AI Tool Can Help You

If you're evaluating AI tools for proposal writing, fee estimation, or client communication— the pricing knowledge architecture you just built is the prerequisite. An AI system can only retrieve what's already documented. Full stop.

This is the core position on AI that informs everything here: it's intellectual augmentation, not replacement. AI, in my view, is a way to move closer to our humanity — to amplify what's distinctly human, not replace it. The retrieval layer doesn't make the decision. Your partner does. But it makes that judgment available to everyone on your team— not just the person who developed it over 20 years.

Most firms try to implement AI tools before they've documented what they know. The result: AI that generates generic, uncalibrated output that doesn't reflect the firm's actual approach. Build the knowledge base first. The AI layer follows naturally.

If you're not sure where to start, an AI implementation partner can help you map the knowledge your firm already has and build the systems to make it retrievable. The starting point is simpler than you think.

Frequently Asked Questions About LLM Model Architecture

What is LLM model architecture?

LLM model architecture refers to how large language models are structured internally— specifically, the transformer-based system that processes text by predicting the next token using patterns learned across billions of examples¹². The transformer, introduced in the 2017 paper "Attention is All You Need," is the foundation for GPT, Claude, Gemini, and every other major AI model. Most business AI tools run on decoder-only architecture, which means they generate text rather than simply classify it.

What are the three types of LLM architecture?

The three main types are encoder-only (like BERT, used for understanding and classification tasks), decoder-only (like GPT and Claude, used for text generation), and encoder-decoder (like T5, used for translation and summarization)³. Most business AI tools your firm would adopt run on decoder-only architecture.

What is the difference between RAG and fine-tuning in LLMs?

Fine-tuning bakes specific knowledge deeper into a model's weights— expensive and inflexible once done³⁴. RAG (Retrieval-Augmented Generation) retrieves knowledge from an external knowledge base at query time— updateable without retraining and significantly reduces hallucination⁴. Enterprise knowledge systems favor RAG for business-specific information because it's auditable and can stay current without rebuilding the model.

How does pricing knowledge concentration affect AEC firm valuation?

Key person dependence on a single partner who holds pricing knowledge directly compresses valuation multiples when AEC firms are sold⁸. M&A buyers discount for transition risk— a firm that can't demonstrate pricing processes independent of a specific individual gets repriced late in the transaction. The fix is architectural: document the pricing knowledge the firm owns, not what one person holds.

What percentage do architects typically charge?

Architecture fees typically range from 7-10% of construction costs for general projects, 8-15% for residential, and 15-20% for renovations⁷. Federal projects typically fall in the 5.42-10% range. But the fee range matters less than the methodology— and most firms build those numbers from individual worksheets, not a shared system.

References

1. IBM, "What Are Large Language Models (LLMs)?" (2025) — https://www.ibm.com/think/topics/large-language-models
2. DataCamp, "How Transformers Work: A Detailed Exploration of Transformer Architecture" (2025) — https://www.datacamp.com/tutorial/how-transformers-work
3. LabelYourData, "LLM Architecture: Possible Model Configurations in 2026" (2026) — https://labelyourdata.com/articles/llm-fine-tuning/llm-architecture
4. Pinecone, "Retrieval-Augmented Generation (RAG)" (2025) — https://www.pinecone.io/learn/retrieval-augmented-generation/
5. Archtoolbox, "Calculating an Architectural Fee for Services" (2025) — https://www.archtoolbox.com/calculate-architectural-fee/
6. American Institute of Architects, "Setting Fees: What to Consider" (2025) — https://www.aia.org/resource-center/setting-fees-what-consider
7. Monograph, "Architectural & Engineering Fee Estimating Guidelines" (2025) — https://monograph.com/blog/architectural-engineering-fee-estimating-guidelines
8. Auxo Capital Advisors, "AEC M&A Deal Trends 2025" (2025) — https://auxocapitaladvisors.com/deal-trends-aec-2025/
9. Spiral Scout, "Encode Your Firm's Tribal Knowledge Into AI Before It's Too Late" (2025) — https://spiralscout.com/blog/encode-tribal-knowledge-professional-services-ai
10. APQC, "Top 5 Knowledge Management Threats for 2026" (2026) — https://www.apqc.org/resource-library/resource/top-5-knowledge-management-threats-2026