In this article
Generating code and operating a useful application are different achievements. An application needs somewhere to run, persistent data, a deployment process, and an identity that determines what it may access.
The brazosd serverless stack connects those concerns: agents turn requirements into software, cloud functions execute it, and cloud SQLite databases preserve application state.
What serverless delegates to the platform
Servers still exist. Serverless means that builders need not manage a separate machine and its lifecycle for every small application.
Think of a workshop with shared facilities. Applications bring business logic; the platform supplies an execution environment, an access endpoint, and lifecycle management. Idle execution resources can be reclaimed and prepared again when work returns.
brazosd cloud functions can also serve streaming responses and WebSocket connections. “Function” describes an application execution unit, not necessarily a tiny fragment that finishes in milliseconds.
Why execution and data are separate
State held only in a process's memory or temporary files cannot be relied on after the instance is reclaimed. Durable business records need a separate home.
| Component | Analogy | Responsibility |
|---|---|---|
| Agent | A builder interpreting requirements | Create, revise, coordinate software |
| Cloud function | An execution workspace | Run application logic and serve requests |
| Cloud SQLite | A business ledger | Preserve structured application records |
| Cloud Drive | A shared filesystem | Preserve materials and deliverables |
Swipe to see the whole table
Functions may restart while records remain. Database compute has its own lifecycle, so retaining data need not require keeping the same execution process alive.
How SQLite becomes a cloud database
SQLite supplies tables, SQL queries, and transactions. SQLess, integrated into brazosd, adds remote connectivity, authentication, compute scheduling, and persistent storage.
Database pages can be fetched on demand. Idle compute can be reclaimed and activated by a later SQL request. Durability belongs to the storage protocol rather than depending on one continuously running process.
Each database has one valid read/write owner at a time. This creates an explicit consistency boundary; it does not turn a database into an automatically distributed, unlimited parallel writer.
SQLess also includes sqlite-vec for storing vectors and querying similarity through SQL. Vectors are numerical representations of content, useful for semantic retrieval. An application still needs a model or processing pipeline to generate them; the database does not automatically understand every file.
Models handle change; code handles repetition
Consider orders arriving in a stable format. Asking a model to reason through the same validation rules for every order adds inference cost, latency, and variability.
An agent can instead establish the processing logic. A cloud function then validates, calculates, and writes records according to that logic. New requirements or unusual cases can bring the agent back into the process.
An agent's output becomes reusable software. The benefit depends on workload, model use, and resource consumption; the architecture alone does not establish a fixed savings percentage.
Deployment and identity matter too
Cloud functions use versioned packages. New instances pass health checks before receiving traffic, and deployment history supports returning to an earlier release. Reverting code does not revert database records, so schema changes still require compatibility planning.
Functions also have dedicated service identities. Access to Cloud Drive or platform APIs should be granted to that identity, rather than inherited from an administrator's personal credentials. Agent-generated code follows the same boundary.
These details may be less visible than a generated page, but they determine whether software can be used beyond a demonstration.
Current scope and future development
The current function model uses one steady-state instance, with overlap during deployment. It does not provide automatic horizontal scaling with traffic. Idle reclamation, activation, and horizontal scaling are distinct capabilities; cold-start delay also affects the experience.
Serverless moves recurring infrastructure work into the platform, making specialized applications easier to build and maintain. It supports “cloud apps as processes” in UnoZ OS and the direction of brazosd on brazosd. Implementation and release workflows are covered in the cloud application documentation.