Research

Secular Labs Research

An independent research program examining how AI-native systems change organizational architecture, transaction costs, governance, security, capital efficiency, firm valuation, and how the resulting firm actually reaches a market.

Secular Labs Research — seven research papers spanning architecture, economics, governance, finance, security, market interface, and applied AdTech — built on the AMEI framework
A note on the name

"Secular" is an economics term before anything else. A secular trend describes a long-run, structural shift — as distinct from a short-term or cyclical one (the same root behind "secular stagnation," the well-known framing for long-run economic slowdown). That's the sense intended here: research and advisory work aimed at durable, structural change in how businesses are organized — not a trend to ride, but a shift to build for.

Founder & research lead

Ram Kumar Rajagopal

Ram founded Secular Labs. His background is in building and directing AdTech infrastructure — platform strategy, marketplace mechanics, and delivery for international media networks — hands-on operating experience that now shapes how we think about automated coordination at Secular Labs. He holds an MSc in Software Engineering from Bharathiar University, Coimbatore, is an alumnus of IIT Bombay, and holds a dual MBA from Washington University in St. Louis and IIT Bombay.

Alongside that, Ram researches the economics and systems architecture of AI-driven organizational automation — published as the AMEA and AMEE working papers, with further work submitted toward peer-reviewed and conference venues including SSRN, IEEE, and NBER-affiliated tracks. That research is what Secular Labs is built to apply commercially. Ram also works as an angel investor and advisor, having backed seed-stage companies across AgriTech, FinTech, SaaS, and deep tech since 2022, and advises founders on technical architecture and product due diligence for high-concurrency, AI-native systems.

Research independence

Secular Labs supports an independent research program investigating autonomous organizational systems. Some concepts developed through the research program inform commercial advisory and implementation engagements. Research papers disclose relevant commercial relationships and distinguish theoretical contributions from commercial applications.

The core research program

Five formal pillars, one operational core.

The five pillars of the AMEI operational core: AMEA Architecture, AMEE Economics, AMEG Governance, AMEF Finance, AMES Security
01AMEA — Architecture

How do autonomous agents execute complex organizational workflows? Zenodo → · Plain-language page →

02AMEE — Economics

What happens to transaction costs and firm boundaries when coordination becomes algorithmic? SSRN → · Plain-language page →

03AMEG — Governance

How can autonomous execution remain bounded, auditable, and accountable? Zenodo → · Plain-language page →

04AMEF — Finance

How should capital allocation, valuation, and investment change when organizational coordination becomes algorithmic — including the cost of the security layer above? Zenodo → · Plain-language page →

05AMES — Security

How does autonomous execution remain safe under adversarial pressure? AMES formalizes zero-trust state transitions, independent boundary verification, cryptographic attestation, and bounded adversarial escalation between reasoning and settlement. Zenodo → · Plain-language page →

06AMEI — Market Interface Layer

Below: the layer that contains all five.

Not a sixth pillar. AMEI is the composition layer that contains all five — the market-facing interface that wraps around the operational core. Read the five pillars as the operating system; read AMEI as the interface through which that system reaches customers, partners, regulators, and markets.

Zenodo → · Plain-language page →

AME Research Framework on GitHub

A public repository that organizes the six AME components (AMEA, AMEE, AMEG, AMEF, AMES and AMEI), links each one to its canonical publication on Zenodo or SSRN, and provides supporting architecture diagrams. The published papers remain the reference to cite; the repository is a companion for researchers, developers and universities.

See where the architecture is applied: Applied systems →

The market interface layer

AMEI — not a sixth pillar, the layer that contains them.

The five pillars — AMEA, AMEE, AMEG, AMEF and AMES — are the operational core. AMEI is not a sixth pillar sitting alongside them; it is the composition layer that contains all five. Read the five pillars as the operating system; read AMEI as the market-facing interface wrapped around it.

A companion working paper argues that the five pillars above form a formally verified operational core — but a core alone does nothing without a way to reach customers, partners, regulators, and competitors. AMEI (Autonomous Micro-Enterprise Interface) is that membrane: it doesn't sit beside AMEA/AMEE/AMEG/AMES/AMEF as a peer, it wraps around all five. Zenodo →

Diagram showing the AMEI Market Interface Layer as an outer ring — Demand Discovery, Conversion, Retention, Partnership and Channel, Brand and Positioning, and Feedback Loop — containing the formal operational core of AMEA, AMEE, AMEG, AMEF, and AMES

The operational core is formal and bounded-risk; AMEI is a practice-led companion framework that wraps around it rather than forming a sixth formal pillar.

AMEI names six practice-led sub-layers: Demand Discovery, Conversion, Retention, Partnership & Channel, Brand & Positioning, and Feedback Loop. The paper's central argument is a practical one — once internal coordination cost collapses toward zero, the market interface becomes the new binding constraint on growth, not the technology itself. The interface layer therefore matters as much as the operational core.

Applied research

Autonomous Programmatic Clearing

An application of the framework to programmatic advertising — verification DAGs, IAB standards compliance, and algorithmic clearing, benchmarked on a 100,000-transaction synthetic workload built on standard OpenRTB bid formats.

From research to real-world impact — the Autonomous Programmatic Clearing paper benchmarks the approach our production plugins implement
Market patterns

The coordination tax is being productised

Across publisher ad ops, AR collections, logistics claims, underwriting and returns, the same structural pattern is showing up. Small teams are scaling output without matching headcount by rebuilding the coordination layer of the business — not by adding people to it.

The pattern

Every recurring operational workflow has three layers:

01Coordination

Information moves between people and systems. Someone prepares, routes, checks and commits work.

02Decision

A rule or a judgment is applied.

03Verification

The result is confirmed, reconciled, or escalated.

For most businesses, the first and third layers consume the majority of operational headcount — not because the work is complicated, but because coordination is manual and verification is done by people reading outputs. As volume grows, headcount grows proportionally. That's the coordination tax.

A pattern is emerging across industries: teams that productise the coordination and verification layers — with rules, integrations, and narrowly scoped AI — grow capacity without growing headcount the same way. They don't replace their people. They change what their people do.

The examples below are publicly documented market patterns. They are not our clients and we are not endorsing them. They illustrate the same structural move we diagnose.

How to read the framework tags

Each pattern below is tagged with the AMEA pillar it exercises most heavily. AMEA is the five-pillar operational core we use to structure operational analysis:

  • AMEA — Architecture / Runtime

  • AMEE — Economics / Model

  • AMEG — Governance / Controls

  • AMEF — Finance / Capital

  • AMES — Security / Trust

Most real workflows touch all five. The tags indicate where the pattern's leverage is concentrated, not where it stops.

AdTech / publisher ops

A publisher-monetisation startup

Tag: AMEA (Architecture / Runtime)

Unified monetisation stack, moved from services to SaaS. Publicly reported at roughly $5M ARR in about 18 months, with a founder and three engineers. The coordination tax in publisher ops — campaign setup, yield decisions, reconciliation — productised rather than staffed.

A sell-side ad ops startup

Tag: AMEA (Architecture / Runtime)

Agentic trafficking, yield and floor management. Founded around 2023, with a publicly reported ~$5.8M Series A and a small team running millions of automated actions. Eliminating swivel-chair work is the operating principle.

An agentic performance-marketing agency

Tag: AMEE (Economics / Model)

Agency run as an agentic operator across major ad platforms. Founded in 2023, with a publicly reported ~$7M of contracted ARR in its first year and about 15 people. Agency output without agency headcount.

Finance / AR / P2P

An accounts-receivable automation company

Tag: AMEE (Economics / Model) · AMEG (Governance / Controls)

Agents for invoice Q&A, collections and escalation across fragmented finance data. Its customers publicly report a ~34% reduction in days-sales-outstanding within weeks. AR is fragmented data plus a long exception tail.

An order-to-cash AI startup

Tag: AMEA (Architecture / Runtime)

AR agent for billing, cash application and collections. The same order-to-cash workflow problem, approached as reconnection rather than replacement.

A procure-to-pay and order-to-cash copilot vendor

Tag: AMEA (Architecture / Runtime) · AMEE (Economics / Model)

Agentic copilots for P2P and OTC, with publicly listed enterprise customers. Where headcount hides in most established businesses.

Logistics / insurance / regulated ops

A logistics claims-recovery startup

Tag: AMEG (Governance / Controls)

Agents to recover claims, billing errors and credits. Claims recovery is a pure verification burden — every claim has to be checked, and most are lost to process friction rather than merit.

An insurance underwriting AI company

Tag: AMEG (Governance / Controls) · AMES (Security / Trust)

Agents for underwriting, fraud and compliance in a regulated environment. Verification-heavy, high-stakes. Autonomy works when the residual risk is bounded and the verification architecture is explicit.

E-commerce / post-purchase

A creator and partnership operations platform

Tag: AMEA (Architecture / Runtime)

Agents that book, track and pay influencers. Partnership operations was a spreadsheet army three years ago; now it's a routing layer with humans on the exceptions.

Returns and post-purchase operations (pattern, D2C / marketplace)

Tag: AMEG (Governance / Controls) · AMEE (Economics / Model)

Returns, exchanges and fraud logic are being moved to agentic workflows across D2C and marketplace operators. High-exception, high-verification, structurally similar to AR and claims.

The same architecture, different surface

Look across these examples and the shape repeats:

01Coordination

Information moves between systems. Agents prepare and route; people retain what requires judgment.

02Decisions

Rules and integrations handle deterministic steps. AI handles classification, preparation and interpretation.

03Verification

Controls, reconciliation and audit trails stay explicit. The verification architecture is what makes autonomy safe.

04Economics

Capacity recovers without proportional headcount. That's the leverage.

The vertical changes. The pattern doesn't.

Where Secular Labs fits

We don't build another vertical AI tool. We diagnose where coordination still sits in your workflow, redesign the architecture so leverage is measurable and verifiable, and hand you a plan you can execute.

That's the same discipline these teams have applied internally — applied to your operations, on evidence, with verification built in.

The diagnostic identifies where coordination and verification still consume headcount in one recurring workflow. It's directional — it tells you where to look. If it finds a credible opportunity, the Operational Audit measures it and quantifies what the redesign would actually recover.

Notes on this list

We have no client relationship with any company named on this page. These are publicly documented patterns, included because they illustrate a structural shift in operational design. None of the patterns above is a Secular Labs implementation, case study, or endorsement.

Traction and funding figures are public and recent as of late 2025 / early 2026. They are included as context, not as competitive analysis, and we make no representation as to their accuracy beyond what was publicly reported.

The list will grow. AdTech, finance ops, logistics, insurance, e-commerce. As we collect more, the pattern will stay the same.

Before the acronyms — the idea in one analogy

Economists compare countries using GDP per capita, not just total GDP, because total output means little until you divide by the number of people producing it. The same logic applies to a company: revenue alone doesn't tell you how efficient it is — revenue per employee does. A small number of AI-native companies, some with teams of only a few dozen people, have drawn attention precisely because their publicly reported revenue-per-employee figures run far ahead of a similarly sized traditional business. They are cited here as public market examples, not as Secular Labs clients, partners or endorsements. AMEA is our research on how a company gets architected to do that; AMEE is the economic reasoning for why it's worth doing.

Get the AMEA excerpt

Leave your email and we'll send you the first section of the AMEA working paper directly.

We use your email only to send the paper. See our privacy notice.

Notes

Plain-language notes from the research.

Short explainers: The coordination tax · The verification premium · Agent orchestration vs RPA · Verifying AI agent decisions · Revenue per employee

Plain-language notes from the seven papers — key ideas in simple terms for builders, operators and investors
From the AMEA working paper

Why headcount stopped being the constraint

The classical theory of the firm treats internal coordination cost as the reason businesses stay small, or stay bureaucratic as they grow. Multi-agent orchestration changes that calculation: when a graph of agents can hand off work deterministically, with state that survives interruption, the coordination-cost curve that used to force a choice between "small and nimble" or "large and slow" mostly disappears. That's what lets a handful of people run a business that behaves, operationally, like one many times its size.

Coordination cost as a business grows Small team Large team Classical model AMEA-orchestrated

Conceptual illustration, not empirical data — the underlying claim is argued in the AMEA paper, not measured here.

From the AMEE working paper

The verification premium

Removing humans from a workflow doesn't remove risk — it changes its shape. Under classical transaction-cost economics, monitoring an employee's judgment is an open-ended, ongoing cost. Under algorithmic contracting, that same risk can be converted into a fixed, computable premium: a defined verification layer, checked at a known cost, with a bounded worst case. That reframing is the economic argument for why a governance and verification layer isn't overhead — it's what makes the rest of the automation defensible.

From the research program

What ultra-lean AI-native firms have in common

A small but growing set of two-to-ten person teams are reaching revenue-per-employee figures that would have been implausible for a company that size a few years ago. What they share isn't a single tool — it's an architecture: a clear separation between reasoning, retrieval, model access, and validation, so that adding capability doesn't mean adding organizational complexity. That pattern, more than any individual product, is what we look for when we assess whether a business is ready to restructure around it.

From the AdTech-specific working paper

What a verification layer is actually worth, measured

Our third paper takes the AMEA framework and applies it specifically to programmatic advertising — OpenRTB bid streams, IAB SupplyChain and consent-string compliance, and the sub-100ms timeout windows that real-time bidding runs under. Rather than argue the case abstractly, it benchmarks one: a simulated clearing workload of 100,000 concurrent bid transactions, comparing a traditional human-triaged setup against an AMEA-style verification pipeline. The gap was large — order-of-magnitude improvements in throughput and tail latency, and marginal labor cost collapsing toward zero as compute took over the checks a person used to do manually. It's a benchmark, not a live production claim, but it's the clearest evidence yet for why a verification layer belongs in the architecture from day one rather than being bolted on afterward.

From the AMEG working paper

Governance isn't a document — it's an architectural property

Most companies treat "AI governance" as a policy written after the system is already live: a document explaining what the system is supposed to do, reviewed periodically, largely disconnected from what the system actually does. The AMEG framework argues that's backwards. Every agent decision is checked against an explicit set of rules — what's required, what's allowed, what's forbidden — before it's allowed to go through, and the outcome is written into a tamper-evident, cryptographically linked record rather than a pile of unstructured chat logs someone has to comb through after an incident. If a decision can't be verified in time, the system is designed to stop and escalate to a human rather than guess. That combination is what turns governance from a document into a property of the system itself.

This also isn't AdTech-specific — the same verification approach has been tested against financial-transaction scenarios (attempted sanctions evasion, unauthorized discounting, unlogged actions) designed specifically to probe whether the layer would catch them before they reached settlement. And it's what makes the architecture portable across regulatory regimes: the underlying verification logic is the same whether the local rules come from the EU AI Act, the US NIST AI RMF, or a framework that doesn't exist yet — only the specific rules being checked change, not the checking mechanism.

The EU AI Act asks high-risk AI systems to prove control, not just describe it. Our governance research maps each core obligation to something the system enforces while it runs.

EU AI ActUsual approachHow our architecture handles it
Art. 9 Risk managementPeriodic risk spreadsheetsRules checked before every action, continuously
Art. 11 Technical documentationManuals updated now and thenVersioned architecture tied to every build
Art. 12 Record-keepingUnstructured chat logsTamper-evident record of every state change, tool call and check
Art. 14 Human oversightReviews after something goes wrongAutomatic hand-off to a person when checks keep failing
Art. 15 Accuracy, robustness, cybersecurityPeriodic scansAgents hold no payment or system keys, and independent security checks run on every action

This shows how the architecture supports these obligations. Whether a specific system is high-risk, and how it complies, is assessed for each engagement.

On the economics of AI adoption

Tokens can become the new headcount problem — if you let them

There's a fair skepticism building around AI economics right now: that businesses are quietly trading a labor line item for a token line item, and that the second one can grow just as unpredictably as the first — arguably worse, since usage-based pricing means cost scales with volume in a way a fixed salary doesn't. It's a reasonable worry, and it's part of why some of the loudest AI enthusiasm is starting to meet real doubt about whether the economics actually hold up.

Our answer isn't to argue the worry away — it's to design against it. Every architecture we build treats a model call as the expensive resource it is: deterministic rules and lightweight models handle whatever they're capable of handling, and a large language model is only invoked where nothing cheaper will do — often only for the last step of explaining a decision that's already been made by rule-based logic, not for making the decision itself. Retrieval keeps prompts small. Guardrails prevent the silent re-ask loops that quietly multiply token spend. And every call is logged with its actual cost, so nobody discovers the real number for the first time on an invoice. Done properly, compute becomes a small, monitored, fixed-ish cost — not a second uncontrolled headcount line hiding inside the same P&L.

From the AMEF working paper

Why "revenue per employee" is the wrong metric for lean AI firms

Investors evaluating a traditional software company lean on two familiar numbers: burn multiple and revenue per employee. Neither holds up well for a genuinely lean, verification-gated firm — a team of four processing meaningful recurring revenue makes revenue-per-employee a statistical outlier rather than a useful signal, and burn multiple assumes most cash goes to payroll rather than compute and verification infrastructure. The AMEF framework proposes a complementary metric — a ratio measuring new recurring revenue against what it actually costs to run the business: compute, verification overhead, and a small core team — alongside, not in place of, conventional measures.

It also makes a valuation argument worth understanding even if you're not an investor: when a failure mode is inspectable — a verification log, not an opaque management judgment call — the risk premium a rational investor demands should compress accordingly. The paper's worked examples are explicitly stylized illustrations, not empirical claims about any specific company. But the underlying argument — that lean, verification-gated firms deserve different underwriting tools than headcount-scaled ones — is the same thesis running through all five papers, just applied to how capital gets priced.

Research & academic collaboration

Interested in collaborating on autonomous AI systems, AI-native organizations, or their economics and governance?

Work with us as a research collaborator, or join our team as a PhD scholar or post-doctoral researcher.