One Engine, Many Faces

The product problem nobody writes about

Most writing about AI agents focuses on models — which one to use, how to prompt it, how to make it produce better output. That's the visible layer. The invisible layer is the product architecture: how do you build one system that serves a researcher, a writer, and a filmmaker without becoming three separate products?

This is not a hypothetical. We run a system that does all three. The same engine, the same governance layer, the same worker, the same dashboard — configured differently for each operator. A researcher gets intake modes for questions and deep research jobs. A writer gets workflow stages for outlines, drafts, and revision with collaboration modes at each gate. A filmmaker gets a six-stage pre-production pipeline with storyboard generation and governed cloud spend on image and video models.

None of them share a prompt template. All of them share an engine.

The industry term for this pattern is "verticals." But the interesting question isn't the pattern — it's the specific decisions that make it work without collapsing into either a monolith (one product that tries to be everything) or a toolkit (a box of parts that requires engineering to assemble).

What a vertical actually is

A vertical is a configuration profile that shapes how the engine behaves. It specifies identity, intake, workflows, models, and governance — and the engine adapts accordingly.

Identity. The name, branding, and visual tone. A research operator sees "Torque Research" in orange. A filmmaker sees "Torque Cinema" in rose. The branding carries through the dashboard, the provenance records, and — when the system runs as a desktop application — the window title. Small details, but they make the difference between a generic tool and something that feels purpose-built.

Intake modes. What the operator can ask the system to do. Each mode has a name, a natural-language description, and a routing target. A research vertical might have four modes: ask, capture, remind, research. A cinema vertical has four different ones: script, storyboard, animate, research. The operator doesn't need to memorize these — the engine classifies incoming messages by semantic similarity using a built-in embedding model and routes automatically.

Workflows. Multi-stage pipelines where each stage has its own model preference, collaboration mode, quality validators, and approval gates. This is where verticals diverge most. A writing workflow has four stages: outline → draft → revise → publish. A cinema workflow has six: script analysis → scene breakdown → visual direction → storyboard generation → animatic generation → assembly. At each stage, the operator decides how human and machine share responsibility — fully autonomous, collaborative, assisted, or manual.

Model roster. Which providers handle which kinds of work. A research vertical maps everything to a local model. A cinema vertical maps text analysis to local, image generation to a cloud image model, and video to a cloud video model. The roster uses abstract slots — fast-local, capable, precise, image-cloud, video-cloud — so operators can swap providers without reconfiguring workflows.

Governance presets. Cost caps, approval rules, routing policies. A research vertical might allow $50/day in cloud spend. A cinema vertical sets the same ceiling but adds per-stage throttles that limit image generation to $20/day and video generation to $30/day. The governance layer enforces these automatically — the operator sets the ceiling once and the system respects it.

When an operator installs Torque, they choose a vertical. The engine, dashboard, worker, governance, ingestion, provenance, and semantic layer are all included. The vertical is what makes it theirs.

The decisions that make this work

Several architectural decisions are load-bearing for the vertical model. These aren't obvious from the outside, but they determine whether the system feels like a coherent product or a collection of features.

Collaboration modes per stage, not per vertical. The early design had a single collaboration mode for the whole workflow. Too coarse. A cinema workflow needs the script analysis to run autonomously, the visual direction to be entirely manual, and the storyboard generation to be autonomous with an approval gate before it proceeds. Four modes — autonomous, collaborative, assisted, manual — applied independently per stage, with per-stage approval gates. This granularity is what allows the same workflow engine to serve a writer who wants to co-edit drafts and a filmmaker who wants to set direction once and let the machine generate.

Typed outputs, not just text. The engine originally stored all work products as text. Cinema broke this immediately — storyboard frames are images, animatic clips are video, and the assembly stage produces an MP4. The solution was typed output formats: each workflow stage declares its output type (text, image, video, audio, or manifest). The worker detects the type and routes to the appropriate provider. The dashboard renders the right component — markdown for text, a gallery for image manifests, a video player for clips. This decision was made at the engine level, which means future verticals that produce non-text outputs (audio, data visualizations, presentations) get the same capability for free.

Governance as a shared policy layer. Every vertical's tasks pass through the same Arbiter governance engine. The routing rules, approval gates, and cost caps are declarative policy files evaluated in microseconds. When a new vertical introduces new task types, the rules extend rather than fork. A single policy system governs all verticals. The decision traces are identical in format regardless of which vertical produced the task. This means the trust center in the dashboard — where the operator sees exactly why the system made every decision — works the same way for everyone.

Semantic routing instead of mode selection. Instead of requiring operators to know and select intake modes by name, the engine embeds each mode's description and classifies incoming messages by semantic similarity. An operator who types "I want to look into something" gets routed to the research mode without knowing it exists. This works across verticals because the descriptions differ — a cinema operator's "script" mode and a researcher's "ask" mode have different semantic signatures but are classified by the same mechanism.

What the operator never changes

The shared infrastructure beneath the verticals is where most of the engineering investment lives. It includes:

A worker that polls a task queue, evaluates governance rules before every action, retrieves context from a distributed vector database with quantized search, calls the routed provider, and records provenance — complete with SHA-256 artifact verification, governance decision traces, and entity-level structural diffs that show what changed in terms of functions and sections, not line numbers.

A semantic layer with a built-in 384-dimension embedding model that runs locally with no API dependency. It powers response caching (avoiding redundant inference for semantically similar prompts), content indexing (finding related documents across the corpus), a hot index for recent session context, and a collaboration workspace where multiple workers share findings through CRDT-backed state.

A structural indexer that produces entity-aware chunks from content — splitting at function boundaries, class boundaries, and section headings rather than arbitrary character counts. When source material changes, impact analysis identifies which downstream work products are affected.

A coordination layer that prevents conflicts when multiple workers operate concurrently — claims, heartbeats, and stale-agent cleanup through a content-addressable object store.

A dashboard with seven pages — overview, chat, queue, workflows, trust, vault, settings — all updating in real time via WebSocket. The workflow page adapts to each vertical's output types, but the page itself is shared.

None of this changes when an operator chooses a vertical. None of it needs to be configured. It's the foundation that every vertical inherits.

The economics of sharing an engine

The vertical model has a compounding economic advantage that gets more pronounced over time.

When we replaced naive text chunking with structural entity-aware chunking — splitting at function and section boundaries instead of arbitrary points — retrieval quality improved for all three verticals simultaneously. Research briefs pulled tighter context. Studio drafts got more relevant source material. Cinema breakdowns referenced more precise prior work. One engineering investment, three quality improvements.

When we added semantic caching, inference costs dropped across all verticals. A cache hit on a semantically similar query saves the same tokens whether it came from a research session or a cinema pre-production run.

When we hardened the database layer for concurrent writes, the fix benefited every vertical — even the ones that hadn't triggered the race condition yet. Cinema's multi-shot storyboard generation was the stress case that revealed the bug. Research and Studio got the reliability improvement for free.

This is the argument against building separate products per use case. The cost of maintaining one engine is lower than the cost of maintaining three products, and the improvement velocity is higher because every fix compounds across every vertical.

For the operator, this means the product they're running today gets better over time in ways that have nothing to do with their specific vertical. A research operator benefits from work done to support cinema workflows, because the underlying retrieval, governance, and provenance systems improved in the process.

Where the model has limits

The vertical model isn't free. There are real constraints.

The engine's capability surface grows. Every vertical pushes the engine to support new output types, new provider integrations, new governance patterns. Cinema pushed asset-aware outputs and media providers. A future audio vertical will push mixing and sequencing. Each addition is backwards-compatible — existing verticals don't break — but the total complexity increases. The discipline is ensuring each extension follows the same pattern: typed outputs, governed routing, provenance recording.

Governance complexity scales with verticals. When the policy layer handles research, writing, image generation, and video generation — each with different cost profiles and approval requirements — the policy surface is no longer trivial. Research from 2026 on Governance-as-a-Service proposes modular enforcement layers with trust-factor scoring to manage this complexity at scale. The Arbiter architecture supports this direction, but for most operators today the default governance bundles handle the common cases well.

Cross-vertical work is not yet seamless. An operator who wants to research a topic, write about it, and produce visuals for it is currently switching between verticals. A future capability — cross-vertical workflows that chain research → writing → cinema stages into a single pipeline — is architecturally possible but not yet built. The engine supports it; the workflow configuration surface doesn't expose it yet.

What this is really about

The vertical model is a bet on a specific thesis: the value of an AI operating system is not in the model. It's in the governed infrastructure around the model.

The model is interchangeable — swap one local model for another, add a cloud fallback, change providers entirely — and the system keeps working. What's not interchangeable is the governance layer that prevents overspending, the provenance system that makes every decision traceable, the structural indexer that produces high-quality retrieval context, the semantic cache that eliminates redundant inference, and the coordination substrate that makes concurrent operation safe.

Build that infrastructure once, well, and you can point it at any domain by changing a configuration profile. Research, writing, cinema, audio, code generation, compliance review — each is a vertical with its own intake modes, workflows, model roster, and governance presets. The engine handles everything else.

The product isn't an LLM. The product is a governed, local-first operating system for autonomous work. The LLM is one component — routed by policy, constrained by cost caps, verified by provenance. The vertical decides what work the system does. The engine decides how it does it safely.

That's the split. And it's the split that lets an independent operator run multiple verticals on their own hardware, with governance they control, producing work products they can trace and verify. No cloud dependency. No vendor lock-in. No model lock-in. One engine, many faces.

Designing a vertical for your domain?

ResonanceWorks works with founders and small teams on agent architecture, governance, and vertical design. Talk to Consulting.

Want a system with verticals built in?

Torque Engineering ships Research, Studio, and Cinema verticals with Arbiter governance and local-first economics. Get Started.

Exploring human-machine culture?

Entrainment House publishes music, art, and cultural works shaped through human-machine coordination. Enter the House.