At Gottlieb, we're building AI agents for physical engineers—people who design jet engines, medical devices, and manufacturing systems. And we've learned something uncomfortable: the playbook for building software agents doesn't work when the consequences are physical.
The reason reveals something fundamental about what makes physical engineering different from software engineering—and why building agents for this domain requires rethinking everything.
The One Asset vs. Five Assets Problem
In software engineering, there's essentially one critical asset: the code.
Push to GitHub, and you've captured 95% of the value. Your codebase contains the complete specification, the executable artifact, the version history, and the ability to replicate the system anywhere.
Physical engineering doesn't work this way.
Ask any mechanical engineer: the CAD files are maybe 25% of the asset. To actually manufacture a jet engine, you need five critical assets:
1. The drawings (what to build) - CAD files, specifications, tolerances, assembly diagrams
2. The process documentation (how to build it) - manufacturing parameters, assembly sequences, heat treatment cycles, quality checkpoints
3. The tooling (means of production) - custom molds, jigs, fixtures, CNC programs, test equipment
4. The test data (proof it works) - validation results, failure analyses, destructive testing, regulatory certifications
5. The domain expertise (institutional knowledge) - the senior engineers who "just know" what works
Here's the critical insight: even with perfect CAD files, you cannot replicate a turbine blade.
GE's jet engine turbine blades are single-crystal superalloy castings. The material composition is published in patents. Competitors know exactly what it is. But they can't make it, because the process is the asset—temperature ramp rates, cooling sequences, furnace atmosphere. That knowledge took decades to develop.
This creates a fundamental tension: physical engineering knowledge is distributed across five asset types, none sufficient alone. Software concentrates everything in code.
Why This Breaks Traditional AI Agents
Most AI agent architectures assume the software model: code is truth, iteration is cheap, rollback is easy.
But when we built agents for physical engineers, we hit immediate problems:
Problem 1: The knowledge isn't in one place
An engineer asks: "What's the heat treatment cycle for 17-4 PH stainless steel?"
The answer isn't in CAD files. It's in:
- Process documentation (supplier specs)
- Test data (validation reports from previous projects)
- Domain expertise ("we tried this in 2019 and it failed because...")
- Tooling constraints (our furnace can't reach that temperature)
Traditional RAG (Retrieval-Augmented Generation) assumes documents contain the answer. In physical engineering, the answer requires synthesizing across all five asset types.
Problem 2: Errors have physical consequences
An agent suggests using 6061-T6 aluminum instead of 7075-T6. The code works perfectly. But:
- 6061 has 40% lower strength
- The part fails under load
- The $50K prototype is destroyed
- The project delays 6 weeks
You can't rollback a machined part. You can't patch a failed stress test. Physical iterations cost $10K-$1M and take weeks.
Problem 3: The critical knowledge is tribal
The most valuable engineering knowledge isn't documented anywhere:
- "This supplier's material certs are unreliable"
- "That tolerance is theoretically achievable but practically impossible"
- "The drawing says use Method A, but everyone knows Method B actually works"
An agent trained on documents misses the institutional knowledge that makes things actually work in production.
The Gottlieb Architecture: Five-Asset Agent System
Our architecture is inspired by the five-asset model.
Multi-Modal Knowledge Graph
Instead of traditional RAG over documents, we maintain a knowledge graph with five node types:
- Drawings - CAD files, BOMs, assembly diagrams
- Process - Manufacturing specs, supplier docs, work instructions
- Tooling - Equipment capabilities, fixture designs, CNC programs
- Tests - Validation reports, failure analyses, material certs
- Expertise - Engineer annotations, tribal knowledge, decision rationale
When an engineer asks "Can we substitute this material?", the agent:
- Retrieves the drawing (geometry and tolerances)
- Checks process docs (supplier qualification status)
- Queries tooling constraints (can our equipment work this material?)
- Reviews test data (have we validated this material before?)
- Surfaces expertise nodes (what did senior engineers document about similar substitutions?)
The answer synthesizes all five assets, not just documents.
Validation Against Physical Constraints
Agents for software engineering validate against code. Our agents validate against physical reality:
Symbolic constraint checking:
- Material property databases (actual strength, not LLM guesses)
- Tolerance stack-up analysis (geometric math, not approximation)
- Regulatory requirement matching (exact compliance, not "sounds right")
Multi-model verification for high-stakes decisions:
- Design changes: two LLMs must independently agree, plus symbolic validator
- Material substitutions: check against materials database AND past failure library
- Process modifications: validate against physics simulation, not just textual reasoning
Human-in-the-loop for irreversible actions:
- Ordering $50K+ tooling → requires approval
- Releasing drawings to manufacturing → requires PE sign-off
- Making design changes after first article → requires review
This mirrors how physical engineers actually work: cheap analysis upfront, expensive validation before committing physical resources.
Institutional Knowledge Capture
The hardest problem: capturing tribal knowledge before it walks out the door.
Our approach:
- Decision trace logging: Every time an engineer overrides agent suggestion, we capture why
- Failure annotation: When prototypes fail, engineers tag the relevant drawings/processes/decisions
- Review cycles as knowledge generation: Senior engineer reviews tune the agents
- Collaborative refinement: Agents propose, engineers correct, corrections become new expertise nodes
Example: An agent suggests a welding sequence. Engineer says "No, weld these joints first or thermal distortion will throw off final dimensions." This becomes an expertise node linked to that geometry type, enriching future suggestions.
Over time, the agent doesn't just retrieve documents—it accumulates the institutional knowledge that makes experienced engineers valuable.
What This Enables: The Compound Effect
By respecting the five-asset model, we enable capabilities impossible for traditional agents:
Cross-project knowledge transfer: "Show me every time we've used Inconel 718 in high-temperature applications"—retrieves drawings, processes, test data, and failure notes across 10 years of projects.
Supplier risk assessment: "This supplier just changed ownership"—agent surfaces all parts from that supplier, alternative sources, past quality issues, and re-qualification requirements.
Rapid design iteration with safety rails: Engineer sketches a modification. Agent validates against: drawing standards, manufacturing capabilities, material availability, past failures of similar changes, regulatory requirements. Suggests refinements before any physical prototype.
Onboarding acceleration: New engineer asks "Why did we choose this bearing?" Agent surfaces: the analysis (test data), the decision rationale (expertise node), the alternative considered (archived drawings), and the manufacturing constraint that was decisive (process doc).
The Deeper Insight
Here's what we've learned: AI agents for physical engineering can't just be smarter search. They must model how engineering knowledge actually exists—distributed, interdependent, and accumulated over decades.
Software agents can be Revolutionary because software is plastic: deploy fast, break things, patch quickly.
Agents for physical engineering must be Evolutionary: they compound institutional knowledge over time, enable faster iteration within safety constraints, and prevent expensive failures before they happen.
The irony: this makes them more defensible than pure software agents. Our moat isn't the LLM or the code—it's the five-asset knowledge graph we're building for each customer, accumulating their institutional knowledge in a queryable, compoundable form.
This is the future of AI for physical industries: not replacing engineers, but finally giving them a system that respects how their knowledge actually works.
