TL;DR: We published a paper on the post-SaaS computing stack. The argument: as models synthesize behavior on demand, persistent multi-tenant applications lose ground to ephemeral software — and ephemeral software needs a substrate that holds accountability, not the artifact itself. Delegate is our working implementation of that substrate.
We have been building Delegate for the past year. The engineering notes on this site cover the routing layer, the token savings, the auth model. This post introduces something different: the full architectural argument, written as a paper, co-authored with Andrea Phillips, CTO of Delegate and co-founder of the lab.
Beyond SaaS: Delegate and the Substrate Layer for Runtime-Synthesized Applications is now available on the site. Daniel Phillips and Andrea Phillips, Controlled Mayhem, May 2026.
The core claim
SaaS assumed the cheapest way to give a user a capability was to pre-author it, sell access, and let the user invoke it through an interface. Contemporary language models invert that assumption for an expanding class of use cases. The user describes what they need. The model synthesizes the behavior on demand. The persistent product is no longer a necessary intermediate artifact.
We call the resulting class of computation ephemeral software. It has four structural properties:
- Not retained. Logic is regenerated when the need recurs, often in a form adapted to the recurrence.
- No front door. No website, no sign-up, no settings page. The model is the interface.
- Composed, not selected. Capability comes from the union of available primitives, not a vendor's feature menu.
- Accountability lives outside the artifact. The application does not persist long enough to carry credentials, scopes, or audit logs. The substrate must.
That last property is the paper's central concern.
What the paper contributes
Three things, stated plainly:
- Structural requirements for a primitive substrate — derived from the properties of ephemeral software and the asymmetries between human-driven and model-driven authorization.
- A three-part taxonomy of substrate primitives: mediated (principal holds the upstream account), first-party (substrate holds the account), and native (substrate-owned). The evolution from technical to non-technical principals maps to a shift toward first-party composition.
- Delegate as a worked example — seven meta-tools over a single Streamable HTTP endpoint, scoped permissions, encrypted credential storage, tenant-isolated audit logging, and per-key service visibility.
The meta-tool argument in one paragraph
The dominant MCP pattern loads every tool schema into context at session start. At scale, that cost scales linearly with enabled integrations — and can exceed the working context window of frontier models entirely. Delegate's meta-tool surface registers a fixed schema cost (~1,050 tokens) regardless of catalog size. The paper walks through several baselines — full-catalog upper bounds, realistic ten-service working sets, smaller five-service working sets — and declines to report a single headline percentage, because the figure depends entirely on what the per-tool author would otherwise have enabled. The architectural claim is what holds across all of them: any non-trivial per-tool baseline exceeds the meta-tool surface by at least an order of magnitude, and the gap widens as the catalog grows.
What we explicitly do not claim
The paper states its limits clearly:
- Delegate is not the only viable substrate design.
- The schema-size calculation is structural, not a behavioral production measurement — a production appendix is deferred until the user base supports it.
- Not all SaaS will be displaced. Deep persistent state, network effects, and curated experiences persist.
- Self-hosted deployment and first-party primitives are on the roadmap, not shipped.
We think intellectual honesty about what is proven versus what is argued makes the paper more useful, not less.
How to read it
The paper runs 20 pages. If you have five minutes, read the abstract and Section 11 (Conclusion). If you have twenty, read Sections 3–5 for the requirements derivation and architecture. If you are evaluating whether to build on Delegate or a similar substrate, Sections 6–8 cover the meta-tool layer, accountability model, and multi-tenancy.
The takeaway
MCP solved discovery. It did not solve scale, accountability, or the structural mismatch between OAuth's scope model and model-driven authorization. The per-service tool pattern dominant in the public MCP ecosystem does not satisfy the requirements of ephemeral software. Something has to sit between the model and the world's APIs — holding credentials, enforcing scopes, writing the audit trail. That layer is load-bearing infrastructure for the post-SaaS era. Delegate is our attempt to build it well enough to be trusted with it.
If you are running a multi-server MCP stack, building agent infrastructure, or thinking about what comes after SaaS for your category, we would be interested in talking.