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 Operational Leverage 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.
| Principle | What it prevents | Specified in |
|---|---|---|
| Deterministic orchestration | Agents drifting off-task in open-ended loops, and unpredictable cost | AMEA |
| Verification-gated execution | Wrong, malformed or non-compliant actions reaching money, data or customers | AMEA · AMEG |
| Bounded self-correction | Endless retries, or a bad answer “fixed” into a worse one | AMEA |
| Human exception handling | Agents guessing their way through edge cases | AMEA · AMEG |
| Auditable execution | “Why did it do that?” with no answer | AMEG |
| Governance as architecture | Rules that exist only in a policy document | AMEG |
| Interoperable by default | Lock-in to one model or vendor, and tools used outside their scope | AMES · AMEF |
| Zero-trust boundaries | Prompt injection and stolen credentials: agents never hold payment or system keys, and every action passes independent security checks | AMES |
Every action an agent proposes is checked before it runs. Anything that fails is stopped and handed to a person; it is never guessed through.
Not just an architecture on paper.
We don't present everything with equal certainty — production work and research are different evidence levels, and we keep them labeled that way.
| Programmatic infrastructure | Production
OpenRTB-compliant supply- and demand-side integrations, header-bidding, and marketplace transaction logic for international DSP/SSP operators. |
| AdCP integration | Production
Agent-to-agent campaign discovery, negotiation, and activation — agentic commerce, not a slide deck. |
| Real-time fraud detection | Production
A production IVT plugin combining rule-based scoring with anomaly detection, fast enough to sit on the live bidding path. |
Limits we state openly, and how we handle them.
| Limit | How we handle it in engagements |
|---|---|
| Our performance figures are modeled, not yet measured in live client deployments. | Every engagement measures its own baseline and results before anything is scaled. |
| The safety bound assumes check failures are independent; correlated failures can weaken it. | Checks use different mechanisms (schema, rules, signatures), and repeated failures always go to a person. |
| Checks catch actions that break rules, not actions that follow the rules but miss the intent. | A named owner reviews exceptions and decides what agents are not allowed to decide. |
| Data quality: our research doesn’t yet cover training-data quality or bias. | Inputs are validated and traced to source before agents use them; data issues found in the audit are reported, not worked around. |
| Monitoring after go-live. | Error, escalation and cost rates are tracked, with re-validation whenever a model, prompt or vendor changes. |
| Independent validation. | Checks are reviewed by someone other than the person who built them before sign-off. |
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 Autonomous Programmatic Clearing paper benchmarks this approach directly against traditional ad-operations workflows — see Research for the results.
| Plugin | What it does | Controls that make it safe | For the business |
|---|---|---|---|
| AdOps Copilot | Plain-English investigation of ad server and exchange performance: what happened, what changed, why, and what to do next. Runs health checks for expiring campaigns, behind-pace delivery and unfilled zones. | Read-only access with query limits and logging. Never changes a campaign. Database credentials never reach the AI model. Role-based access. | Faster answers on fill rate, revenue and pacing, without waiting for an analyst. |
| MCP Database Agent | Ask the ad platform database in plain English. It finds the real schema, writes a read-only query and answers in plain language. | SELECT-only through a separate MCP server. Credentials never exposed to the model. Row limits, timeouts and hidden sensitive columns. Every query logged. | Self-service data for every team without SQL, with a low-risk read-only design. |
| RTB Intelligence Engine | Machine-learning bid shading for buyers and dynamic floor prices for sellers, running inside the bidder. | Local inference with no external call at bid time. Caps on how far prices move. Automatic fallback to existing logic. A/B rollout on a slice of traffic. | Lower cost per win on the buy side, and floors that track real inventory value on the sell side. |
| IVT AI | Real-time invalid-traffic scoring of every impression and click, with a Clean, Suspicious or Blocked verdict. | Rules decide; the machine-learning anomaly layer only adds signal. The optional AI explanation never changes the verdict. Tunable thresholds. Fails safe. | Stop paying for fraudulent traffic and keep advertisers confident in the numbers. |
| AI Banner Ad Generator | Finished banners from a plain-English brief, in 10 standard IAB sizes, with instant revisions. | Exact pixel sizes. Every banner is reviewed by the team before it goes live. | Campaign creative in seconds instead of days. |
The same patterns, typed contracts, human approval, validation loops and governed tool access through MCP, run across the systems built by our engineering team and delivery network. See Selected builds.
In focus: the MCP 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. |
Also built: Agent Access
An MCP server that lets AI agents work with the ad server safely: list campaigns, read reports, pause or resume campaigns, change budgets and create banners. It is read-only by default, each agent or person gets a role-based token, an approval step sits before any change goes live, and every action is logged, with undo for reversible actions. Agents can handle routine requests around the clock, while every change stays approved, logged and reversible.
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.
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.
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 →
Raja Mohammed Sheriff
Raja leads day-to-day business operations at Secular Labs, with a career spanning finance, HR, and independent e-commerce operations. His background includes senior finance and HR leadership roles across manufacturing and technology businesses, alongside hands-on experience running an independent D2C e-commerce operation end-to-end.
Raja is an alumnus of the Indian Institute of Management, Kozhikode. His operating experience — including running a physical-product e-commerce business end-to-end — directly informs how Secular Labs approaches workflow design and operational reality checks.
How Secular Labs operates
Secular Labs pairs its research architecture with hands-on AdTech infrastructure experience — the operating discipline behind the papers, not just the theory.
The technical capability spans agent orchestration and applied AI, production-grade ad-serving and real-time bidding infrastructure, and the verification logic that keeps automated decisions accountable — paired with dedicated infrastructure and deployment expertise, so what we build is demoable and production-ready, not a one-off prototype.
Alongside the engineering work, a separate operations capability manages research, partnerships, and the administrative backbone that lets the technical work stay focused — from grant relationships to the applied research program itself.
We're a deliberately lean organization by design — the same architecture we advise other businesses to adopt is the one we run ourselves.