One Codebase, Three Industries: The Platform-Application Dual-Layer Architecture of combo agent

Building industry-specific AI products is hard in two ways: don't rewrite generic capabilities for every project, and don't let industry know-how pollute a shared framework and leak into other customers. combo agent separates these two concerns at the architecture level from day one.

TL;DR

The Dilemma of Industry AI Deployment

Two failure patterns we've seen repeatedly:

Type A: Generic AI assistant + industry prompt templates. Result: customers get "ChatGPT with a skin + a pile of system prompts." It can't answer professional questions, terminology is off, and workflows don't fit.

Type B: Build a product from scratch for each industry. Result: the business works, but when moving to the next industry you find yourself rewriting multi-Agent orchestration, context management, memory systems, and skill scheduling all over again.

combo agent's design: generic and industry-specific must be separated at the architecture level, but well-integrated at the product level.

What the Platform Layer Does

The platform layer is combo agent, providing capabilities that are industry-agnostic:

Full platform capabilities: combo agent User Manual.

What the Application Layer Does

Each industry gets one variant, layering industry-specific know-how on top of the platform:

The core of the application layer is encapsulating industry workflows and expert rules. For example, automotive's automotive-process-analyzer knows what a broken link in a V-model looks like; patent's patent-agent knows the structural constraints of independent and dependent claims; manufacturing's drawing-review knows how to classify "red/yellow/blue issues" in window engineering projects.

One Codebase, Three Websites

We didn't fork the codebase for each industry. Instead, we use NEXT_PUBLIC_SITE_VARIANT to switch on a single codebase:

• Landing page copy: messages/{locale}.{variant}.json overlays on top of the base messages/{locale}.json
• Brand config: config/sites/{patent,auto,mfg}.ts controls logo / site name / color palette
• Docs filtering: app/source.ts's VARIANT_HIDE ensures each site only sees its own industry's doc subtree
• Blog filtering: Each post's frontmatter variants: ["patent"] is filtered at runtime per variant

Result: xipnex.nox-lumen.com, auto.nox-lumen.com, and mfg.nox-lumen.com — three domains, three brand identities, three doc subsets — but new model releases, new generic Skills, and platform bug fixes are deployed exactly once.

              ┌─ patent (xipnex.nox-lumen.com)
              │
codebase ──┼─ auto   (auto.nox-lumen.com)
   │       │
   │       └─ mfg    (mfg.nox-lumen.com)
   │
   └─ Single git repo / single build pipeline / three deploy artifacts

Why This Architecture

Separating generic from industry-specific is better for customers and for us:

• Customers get a product that has been re-calibrated to their industry's terminology, workflows, and compliance language — not "generic AI assistant + customer-configured prompts"
• Upgrading the model or orchestrator benefits all three industries simultaneously; adding a new industry only adds a variant without touching the platform
• Data is strictly tenant-level physically isolated, no cross-customer "industry benchmark" training, customer data sovereignty is non-negotiable
• Platform changes run through a shared CI / shared e2e — regression happens once, all three benefit

Key Platform Capabilities

Code Index Three Tiers

Not "bare LLM reading a diff" — the platform supports selecting index depth by scenario:

ASIL-D module: "which downstreams are affected if I change this line?" — heavy index is mandatory. See Code Index Three Tiers.

Graft: Cross-Session Handoff

Each session is an isolated context, but sometimes you need to "relay" — e.g., after an ASPICE traceability analysis, the next session for change impact analysis should directly reuse the previous session's output without re-running everything. Graft makes handoff a first-class capability. See Graft Skill.

bug-import: Turn Historical Bugs into LTM

Import historical issues from Jira / Polarion / internal defect trackers via bug-import, aggregated along four dimensions: module hotspots / cross-module patterns / file hotspots / recurring root causes. Future code reviews that match historical patterns are automatically flagged bug_pattern_match. See bug-import Skill.

Deployment

• Multi-modal entry: Lark / WeCom / Email / Web SDK / HTTP API — same session identity across all channels
• Private deployment: On-premises / intranet / state-encryption compliant — meets OEMs, Tier1s, law firms, and manufacturing enterprises' data sovereignty requirements
• Managed operation: We continue maintaining after go-live; customers don't need to build an AI team (see Engagement Process)

Explore Each Industry in Depth

• Legal: xIPnex Progress · From Disclosure to Patent Draft
• Automotive: Nox-Lumen Auto Progress · ASPICE Engineering Loop Case Study
• Manufacturing: Nox-Lumen Mfg Progress · Window Engineering Customer Case Study

Full platform capability list: combo agent User Manual. All three industry application layers: solutions.