Nexus: The Harness Above the Vendors — What Agents-as-a-Service Actually Is
What Agents-as-a-Service actually is — the internal harness above eight LLM vendors so no SynaptixLabs product ever calls a provider directly. Route a request and watch it flow.

Most teams don't have an AI strategy. They have a pile of API keys.
One product wires itself to OpenAI. The next one reaches for Anthropic because the writing is better. A third bolts on Groq because it's fast and cheap. Each integration hard-codes a vendor SDK, scatters a secret in a .env somewhere, and invents its own logging — or skips it. Then a better model ships, and every one of those products needs a rewrite to adopt it.
This is the quiet tax on every company building with AI in 2026. It doesn't show up as a line item. It shows up as the reason swapping a model takes a quarter, the reason no one can answer "what did we spend on inference last month, and on what," and the reason sensitive data keeps leaking toward whichever cloud was easiest to call.
Nexus is our answer to a deceptively simple question: what if no product ever called an LLM provider directly again?
The problem isn't the model. It's the wiring.
At SynaptixLabs we don't have one AI product — we have a portfolio. A monitoring tool, a publishing platform, a marketing site with content crews, an eldercare assistant. Every one of them needs AI. And each one was, left to itself, about to grow its own provider plumbing.
Multiply one team's vendor lock-in by the number of products and you get the real shape of the problem:
- Keys everywhere. Every repo holds its own secrets, with its own blast radius.
- No shared audit trail. When a regulator — or a founder — asks "what ran, on which model, for whom," the answer is scattered across N codebases.
- Governance added last. Cost caps, PII rules, and clearance checks get bolted on after launch, if at all.
- No path off the cloud. The day a client needs classified data to stay inside a perimeter, "just call the API" becomes a per-product rewrite.
The instinct is to fix this with a shared wrapper — a thin library every product imports. But a wrapper still runs inside each product, still ships each product its keys, and still drifts the moment one team needs something the library doesn't do. A wrapper spreads the problem evenly. It doesn't remove it.
Agents-as-a-Service is a harness, not a wrapper
Nexus inverts the relationship. Instead of a library that lives inside every product, it is a service that sits above all of them — one layer between the entire portfolio and the model vendors. Internally it's named Synaptix AGENTS, and its README states the rule it exists to enforce, verbatim:
No product calls LLM providers directly; everything routes through AGENTS.
That single invariant is what makes this Agents-as-a-Service rather than "a few helper functions." One layer routes across eight providers behind one abstraction — Anthropic, OpenAI, Google, Groq, xAI, Mistral, DeepSeek, and Replicate — and every product talks only to the layer, never to a vendor.
Pick an agent below and route a request through it. Watch where it goes.
Loading visual...
The thing to notice isn't the animation — it's the shape. Every request takes the same governed path, no matter which product sent it or which model answers it:
Auth → KeyVault → load the agent from the catalog → 7-layer memory → system prompt → provider routing → SSE stream → usage tracking (SXC).
Each stop earns its place. Auth scopes the caller to a session. KeyVault resolves the vendor key (AES-256-GCM) so the secret never lives in the calling product. The agent catalog is a database row, not code — it carries the agent's model and cost tier. Memory assembles seven layers of context so the agent remembers across calls. The model_router chooses the provider. The response comes back as an SSE stream, and the request closes by metering itself in SXC — Synaptix Credits — so cost is a fact, not a quarterly archaeology project.
The model decides; Nexus routes, governs, and audits
Here's the part that wrappers can't do cleanly. In Nexus, the agent owns its model and tier — not the product calling it. The catalog assigns each agent a model and one of three cost tiers, Budget · Balanced · Creative:
| Agent | Model | Tier | Why |
|---|---|---|---|
vigil-router | Llama 3.3 70B (Groq) | Budget | High-volume triage should be cheap and fast |
vigil-coder | Claude Sonnet (Anthropic) | Balanced | Code reasoning is worth the spend |
synaptix-viz | dynamic creative cascade | Creative | Visual generation runs a multi-step DAG |
A bug-triage agent runs cheap on Groq while a coding agent runs on Claude — and the product that invokes them is none the wiser. When a better, cheaper model ships next month, you change one catalog row. Nothing downstream moves. That is the whole point of putting the harness above the vendors instead of inside the products: the swap happens in one place, and the audit trail comes for free because every call already passed through the same seam.
One harness, many shapes
Because the harness is general, the same machinery drives very different jobs:
- Inbound, governed pipelines — a request enters the perimeter, gets classified, looks in the knowledge base first, and when the KB misses, runs a governed fetch from official sources (triangulated, with provenance written back) instead of guessing. The harness turns a missing answer into a sourced one.
- Outbound agents that act like people — red-team and blue-team testers, synthetic stakeholders, support personas. A red agent on one model probes a target while a blue agent on a different model defends it, both orchestrated by the same conductor.
Cloud or fully on-premise. Because key resolution and routing are the harness's job, the same agent can run against a hosted frontier model or an open-source model inside an on-premise perimeter, where the data never leaves. The on-premise, any-LLM, data-sovereign path isn't a slide — it's a property of routing through one layer instead of N. (Try the illustrative sovereign-ops agent in the demo above — it resolves in-perimeter and never lights a cloud vendor.)
Under the hood it's a modular monolith — Python 3.12 and FastAPI, around twenty self-contained modules (llm_core, model_router, memory_core, crew_core, cascade_core, evals_core, the nexus_substrate governance plane), a React + Vite + Tailwind console, and Neon PostgreSQL underneath. Boring on purpose. The interesting behavior lives in the agents; the code just transports it.
Honest status: a golden goose, not a storefront
It would be easy to dress this up as a product launch. It isn't one, and saying so plainly matters more than the pitch.
Nexus is live — deployed on Google Cloud Run in europe-west1, and it is the engine behind the rest of the portfolio today. Its most recent sprint, Sprint 18, closed at a GBU grade of 4.4 (APPROVE) on a substrate-test floor of 751 passing tests and 1,659 unit tests. By every internal measure it works and it's load-bearing.
But "live" here means a live internal substrate, not a public SaaS. The PRD is explicit: Nexus is currently for SynaptixLabs — the company's "golden-goose" engine, the thing that lets a small team run like a large one. There are no external customers and no general availability. An outside release is a deliberate founder decision for later, not a thing that has quietly already happened.
And the known limitations stay on the table, because a substrate you can trust is one that tells you where it isn't finished yet:
- The
tools_coreregistry and runner exist, but the ReAct loop isn't wired to the invoke path yet. - Memory persistence currently uses an in-memory event store; durable vector memory (Qdrant) is planned, not shipped.
- The creative cascade is feature-flagged off by default.
The figures in the visualization above are honest about themselves too: the token and SXC numbers are fixed illustrative constants computed in your browser. No model is called, no secret is touched, and KeyVault is depicted, not invoked. The architecture is real; the demo is a diagram you can poke.
The payoff is structural
Strip away the pitch and what's left is an architectural bet that keeps paying:
- Swap a model in one place. Catalog row, not codebase migration.
- Keep sovereign data in-perimeter. Routing decides where inference happens; the product doesn't care.
- Get 100%-provenance auditing for free. Every call already crossed the same seam, so "what ran, on which model, for whom, at what cost" is one query, not an investigation.
Every other Agents-as-a-Service idea on this blog — routing, catalogs, memory, governance, metering — points back here, because Nexus isn't a thing that uses an AaaS engine. It is the engine. The harness above the vendors is the difference between owning your AI strategy and owning a pile of keys.
SynaptixLabs · the harness above the vendors.
SynaptixLabs