Short, plain-language notes drawn from the five working papers behind our advisory practice — Autonomous Micro-Enterprise Architectures (AMEA), Autonomous Micro-Enterprise Economics (AMEE), a third paper applying the framework specifically to programmatic AdTech clearing, a fourth on governance (AMEG), and a fifth on finance and valuation (AMEF). Full papers are available on request.
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, including Midjourney and Medvi, have drawn attention precisely because their publicly reported revenue-per-employee figures run far ahead of a similarly sized traditional business — cited here as industry data points, not as Secular Labs clients. 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.
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.
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. Our fourth paper 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.
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. Our fifth paper proposes a replacement: a ratio measuring new recurring revenue against what it actually costs to run the business — compute, verification overhead, and a small core team — instead of headcount.
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.