How we work
The architecture, technology, and evidence behind how Secular Labs builds AI-native systems.
A number you investigate, not one we promise.
We evaluate AI-native systems against operational and economic outcomes — not model benchmarks.
| Revenue per core employee | The efficiency metric the 3–100x range above is built from. |
| Workflow throughput | How much gets processed per unit of time, before and after redesign. |
| Cycle time | How long a single request takes end to end. |
| Automation coverage | What share of a workflow runs without a human touching it. |
| Exception rate | How often a case has to escalate to a human, and why. |
| Verification coverage | What share of decisions pass through an explicit check before committing. |
| Operating cost per transaction | Compute and verification cost, measured per unit of work — not per headcount. |
The flow, before the detail.
A model call is the expensive option — we treat it that way.
Replacing headcount with agent orchestration only works if the new cost is genuinely lower and bounded. If every step in the process routes through a large model regardless of whether it needs to, the business hasn't cut cost — it's just swapped a labor bill for a token bill, and one that can grow just as unpredictably. Our architecture is built specifically to avoid that.
-
Deterministic logic first, the model last
In the IVT plugin, for example, a risk verdict is decided entirely by rule-based scoring blended with a lightweight anomaly-detection model — no LLM call in that path at all. A model is only invoked afterward, optionally, to turn an already-decided verdict into a human-readable explanation. If that call fails or times out, the verdict still returns. The model never sits on the critical path where a cheaper method would do.
-
Routing to the cheapest sufficient model
LiteLLM picks a model per request based on what the task actually needs — a frontier model for genuinely hard reasoning, a smaller or self-hosted open-weight model (via vLLM) for high-volume, low-complexity calls. Most requests in a production system are the latter, not the former.
-
Retrieval instead of bigger prompts
pgvector fetches only the relevant context for a given request instead of stuffing everything into the prompt. Smaller, targeted context windows mean fewer tokens per call, consistently, not just when someone remembers to optimize it.
-
Validation to avoid paying twice
Guardrails AI catches malformed or failed outputs before they reach the client — the alternative is a silent re-ask loop that quietly doubles or triples the token spend on a single request without anyone noticing until the bill arrives.
-
Cost visible on every request, not just the invoice
Langfuse logs token count, cost, and latency per call. That means compute spend is a monitored, bounded line item from day one — not something discovered after it's already scaled past the point of being fixable.
This is also part of what we check for in an AMEA Growth Audit: whether a proposed AI system is actually cheaper to run than the process it replaces, once every model call is accounted for — not just cheaper in headcount.
Three real workflows, before and after.
Not a generic "traditional company vs. AI company" diagram — these are our own production and applied-research workflows, the same ones described in Case Studies.
Fraud & traffic-quality scoring
Before — a request arrives → a person or a rigid script checks it against a fixed rule list → ambiguous cases sit in a manual review queue → a decision is made after the bidding window has often already closed.
AMEA — request → rule-based scoring + anomaly detection running concurrently → verdict (Clean / Suspicious / Blocked) → optional plain-English explanation → logged for audit — all inside the bidding window.
Campaign discovery & negotiation (AdCP)
Before — a media buyer manually researches audience segments, requests pricing from multiple publishers, and negotiates terms over email or a call — a process measured in hours or days.
AMEA — advertiser agent expresses intent → publisher agent responds with segments and metadata → agents negotiate directly, logged and auditable → campaign activates — a process measured in minutes.
Programmatic bid clearing
Before — operations teams manually reconcile discrepancies between what was bid, what cleared, and what was billed — often discovered hours or days after the fact.
AMEA — every bid state transition passes a verification check before it commits — discrepancies are prevented at the point of clearing, not discovered afterward in reconciliation.
What's actually different about what we build.
AI agents are easy to demonstrate. Reliable autonomous systems are harder. This is the architecture that makes the difference.
-
Deterministic Orchestration
Coordinate autonomous systems through explicit execution structures and constraints — not open-ended conversational loops.
-
Verification-Gated Execution
Critical actions require defined verification before they're allowed to proceed to downstream execution.
-
Bounded Self-Correction
Systems can correct themselves within predefined operational boundaries — and stop when they exceed them.
-
Human Exception Handling
Defined classes of uncertainty, failure, or exceptional conditions escalate to a human, rather than getting guessed through.
-
Auditable Execution
Every action, decision, and verification event is inspectable after the fact — not reconstructed from memory when something goes wrong.
Not just an architecture on paper.
We don't present everything with equal certainty — production, proof-of-concept, and research are different evidence levels, and we keep them labeled that way.
-
Production
Programmatic infrastructure
OpenRTB-compliant supply- and demand-side integrations, header-bidding, and marketplace transaction logic for international DSP/SSP operators.
-
Prototype / proof-of-concept
AdCP integration
A proof-of-concept for agent-to-agent campaign discovery, negotiation, and activation — agentic commerce, not a slide deck. Not yet a production deployment.
-
Production
Real-time fraud detection
A production IVT plugin combining rule-based scoring with anomaly detection, fast enough to sit on the live bidding path.
AI-first, not AdTech-first.
Hands-on experience running real-time DSP/SSP and OpenRTB infrastructure gives us an unusually direct proving ground for agentic AI specifically — not tooling in general. All built on the same architecture above, and available through our engineering practice at reviveadservermod.com. Our third working paper benchmarks this approach directly against traditional ad-operations workflows — see Research for the results.
-
IVT / Fraud Detection
Real-time invalid-traffic scoring on the bid path — rule-based weighted signals blended with an unsupervised anomaly layer, returning a Clean / Suspicious / Blocked verdict fast enough not to add latency to serving.
-
AI Analytics Copilot
A conversational front door to campaign data — plain-English questions answered from live metrics and campaign documents together, with every answer traceable back to its source.
-
RTB Intelligence Engine
Analysis across bid requests and responses — win rate, latency, timeout rate, and floor-price impact — surfaced as a plugin rather than a separate reporting stack.
-
Banner Ad Generator
Plain-English creative briefs turned into finished, pixel-exact banner ads across every standard IAB size, with instant revisions.
In focus: the MCP natural-language database agent
This is our clearest example of what "AI-first" means in practice. Instead of a person writing SQL, or a chart dashboard someone has to learn, a team member simply asks a question in plain English — the agent discovers the actual database schema itself, generates a read-only query against it, and answers in plain English. It never receives write access or database credentials, and every query is logged for audit.
-
Verification-Gated
Critical actions pass through defined validation before execution.
-
Model-Agnostic
Built on MCP (Model Context Protocol) — the reasoning layer routes across supported models (Gemini, Groq, others) rather than locking to one.
-
Auditable
Every query, decision, and execution event is logged — the same audit trail used across our production architecture.
-
Bounded
Read-only by design — the agent never receives write access or database credentials, regardless of what it's asked.
AdContext Protocol (AdCP)
We've contributed to AdCP, an open standard for agent-to-agent advertising workflows — letting an advertiser's AI agent and a publisher's AI agent discover audiences, negotiate pricing, and activate a campaign directly, with every interaction logged and auditable. It's a working example of agentic commerce, built on the same orchestration and verification principles behind our AMEA advisory practice — and a concrete case study for what "agentic AI in production" looks like outside a slide deck.
See it in a case study
Technical due diligence for AI-native investments
For family offices, venture funds, and private equity firms underwriting companies that claim an "algorithmic" or "autonomous" operating model — we provide the technical due diligence and architecture validation that traditional financial diligence doesn't cover. This is grounded directly in AMEF (Autonomous Micro-Enterprise Finance), which formalizes a five-point framework for exactly this.
-
01
Deterministic verification vs. stochastic drift
Are multi-agent tasks bounded by non-negotiable verification checks, or is "autonomous" doing more marketing work than engineering work?
-
02
Compute-to-revenue elasticity
Does gross margin hold up if transaction volume scales 10x, or does the cost structure quietly invert as usage grows?
-
03
API counterparty resilience & model portability
Can core execution switch model providers without a rebuild — or is the business one pricing change away from a margin collapse?
-
04
Protocol governance & human-in-the-loop fallbacks
Are high-stakes actions held in deterministic escrow pending human approval, or is oversight a policy document rather than a system property?
-
05
Empirical invariant auditing
Can the company produce an unbroken, programmatic audit trail — or is "we checked it" the extent of the evidence?
Engagements are scoped per deal — get in touch to discuss a specific target or portfolio review.
A six-stage production architecture, not a demo.
Every deployment we build runs the same request lifecycle: intake, agent reasoning, retrieval, model routing, output validation, and delivery — a finite-state machine gated by deterministic verification DAGs, where every state transition must pass an invariant check before it commits. Observed end to end, and packaged to ship as one repeatable unit per client.
| Stage | Primary tool | Purpose |
|---|---|---|
| 1. Intake | n8n | Receive, authenticate, validate, and classify the incoming request. |
| 2. Reasoning | LangGraph | Decide what the request needs and orchestrate the steps to get there, with full state control. |
| 3. Retrieval | pgvector | Fetch relevant context or memory, with source metadata attached for citation. |
| 4. Model gateway | LiteLLM | Route the completion to Gemini, Groq, or a self-hosted model — with automatic fallback. |
| 5. Validation | Guardrails AI | Check structure, factual consistency, and safety before anything is released. |
| 6. Delivery | n8n | Deliver the validated response back through the original channel. |
Cross-cutting: Langfuse traces cost, latency, and failure across every stage; the whole stack ships as one Docker/Kubernetes template per client. Every tool is open-source and self-hostable — deliberately, so data-residency requirements (including EU AI Act readiness) don't force a rebuild later.
Every state change is treated as adversarial until proven otherwise.
The six-stage architecture above has a dedicated security extension, formalized in AMES (Autonomous Micro-Enterprise Security), the security layer of the five-part operational core. It sits between reasoning and settlement — every proposed action must independently pass a security check, on top of the functional verification already described above, before it can commit.
Architectural diagram from the AMES working paper. The security layers (2, 4, 5) extend the same core stages already described above (1, 3, 6) — this is an architectural model, not a production benchmark.
We investigate new architectures for AI-native organizations and translate selected ideas into applied systems for information-intensive operations.
This is grounded in an independent research program — architecture, economics, governance, finance, security, and market strategy, plus an applied AdTech study. See the full research →