Whitepaper
Software development is moving toward autonomous agent workflows at a rapid pace. Coding agents handle bugs, build features, and ship pull requests with minimal human involvement. The infrastructure layer has not kept pace with this shift.
Today, these agents operate inside sandboxes: isolated containers that can execute code and, in some cases, run services locally within the same environment. But everything is co-located, resource-constrained, and tied to the sandbox lifecycle. A Postgres process running inside a sandbox does not behave like a managed database in production. The performance characteristics are different. The connection handling is different. The failure modes are different. Code that passes tests against a co-located sandbox database can break in production against a real managed instance. A sandbox is a development shortcut, not a production-representative environment.
When a task requires production-grade services, properly isolated and independently managed, the agent has two options: wait for manual provisioning, or attempt to do it through raw cloud APIs. Both are slow and defeat the purpose of autonomous workflows.
Ephemra is the infrastructure layer for this shift. One API call. The caller describes the topology they need: a runtime, a database, a cache, any combination. Ephemra provisions real, managed cloud services, wires them together, injects credentials, and returns a ready environment. The resulting topology is shared by default. An orchestrator and every agent it spawns connect to the same environment without additional provisioning. Services can be added as the workload evolves, removed individually, or torn down all at once. No cloud credentials. No provisioning scripts. No cleanup.
The product is caller-agnostic by design. AI agents are the sharpest current example of why ephemeral, connected infrastructure is needed, but the same API serves developers, CI pipelines, data teams, and platform builders. Anyone who needs a working environment for a defined period of time, and who does not want to operate the underlying infrastructure themselves, is the audience. AI is where the alignment is tightest today, and where the urgency is highest. Ephemra grows alongside that capability, providing the operational layer that sandboxes were never designed to offer.
This whitepaper describes the v1 product specification. Core components of the Topology Manager and runtime provisioning are operational today, with the broader service catalog and managed service support under active development. Current implementation status, working demos, and roadmap detail are available on request.
The gap between what software workloads need and what existing infrastructure options provide is growing wider. Four categories of tools serve developers and agents today, and each leaves part of the problem unsolved.
Sandboxes provide isolated code execution, but stop at the container boundary. Sandbox providers give you a container through an API call. The container runs code, and that problem is solved well. Sandboxes can run services like Postgres or Redis inside the same container, but these are co-located processes sharing the same resources, not independently managed services. They do not behave like a staging or production infrastructure. The moment a workload needs properly isolated services with independent lifecycles, real connection handling, and production-representative behavior, the sandbox model cannot provide it.
Persistent infrastructure providers serve a different lifecycle. Managed database and backend platforms are designed for long-lived applications. You sign up, configure a project, and manage it over months or years. The mental model is ownership and continuity. These products answer "I need a backend for my application." They do not answer "I need a backend for the next 30 minutes."
Cloud providers offer all the primitives, but none of the assembly. AWS, GCP, and Azure give you everything you need to build a connected environment. You can spin up a compute task, a database instance, wire them together with security groups and VPC configuration, and tear it all down when you are done. You will also spend hours doing it. The primitives exist. The single-call, ready-to-use assembly does not.
Infrastructure-as-code tools automate provisioning, but are designed for humans planning ahead. Terraform and its equivalents let you describe infrastructure declaratively and apply it. The workflow assumes a person is designing a system, running a plan, reviewing a diff, and committing state. It is not designed for runtime provisioning, where the caller needs an environment in the next few seconds and will discard it when the task is done. The plan-and-apply model is correct for long-lived infrastructure; it is the wrong shape entirely for ephemeral workloads.
This gap manifests across many caller types, but four specific pressures define it most clearly. Each is universal to anyone running ephemeral workloads, and each is sharpest in AI coding agent use cases.
First, services without wiring are not infrastructure. Provisioning a database is one step; connecting it to a runtime is another. Security groups, IAM policies, network configuration, credential injection, service discovery: the work of making services usable from each other is its own discipline, and it is the part nobody automates at runtime. A caller who wants a Python runtime that can talk to Postgres has to do that wiring themselves, every time, or maintain templates that go stale. The bottleneck is not whether services exist; it is whether they are connected and ready to use the moment they are provisioned.
Second, no real services. Sandboxes give you a container, not an environment. The moment a workload needs to interact with a real database, use a cache, or work with multiple services that talk to each other, the caller has to wire it up manually. Most real-world software interacts with Postgres, Redis, message queues, object storage, and other APIs. Anyone testing or building that software needs those services available, pre-configured, networked, and disposable when the task is done.
Third, the lifecycle mismatch. Ephemeral workloads are bursty. An agent runs for 20 minutes, finishes its task, and the environment sits idle. A staging environment for a weekly demo sits idle six days a week. A test environment for a CI run is needed for ten minutes and then nothing. But the infrastructure options are binary: always-on servers paying 24/7 for something used a few hours a day, or throwaway sandboxes with no persistence between sessions. There is nothing in between.
Fourth, orchestrators are stuck on one machine. Agent orchestrators can only run agents in the environment they already have access to. Spinning up fresh, isolated environments per task is not something orchestrators can do today without significant do-it-yourself infrastructure work. The same shape of problem affects any system that wants to dispatch work to fresh environments programmatically: CI runners, parallelized test suites, multi-tenant platforms.
An ephemeral topology is a connected set of real cloud services, provisioned as a unit, with independent lifecycles, delivered through a unified API.
The mental model is similar to infrastructure-as-code: describe what you need, and the system provisions it. But where IaC state is a static snapshot you manage, Ephemra's state is dynamic. The Topology Manager tracks the live environment continuously as services are added, swapped, or removed.
A simple example: a Python runtime, a Postgres database, and an object storage bucket, already wired together. A more elaborate one: a Node runtime, a Postgres, a Redis cache, a message queue, and a vector database, all provisioned as a single topology. The shape varies; the model is the same. The caller interacts with every service through the same API. Networking, credentials, and service discovery are handled in the background.
The question the product answers is not "where does my application live," but "what does this task need for the next 30 minutes." The key properties:
Unified API. One endpoint. The caller describes the topology. Ephemra provisions all of it. There is no second step.
Real services. Postgres is a real managed database. Redis is a real cache. These are not emulators. Workloads that depend on actual service behavior run correctly.
Pre-wired. The same API call that provisions services also connects them. All service wiring, credential injection, and discovery happen behind the scenes. The caller targets any service in the topology through the same API that created it.
Independent lifecycles. Tear down the runtime but keep the database. Add a message queue mid-session. Swap a Python runtime for Node against the same Postgres. Add object storage when an analysis run produces artifacts that need to persist. The topology adapts to the work.
Caller-agnostic. The API does not change based on who is calling. AI agents, CI pipelines, developers, platform builders. Same interface, same experience. The product was not built for AI and adapted for everyone else; it was built for anyone who needs ephemeral connected infrastructure, with the AI use case as the most acute example.
The service catalog spans the full backend stack. Runtimes (Python, Node, Go, custom containers). Managed databases (Postgres, MySQL, and document stores as the catalog grows). Caches (Redis, Valkey, Memcached). Object storage (S3-compatible buckets). Message queues (Kafka, SQS-equivalents, pub/sub primitives). Search indexes, vector databases, and other specialized services follow the same model: requested through the same API, wired in automatically, billed per-second, and torn down independently.
All interaction goes through a unified API backed by a single persistent service: the Topology Manager. One endpoint handles everything. The caller never interacts with the underlying cloud provider.
The Topology Manager receives a request, provisions the services, wires them together, and returns a live topology. From there, the caller can execute commands in the runtime, add services, remove what is no longer needed, or tear everything down. Routing, state, and lifecycle management happen behind the scenes.
A topology is not bound to a single caller. Once provisioned, any agent or process with the topology's connection details can access it. An orchestrator requests a topology once, and every agent it spawns inherits access to the same environment: the same database, the same cache, the same runtime. Agents working on different parts of the same task operate against shared infrastructure without any additional provisioning. A developer can pick up where an agent left off. The topology is a shared workspace, not a locked session.
Provisioning is a function of what is requested. Runtime-only topologies, drawn from a warm capacity pool, are available in seconds. Topologies that include managed services — a Postgres database, a Redis cache — take longer because real managed services genuinely take time to provision properly. A standard topology with runtime, database, and cache is typically ready within one to three minutes. Custom Dockerfiles are built once and cached; first builds take minutes, every subsequent topology using that image is instant. Re-using an existing topology is sub-second.
The relevant comparison is not how fast a sandbox starts. It is how long a developer or platform team would spend provisioning the same set of services manually: hours of Terraform, IAM configuration, security group rules, network setup, and credential management. Ephemra compresses that into a single API call.
Credential injection is transparent. The caller registers secrets once through a dashboard or API, and each topology request references them by name. At runtime, the Topology Manager resolves, decrypts, and injects the actual values into the environment. The caller's code references environment variables. The infrastructure handles resolution.
Secrets never appear in API requests, topology definitions, or logs. Agents and code running inside a topology operate with environment variable references, never raw credentials. The separation is architectural: the caller defines what secrets a topology needs, and the Topology Manager handles how they are delivered.
Images come in three tiers, each adding a layer of opinion on top of the last.
Base images are general-purpose development environments. They include common language runtimes (Python, Node, Go), git, and standard build tools. They work out of the box for most tasks without additional setup.
Profile images are specialized for specific workloads. A data-science profile extends the base with pandas, numpy, and common analytical libraries. A web-dev profile includes frontend tooling and testing frameworks. Profiles are opinionated shortcuts that eliminate setup time for known workflows.
Custom images are built from the caller's own Dockerfile. The Topology Manager builds the image once, caches it, and makes it instantly available for every topology after that. Teams with specific tooling, dependencies, or configurations set up their image once. Custom images can also replicate an existing sandbox-like setup while retaining access to the full topology model: real databases, caches, and independent service lifecycles.
Not every workload needs a persistent session. The Topology Manager also supports fire-and-forget execution: send a script, specify the topology it needs, get the result back. The topology is created, the script runs, the output is returned, and everything is torn down in a single request. Both modes use the same underlying infrastructure. The difference is lifecycle.
Every service in a topology is tracked individually — start time, stop time, resource allocation. Billing is per-second, per-service. A runtime that runs for three minutes and a database that runs for twenty are billed for exactly that. Billing is transparent: no rounding, no hidden fees, and no idle charges on services that have been torn down.
Teardown is either full or selective. Destroy the entire topology in one call, or remove individual services while keeping others alive. When a topology is destroyed, the Topology Manager returns a usage summary covering every service that ran, how long it ran, and what it cost.
Callers have full visibility into their usage. A real-time dashboard shows active topologies, running services, and accumulated costs. Spending caps can be configured to automatically stop or pause topologies when a budget threshold is reached, preventing unexpected charges.
Topologies are fully isolated from each other. Each topology runs in its own network environment. Services within a topology communicate over a private network not shared with any other topology or customer.
The Topology Manager is the only component that communicates with the underlying cloud provider. Callers never receive cloud-level credentials. All provisioning, teardown, and resource management is handled by the Topology Manager on the caller's behalf.
Secrets are stored in a dedicated secrets store and resolved at injection time. They are never persisted in topology state, never logged, and never exposed through the API. The Topology Manager performs the injection and moves on.
The architecture was designed from day one with audit trails, network isolation, and credential separation as primitives. Every topology has a clear ownership boundary, every action is logged, every secret is scoped. SOC 2 Type I is the first formal certification on the roadmap, targeted within twelve months of general availability. ISO 27001 follows. Regional data residency frameworks, including GDPR-aligned EU-only deployment, are supported architecturally and will be formalized as customer demand drives prioritization.
Infrastructure decisions are complex, and most callers should not have to make them. Ephemra is built to make most of those decisions disappear, while keeping the controls available for anyone who needs them.
The API serves two types of callers. The first says "I need Postgres" and does not care what runs underneath. They want a database, connected and ready, and the implementation is not their concern. The Topology Manager selects the right backing service based on configuration: workload profile, region availability, and performance requirements. The caller gets a working database. The platform makes the infrastructure decisions.
The second says "I need AWS RDS in ap-southeast-1 with 4 vCPUs." They have compliance requirements, latency constraints, or architectural opinions, and they want to express them. The same API accepts these preferences. When specified, the Topology Manager respects them. When omitted, it makes the best choice available.
This principle applies across the stack. Compute, databases, caches, object storage, message queues, and other service types each support multiple provisioning backends. The Topology Manager routes to the right one based on what the caller specifies, or what the platform determines is best when nothing is specified. The caller sees a consistent interface regardless of what runs underneath.
The decisions in question are not trivial. Which instance type to use, which region offers the best latency for short-lived workloads, which managed service handles ephemeral connection patterns well. These are decisions the platform makes by default so the caller does not have to. But they are decisions the caller can override when their requirements demand it. The API stays simple. The infrastructure behind it is not.
As new provisioning backends are added, as capacity planning matures, and as usage patterns inform better defaults, every topology benefits. The caller's experience gets faster and more cost-efficient over time without them changing anything.
To show how the product works end-to-end, here is a single bug flowing through the entire lifecycle.
A bug is reported. A user files an issue: data exports are silently dropping rows when a column contains null values.
The orchestrator picks it up. The orchestrator assigns the bug to a coding agent. It calls the Ephemra API: create a topology with the team's custom image and these secrets. A topology with a Python runtime, language tools, and git is available in seconds. The orchestrator receives the "ready to go".
The orchestrator connects and starts the agent. The orchestrator connects to the topology and launches the coding agent with the task prompt. The topology is now accessible to the agent and any other agent the orchestrator spawns during this task. The agent takes over from here: clones the repo, checks out the branch, and starts reading the issue.
The agent builds up what it needs. The agent looks at the code and sees the export logic queries Postgres and uses a Redis cache for intermediate results. It cannot reproduce or test the bug without those services. So it requests them. Postgres and Redis are added to the topology through the same API, with connection details injected as environment variables once provisioning completes a minute or two later. The agent did not need to know upfront what the task required. It discovered the dependencies as it worked, and the topology adapted.
The agent develops the fix. With real services running, the agent reproduces the bug: it loads test data with null values, runs the export, and confirms rows are being dropped. It traces the issue to a query that filters out nulls. It writes the fix. It runs the export again against the same Postgres with the same test data. All rows present. Unit tests pass.
A production-like topology is spun up. The agent wants more confidence. It requests a separate topology: Python, Postgres, and Redis, configured to match the production stack. A larger test dataset is loaded, including edge cases beyond just nulls. The agent runs the full export pipeline end-to-end against real services. All rows present, nulls handled correctly, performance within acceptable bounds. Integration tests pass.
The test topology is torn down. The production-like environment served its purpose. It is destroyed. No cleanup, no lingering resources, no cost accumulating while someone reviews the PR.
The fix is committed and pushed. The agent commits the fix, pushes the branch, and opens a PR. The orchestrator tears down the remaining topology. The developer gets notified: branch name, commit SHA, test results, pass/fail. They review, approve, merge. Done.
This single workflow touched four product capabilities. On-demand service provisioning: the agent started with a runtime and added Postgres and Redis as it discovered it needed them. Development against real services: the bug was reproduced and fixed against real Postgres and Redis, not mocks. Production-like verification: a separate environment mirroring the production stack was spun up on demand. Independent lifecycles: the development and test environments were created and destroyed independently based on what the workflow needed at each stage.
A sandbox could run the fix. But it could not spin up Postgres and Redis when the agent realized it needed them, load test data, run the full export pipeline, then spin up a separate production-like environment for final verification. That is what topologies do. The same agent, working on a different bug, might have requested object storage for file processing, a message queue for event-driven testing, or a vector database for retrieval-augmented generation tasks. The topology adapts to the work, not the other way around.
The AI agent workflow is the clearest demonstration of the product, but it is one caller type among many. The underlying infrastructure is general-purpose. Every example below is the same product, the same API, and the same topology model. What changes is who is calling and why.
A data analyst as the caller. Loading several gigabytes of CSV data into a columnar warehouse, running aggregations, exporting results to S3-compatible object storage. One API call. R, ClickHouse, and a storage bucket. The data lands, the analysis runs, the artifacts drop into the bucket. Tear down the runtime, keep the bucket.
A CI pipeline as the caller. Every pull request gets its own topology, sized to the test it runs. A unit test pipeline gets a runtime alone. An integration test for a search-driven feature gets a runtime, MySQL, and an Elasticsearch cluster. A workflow that exercises an event-driven service gets a runtime, MongoDB, and a Kafka cluster. Fresh state every time, no shared environment between branches, automatic teardown when the build completes.
A developer as the caller. Prototyping a feature that needs streaming. The developer requests a topology with Go, a Kafka cluster, and a key-value store. Working against real services from the first line of code, no local Docker Compose, no setup project. When the prototype is done, the topology is destroyed; when the work resumes next week, a new topology is created from the same definition.
A scheduled job as the caller. A nightly ETL runs as fire-and-forget execution: a topology with Python, a DuckDB instance for transformation, and an object storage bucket for the output. The script reads upstream data, transforms it, writes Parquet files to the bucket, and the topology is destroyed. No session management, no leftover infrastructure, no monthly cost for a container that runs for fifteen minutes a day.
A platform builder as the caller. A SaaS company offering customer-facing AI features provisions a topology per end-user request: a runtime with their custom image, a Postgres for that user's session state, a vector database for retrieval, and a Redis instance for response caching. The platform builder calls the same API the others do; their end users never know cloud infrastructure is involved.
The pattern across all five is consistent: connected infrastructure, temporarily, without managing any of it.
The competitive landscape has three established categories, and a gap between them that AI-driven development is forcing open. Sandbox providers have built strong products for isolated code execution. Persistent infrastructure providers offer managed databases and backends for long-lived applications. IaC tools automate provisioning but require human-driven workflows. Ephemra sits in the gap: real services, connected and ready, provisioned at runtime with dynamic state managed by the platform.
| Sandboxes | Persistent Infra | IaC (e.g. Terraform) | Ephemra | |
|---|---|---|---|---|
| What you get | A container | Managed services | Scripted cloud resources | A connected topology |
| Lifecycle | Minutes | Months / years | Long-lived, human-managed | Minutes to hours |
| Services | Runtime only | Database, auth, storage | Anything, if you script it | Runtime + DB + cache + queues, wired |
| Setup | One API call, seconds | Account + project config | Plan + apply, human-driven | One API call, seconds to minutes |
| Teardown | Automatic | Manual | Manual or scripted | Automatic, full or per-service |
| Billing | Per-second container | Monthly | Underlying cloud costs | Per-second per-service |
The product is complementary to all three. A team using sandboxes for code execution and a managed database for production data might use Ephemra for integration testing, staging, and agent workflows. A team using Terraform for production infrastructure might use Ephemra for the short-lived environments Terraform was never designed for. Each serves a different moment in the development lifecycle.
Three overlapping segments define the addressable market: AI agent infrastructure, ephemeral development and testing environments, and CI/CD pipeline environments.
The fastest-moving segment. The coding AI market reached approximately $4 billion in late 2025, with GitHub Copilot, Claude Code, and Anysphere's Cursor each crossing $1 billion ARR, and seven companies surpassing $100 million ARR (CB Insights, December 2025). Gartner estimates the AI code-assistant market at $3.0 to 3.5 billion in 2025. Developer adoption is mainstream: 84% of developers use or plan to use AI tools, and 51% use them daily (Stack Overflow 2025 Developer Survey). GitHub Copilot alone has crossed 20 million all-time users (TechCrunch, July 2025).
As agents move from code completion to autonomous task execution, they need databases, caches, and connected services to do real work. Infrastructure is a meaningful and growing share of agent platform costs. That infrastructure spend is the segment Ephemra targets directly.
Developers and teams pay for always-on staging servers, preview environments, and test databases that sit idle the majority of the time. Railway (2 million users), Render (4.5 million developers), and Fly.io collectively serve millions of developers with persistent infrastructure. A meaningful portion of those workloads are episodic, bursty, and better served by per-second billing against real services torn down when the work is done.
Every pull request that needs an isolated database or full-stack environment for integration testing is a potential topology. The continuous delivery market is estimated at $3.5 to 5 billion (industry estimates, 2025). The subset requiring multi-service environments, not just a container to run unit tests, represents roughly a third of that spend.
Worldwide AI spending is forecast to total $2.53 trillion in 2026, with $1.36 trillion in AI infrastructure alone (Gartner, January 2026). AI infrastructure spending reached a record $86 billion in a single quarter in Q3 2025, on pace for $758 billion annually by 2029 (IDC). Within that, the shift from AI-assisted coding to AI-agentic coding is the inflection point that creates demand for Ephemra's category.
The revenue ramps in adjacent markets are extraordinary. Cognition's Devin grew from $1 million to $73 million ARR in nine months (Bloomberg, September 2025). StackBlitz's Bolt.new reached $40 million ARR in six months (CB Insights). Anysphere raised $900 million at a $9 billion valuation after Cursor crossed $1 billion ARR. VC investment in agentic AI grew from $4.6 billion in 2024 to $6.4 billion through October 2025 (PitchBook), with agentic AI companies raising $2.66 billion in Q1 2026 alone, a 143% year-over-year increase (CB Insights).
The infrastructure layer has not kept pace. Sandbox providers (E2B, $35 million raised; Daytona, $31 million raised) provide isolated runtimes but stop at the container boundary. Persistent infrastructure providers (Railway, $100 million raise; Render, $100 million raise at $1.5 billion valuation) serve long-lived workloads with monthly billing. No current player offers a single API call that provisions a connected topology of runtime, database, and cache with per-second billing and automatic lifecycle management.
Billing is per-second, per-service. Each service in a topology is billed independently for exactly the time it runs. Pricing is fully usage-based and the per-second rates are all-inclusive.
Pricing scales with topology size. A small topology with a runtime, Postgres, and Redis costs $0.17 per hour. A standard production-grade topology, with larger instances suitable for serious workloads, runs at a higher rate aligned with the underlying resources consumed. A five-minute task on a small topology costs approximately $0.014. A 30-minute session costs approximately $0.085. For roughly $0.04 per hour more than what existing sandbox providers charge for a container alone, Ephemra provides a full topology with a real database and cache.
A usage dashboard and configurable spending caps give callers full control over costs.
Enterprise and bring-your-own-cloud arrangements are priced separately. In BYOC mode, the underlying cloud spend goes directly to the customer's cloud provider at their negotiated rates, and Ephemra is invoiced for the orchestration layer. Enterprise pricing reflects the dedicated infrastructure, integration, and support requirements that go beyond standard usage-based billing. Detailed pricing for these arrangements is available on request.
The current product is ephemeral topologies: spin up, use, destroy. This is the foundation. Four natural expansions build on top of it.
Instead of destroying a topology, pause it. The full environment state is snapshotted: filesystem, database contents, packages, configuration. Compute billing stops. Resume later, pick up exactly where you left off. This opens the product to workloads that are recurring but not continuous.
For individual developers, this replaces the VPS that runs 24/7 for a few hours of actual use. A developer working on a side project spins up a topology when they sit down to code, pauses it when they stop, and resumes it the next day with everything intact. No server maintenance, no idle costs between sessions.
For companies, it replaces infrastructure that stays running on the assumption that someone might need it. A team that demos to clients twice a week no longer needs a persistent staging environment. They resume it before the call, pause it after. QA teams spin up a production-like topology for a test cycle, pause it overnight, and resume it in the morning. Internal tools that only see traffic during business hours do not need to run at 3 AM.
Community-contributed topology definitions that let anyone spin up any application in a single API call. A project maintainer publishes a definition. A user clicks one link and has a running instance, with their own data, pausable and resumable. Metabase requires a JVM runtime and Postgres. n8n requires Node and a database. Plausible requires Elixir, Postgres, and Clickhouse. Each of these becomes a one-call topology. The catalog grows organically. Each new definition brings new users to the platform.
The product currently runs on AWS. The Topology Manager abstracts the underlying provider entirely. Expanding from AWS to additional providers opens geographic coverage, cost optimization, and resilience. Hyperscalers (Google Cloud, Azure, Oracle Cloud) bring marketplace access and committed-spend integration (AWS EDP, Google CUD, Azure MACC). Non-hyperscaler providers bring different price-performance profiles and capacity diversity.
The caller decides how much to specify. A caller who needs AWS in a specific region for compliance or latency reasons says so. A caller who simply needs a working topology gets the most cost-effective option available. Both use the same API. The API contract does not change.
By default, Ephemra provisions infrastructure on its own cloud accounts. For organizations that need infrastructure to run within their own cloud environment — whether for compliance, data residency, or cost allocation — the platform supports a bring-your-own-cloud model. The caller provides cloud credentials scoped to their account. The Topology Manager provisions and manages topologies within that account using the same API, the same lifecycle management, and the same interface. The organization retains full ownership of the underlying resources while Ephemra handles the orchestration. This also allows enterprises to run Ephemra workloads against their existing committed cloud spend, combining the operational simplicity of the platform with the financial structure they already have in place.
The growth path runs from ephemeral (one-off tasks, minutes) to persistent and paused (regular use, hours per day) to always-on (continuous, 24/7). The same infrastructure serves all three. Each step up is more revenue on the same platform.
Falk brings 15+ years of technical leadership experience, having served as CTO and founding member across multiple companies. He has led cross-functional teams and delivered scalable systems across industries including online travel, logistics, IoT, and DeFi. His expertise spans building and scaling engineering organizations, architecting complex systems, and driving execution from concept to production.
Louis brings over a decade of experience across product, engineering, and venture building. He previously co-founded a DeFi protocol that secured $40M+ in user funds, leading product strategy, technical architecture, fundraising, and team building. Prior to that, he launched multiple ventures at Rainmaking (acquired by Bain & Company) and Rocket Internet, combining deep technical execution with strong commercial and operational leadership.
Whitepaper v4 · Draft · May 2026 · Confidential