Modern Engineering Solutions

Last month I wrote that AI is architecture, not a feature, and showed you the project at the relational core. Several of you wrote back asking the next question.
What is actually inside the database, and how do the layers connect?
Top down, four of them. The rest of this article walks them in order.
88 / 100 SEO Score
Four-layer AI architecture diagram for engineering firms showing operating system at top, operational spine in middle, external edge layer, and AI agents reading all three layers

QUICK ANSWER

Most firms start with AI agents and bolt them onto whatever SaaS is already in place. That is why their AI sounds like a chatbot pretending to be the firm rather than the firm itself answering a question. The architecture that actually works has four layers: an operating system that defines truth, an operational spine that holds reality, an external edge that syncs the outside world, and agents that read all three. The shape of the stack matters more than any specific tool.

Layer 1 – The Operating System

The first is the operating system. It lives in a single table called os_documents that holds about seventy entries today. This is the firm’s brain in structured form, organized into five pillars.

Pillar 01 — First Principles Vision, mission, values the foundation everything else is interpreted through.

Pillar 02 — Strategy ICP registry, revenue strategy, quarterly plans.

Pillar 03 — Standards Load-bearing rules for sales, delivery, brand, HR, finance, and IT.

Pillar 04 — Execution Playbooks, decision rights, cadence how work actually happens.

Pillar 05 — Targets KPIs, revenue goals, staffing ratios, bonus tiers what the firm is measuring itself against.

Every other layer is interpreted through this one. A project’s gross margin is just a number until it is read against the firm’s stated target margin sitting in the operating system. Then it means something. The OS tells the AI what should be, not just what is.

Layer 2 – The Operational Spine

Below the OS sits the operational records layer the relational spine. Five core tables: Projects, Staff, CRM (deals, contacts, companies), Financial Records, and Activity Stream. Every other operational table in the database links back to the spine through a foreign key.

Time entries link to projects and staff. Payroll runs derive from time entries combined with the HR rules attached to each staff member. Bonus calculations join staff and projects against the bonus tiers in the OS. Milestones and tasks attach to projects. Content pieces, Teams messages, and call transcripts all flow into the activity stream.

The result: a single query can join time entries, project profitability, the engineer who logged them, and every email that engineer sent the client in one read.

Because that spine is native to the firm, the SaaS stack collapses. We built our own time tracking module on top of it. We built our own HR management module on top of it. CRM, project management, and email sequencing all run inside this database now. HubSpot is being shut down at the end of this quarter. Instantly is gone. Resend is gone. The firm controls its own data instead of paying half a dozen vendors to hold pieces of it.

Layer 3 – The External Edge

Below the spine sits the edge. This is the layer where regulated and external data lives natively and syncs in on our terms.

Edge 01 — QuickBooks Supplies invoices, estimates, and payments. Read in, not replicated.

Edge 02 — Microsoft Graph Handles SSO, SharePoint files, email, Teams, and calendars. Read and write.

Edge 03 — Google Analytics Suite GA4, Search Console, YouTube marketing and lead intelligence.

Edge 04 — Client Research Scraping and enrichment tools that supply prospect intelligence.

Anything regulated stays in its native system. Anything else gets pulled native. The rule is simple: we own what we can own, and sync what we must sync.

Layer 4 – The Agents

On top of all three sit the agents. Six department agents and one main Ask MES agent. None of them carry any hardcoded knowledge about the firm. Every fact in every answer comes from a tool call.

They have OS tools that search standards, spine tools that search projects, staff, the activity stream, and project profitability, edge tools that reach into email and QuickBooks, and department-specific tools on top.

Every agent is required to consult the operating system before answering any operational or strategic question, and every claim in their output is cited inline as [OS: slug] with a clickable link straight back to the source document.

When the marketing agent drafts a LinkedIn post, it pulls brand voice from the OS, the current ICP from the registry, recent project outcomes from the spine, and the last week of relevant activity from the stream – in one prompt.

When the finance agent runs a quarterly profitability review, it joins time entries, project budgets, payroll, and bonus rules in a single read and tells me which projects went sideways and exactly why.

Why the Shape Matters

The shape of the stack matters more than any specific tool.

Operating system on top defines truth. Spine in the middle holds reality. Edge syncs the outside world. Agents read all three.

Most firms invert it. They start with the agents and bolt them onto whatever SaaS is already in place. That is why their AI sounds like a chatbot pretending to be the firm rather than the firm itself answering a question.

Almost every firm I have looked at has a spine of some kind, no operating system at all, and a few agents bolted onto SaaS. If you want to map your own stack against this one, reply and tell me which layer you think you are missing.

Frequently Asked Questions

What is an operating system layer in the context of an engineering firm’s AI stack?

The operating system is a structured table in the database at MES it is called os_documents that holds the firm’s brain in structured form. It contains the firm’s vision, mission, values, ICP registry, revenue strategy, standards for every department, playbooks, decision rights, and KPI targets. Every AI agent reads this layer before answering any operational or strategic question. It is what separates an AI that knows the firm from an AI that is pretending to know it.

Why did MES shut down HubSpot, Instantly, and Resend?

Because the operational spine is now native to the firm’s own database. CRM, project management, time tracking, HR management, and email sequencing all run inside the same database that the agents read from. When your data lives natively in one place, you no longer need to pay multiple vendors to hold disconnected pieces of it. The SaaS stack collapses naturally once the spine is built.

What is the difference between the spine and the edge?

The spine holds the firm’s own operational records projects, staff, deals, financial records, and the activity stream. These are records the firm owns and controls entirely. The edge holds regulated or external data that must stay in its native system QuickBooks invoices, Microsoft Graph emails and Teams messages, Google Analytics data, and prospect intelligence. The rule is: own what you can own, sync what you must sync.

Why must agents consult the operating system before answering strategic questions?

Because without the OS, the agent has no standard to interpret data against. A project gross margin is just a number in isolation. Read against the firm’s stated target margin in the OS, it becomes a signal, on track, off track, or needs attention. The OS is what gives the agent the context to say what should be happening, not just what is happening.

Can small engineering firms build this kind of architecture?

Almost every firm already has a spine of some kind project records, staff records, some form of CRM. What most firms are missing is the operating system layer entirely. That is the layer that costs nothing to build except the discipline to write down what the firm believes, how it operates, and what it is measuring itself against. Start there. The agents are the last layer to add, not the first.

Engineering a Smarter Firm from the Inside Out

Modern Engineering Solutions works with engineering firms and municipalities to build the data infrastructure that makes AI actually useful not just another tool running in isolation.

We specialize in:

  • AI operations architecture for engineering firms
  • Operating system design, standards, playbooks, KPIs, and decision rights in structured form
  • Relational spine development across projects, staff, CRM, financial records, and activity streams
  • Agent design with OS-grounded tool calls and inline source citation
  • SaaS stack consolidation through native database ownership
  • Custom full-stack applications built with Claude Code for engineering firm workflows
Share via
Copy link