Boxel Whitepaper

Executive Summary

We are witnessing the most significant shift in software development since the invention of high-level programming languages. Large language models (LLMs) can now generate functional code in seconds. Yet the infrastructure surrounding that code—the databases, the deployment pipelines, the security models, the economic relationships—remains trapped in paradigms from the 1990s.

The result is a peculiar kind of friction. You can ask Claude to write you a React component in thirty seconds, but deploying that component to production still requires navigating a maze of Git repositories, CI/CD pipelines, environment variables, SSL certificates, and cloud provider dashboards. The intelligence has arrived, but the architecture hasn't caught up.

Boxel is what comes next: a complete environment where AI-generated software can be created, run, evolved, and monetized without ever leaving a coherent system. Not another tool to add to your stack—a replacement for the stack itself.

In concrete terms, Boxel provides:

• A compressed stack where TypeScript + JSON files are the application—no separate database, no deployment pipeline, no context lost between tools
• A unified environment with three modes (Host, Interact, Code) and AI built into every surface
• An ambient database that indexes your JSON files automatically into queryable, relational data
• A type catalog of reusable Cards and Fields so domain logic compounds instead of getting rewritten
• A builder economy where you pay other creators for proven components—not AI companies to regenerate from scratch

The result is a paradigm we call "software as media"—where Cards flow between contexts like photographs flow between apps, carrying their own data, their own rendering logic, and their own behavior.

The core insight is deceptively simple: if AI excels at reading and writing files, then we should build an architecture where files are the application.

This paper explains why we built Boxel, how it works, and what it means for the future of software creation.

The Fragmentation Problem

Open your browser tabs right now. If you're building anything with AI, you probably have ChatGPT or Claude open for ideation and code generation. Cursor or Windsurf for editing that code in context. V0 or Lovable for generating UI components. GitHub for version control. Vercel or Netlify for deployment. Notion or Confluence for documentation. Figma for design. Slack or Discord for communication.

Each of these tools is excellent at what it does. Each represents millions of dollars in engineering investment and years of refinement. And each is a silo.

The workflow: describe an idea to ChatGPT, copy the code into Cursor, commit to GitHub, deploy to Vercel, document in Notion, share in Slack. At each boundary, you lose context. The AI that helped you write the code doesn't know how you deployed it. The documentation system doesn't understand the code it describes.

This is the fragmentation problem, and it's getting worse, not better.

The irony is acute. We have AI systems capable of understanding complex software in its entirety—but we force them to operate through disconnected interfaces, each with its own authentication, its own data model, its own limitations. We have given AI the ability to think holistically while constraining it to act in fragments.

Consider what happens when you ask an AI to "build me a CRM" (customer relationship management system). A modern LLM understands what a CRM does—it can generate the database schema, the API endpoints, the frontend components. But then you spend hours figuring out how to make that code actually run. You need a database, hosting, authentication, environment variables, CI/CD. The ten percent that requires intelligence is done in seconds. The ninety percent that requires infrastructure takes days.

Our tools were designed for an era where code generation was the bottleneck and infrastructure was a solved problem. That era is ending. The new bottleneck is the gap between what AI can imagine and what our infrastructure can execute.

Accidental Complexity: The Reuse Problem

There's a deeper dysfunction in how we build software, one that predates AI but becomes painfully obvious in the age of AI-generated code.

When a team decides to build an application, they first choose a stack—JavaScript, Ruby on Rails, Python with Django—and a set of libraries: open-source tools for UI components, database access, authentication. This part of software development is remarkably efficient. The open-source ethos of reuse means you're standing on the shoulders of thousands of contributors. Nobody rewrites React from scratch.

But here's where it breaks down. The domain logic—the actual business concepts like Invoice, Customer, Vendor, Project, Task—gets rewritten from scratch for every single application. The code that defines what the business actually does is ephemeral. Switch stacks, and you lose it. Build a new app, and you start over. The patterns that matter most to your business have the shortest lifespan.

This is what we call accidental complexity: the unnecessary friction and redundancy developers face because our tools optimize for the wrong layer.

The longevity of software currently resides in the libraries—React, Express, PostgreSQL. But these are meaningless to people who aren't developers. Nobody runs a business on "React." They run a business on invoices, customers, products, and orders. Yet the code that represents these concepts is the code we throw away most often.

Consider how backwards this is. The stack—the technical plumbing—is globally reused and continuously improved. The domain logic—the part that actually creates business value—is locally written and constantly abandoned. We've built an industry around reusing the parts that don't matter to end users while constantly reinventing the parts that do.

Boxel inverts this relationship. Instead of reusing low-level libraries while rewriting business logic, we make business logic itself reusable. An Invoice card isn't just code—it's a piece of software media that carries its schema, its templates, and its logic. Like a photograph that flows between apps without losing its meaning, a Card flows between contexts while remaining fully functional. Use someone else's Invoice card. Extend it for your needs. Contribute your improvements back. The domain concepts that actually matter become the things that persist and compound.

The goal is to eliminate accidental complexity by moving reuse up the stack. Distill software down to its essential complexity—the pure domain model—and wrap it in a Boxel that can be shared, adopted, extended, and composed.

The name tells the story. Boxel comes from "box" plus "element"—by analogy with pixel (picture element) and voxel (volume element). Think of Minecraft: complex structures assembled from simple, standardized blocks. A Boxel is a "box element" for the web—spatial and nested. A Boxel can contain other Boxels, like a folder containing files. Drag the folder, and everything inside moves with it. Like Minecraft blocks, but for the concepts that actually run businesses.

This is what the type catalog represents. Not just convenience, but a fundamental shift in what gets reused. When you build with standard Invoice, Contact, and Product types, you're not just saving time—you're participating in an ecosystem where domain logic finally gets the same treatment as infrastructure code.

The Compressed Stack: Why Traditional Architecture Fails AI

To understand why current AI coding tools produce such frustrating results, you need to understand what they're working with. The traditional "full stack" is not one thing—it's four hostile layers, each with its own language, its own paradigms, and its own invisible dependencies.

At the bottom sits the database layer: PostgreSQL, MySQL, MongoDB. Change something here, and you need a migration—a carefully orchestrated transformation that can take down your application if you get it wrong.

Above that sits the backend layer: Python, Node.js, Ruby, Go. Business logic that speaks to the database through an ORM (object-relational mapper), exposes capabilities through APIs (application programming interfaces), and requires documentation that inevitably drifts from reality.

Above that sits the frontend layer: React, Vue, Angular, Svelte. What users see and touch, speaking to the backend through HTTP requests, managing state that may or may not match what's in the database.

And wrapping all of this sits the infrastructure layer: Terraform, Kubernetes, AWS, Docker. Configuration files where a single missing environment variable can bring down the entire system.

Now consider what happens when an AI tries to work with this architecture.

The AI operates through a context window—a limited amount of text it can see at once. It sees your React component but not the SQL schema that defines the data. It sees your API endpoint but not the infrastructure configuration.

The result is "fix this, break that" loops. The AI updates your frontend to display a new field. But that field doesn't exist in your API. So the AI updates the API. But the field doesn't exist in your database. So the AI writes a migration. But the migration conflicts with your ORM. Each fix creates a new problem in a layer the AI couldn't see.

This isn't a limitation of AI intelligence—it's a limitation of the architecture. The conventional response is "better tooling": smarter IDE integrations, better prompting strategies. These help at the margins. But the architecture itself is hostile to AI-assisted development.

The alternative is to compress the architecture.

This is the Boxel architecture—not a simplification, but a recognition that AI works differently than human engineering teams, and our infrastructure should reflect that.

Think about what LLMs are trained on: billions of documents, articles, code files. They're extraordinarily good at reading text files and writing text files. They understand JSON natively—it's one of the most common formats in their training data. They understand TypeScript deeply—it's one of the most documented languages in existence.

So we built a system where the entire application is just files AI can read and write. The database is JSON files the AI can inspect directly. The UI is TypeScript templates the AI can modify in place. The schema is TypeScript definitions the AI already knows how to work with. Everything composes. Everything is visible. Every change takes effect immediately.

The Three Memories: A Cognitive Architecture for AI-Assisted Development

The cognitive analogy is useful for understanding why the compressed architecture matters. Think of AI as having three types of memory, each with distinct characteristics and limitations.

Muscle Memory is the model itself—patterns learned during training. The model "knows" how to write Python, format JSON, structure React components. This memory is vast but frozen. The model cannot truly learn new things permanently; when you ask about your company's specific API, it's inferring from whatever context you provide.

Short-Term Memory is the context window—the active conversation. Modern context windows are large—and growing—but volatile. Close the tab, and it's gone. Dump your entire codebase, and the AI struggles with the "messy desk" problem.

Long-Term Memory is the database—the persistent state. Customer lists, invoices, blog posts, configuration files. Everything that makes your application yours rather than a generic template.

The fundamental problem with current AI coding tools is that short-term memory is disconnected from long-term memory.

Current AI systems are, metaphorically, "brains in a jar"—floating outside your actual data. They're brilliant at reasoning, but they're reasoning about abstractions rather than realities. When you ask ChatGPT to help you build a feature for your application, it's working from descriptions you provide, not from the actual state of your system. It hallucinates features because it can't verify they exist. It introduces bugs because it can't check whether its assumptions match your data.

To bridge this gap, users resort to manual copy-paste: extracting code from their IDE, pasting it into ChatGPT, copying the response back. This is tedious, error-prone, and fundamentally limited. You can't paste your entire database into a chat window.

Boxel closes this loop. The AI has direct read/write access to your long-term memory—the "Realm." When you ask for a change, it reads your files, reasons about what needs to change, and writes the changes back. The system indexes all your files so the AI can search them instantly. The complete loop: Muscle Memory (model) uses Short-Term Memory (chat) to reason, then commits to Long-Term Memory (Realm). The application evolves and remembers.

This is what distinguishes Boxel from tools that provide "AI assistance." The assistance is the development environment. The AI doesn't help you write code—it writes code, directly, into a system designed to receive it.

The Unified Environment: Three Modes, One System

Boxel unifies chat, code editing, vibe coding, and hosting into one self-contained environment. But "unified" doesn't mean "homogeneous." Different tasks require different interfaces. The key is that switching between them shouldn't require switching between tools.

We organize Boxel around three modes, each optimized for a different kind of work:

Host Mode is for publishing and deployment. Configure how things display, set permissions, publish URLs, connect domains. When you share a link to something you've built, this is what recipients see. Host Mode answers the question: "How does this show up when I share it?"

Interact Mode is for daily use and creation. Navigate between cards, use the AI assistant, connect data across different applications, get actual work done. This is where you live most of the time—working with your applications as a user rather than a developer. Interact Mode answers the question: "How do I use what I've built?"

Code Mode is for deep editing and extension. Full IDE capabilities, complete access to the underlying TypeScript and JSON files, the ability to extend anything in any direction. Modify generated code, add features, debug problems, visualize schemas. Code Mode answers the question: "How do I change how this works?"

These three modes represent three different relationships to the same underlying reality. In Host Mode, you're a publisher. In Interact Mode, you're a user. In Code Mode, you're a developer. Same files, same data, same system—different lenses.

Host Mode gives you the publishing capabilities of Webflow. Interact Mode gives you the daily workspace of Notion. Code Mode gives you the IDE power of Cursor. Currently, these are three separate products with three separate data silos.

Boxel collapses these boundaries. The project plan you wrote in Interact Mode is the same data that renders in Host Mode and that you extend in Code Mode. No export. No import. No sync.

On the Roadmap: Run Mode and Design Mode

The mode system is designed to grow. Two modes are in development:

Run Mode will handle automation: scheduled tasks, responding to external events (like payment confirmations or form submissions), and mixing scripted logic with AI judgment. Define a deterministic command for the predictable parts; let AI handle the edge cases. Automation that's reliable where it needs to be, intelligent where it helps.

Design Mode will provide a spatial canvas for layout and composition. Place any Card on the board—at any format—and retain full interactivity. Zoom in to edit details, zoom out to see the whole system. Not a static mockup: the real working application, arranged visually.

Other tools force you to choose: IDE or no-code builder, writing code or using an application. Boxel gives you all three, and switching is instantaneous. Your context travels with you. The AI knows which mode you're in and adapts its assistance accordingly.

This matters because real work doesn't fit neatly into categories. You might start in Interact Mode, using your CRM to look up a customer. You notice the dashboard is missing a field you need. You switch to Code Mode, add the field to the schema, update the template. You switch to Host Mode, verify the change looks right when shared. You switch back to Interact Mode and continue your work. The whole sequence takes minutes, and you never leave Boxel.

The Two Starting Points

Boxel supports both approaches to AI-assisted development:

Starting from nothing: Describe what you want, AI builds it. "I need a project tracker with tasks, deadlines, and team assignments." The AI generates the schema, templates, initial data structure. Ideal for exploring ideas or building something truly custom.

Starting from the end product: Begin with a working application and modify any aspect. Take an e-commerce app, ask the AI to add Stripe integration, redo the dashboard, swap image handling for 3D models. Preserve what works while changing what doesn't.

The power is composability without regeneration. Instead of generating every application from scratch, you assemble proven building blocks. "I want a blog that allows tipping" doesn't mean writing tipping logic from scratch—it means taking a Blog Card, attaching a Payment Card, linking them together. Fewer bugs, because you're assembling proven components.

Full depth for those who want it, full accessibility for those who don't.

You Only Vibe Code What Makes It Unique

Current vibe coding tools generate impressive UIs but miss essential infrastructure—authentication, error handling, data validation, permissions, real-time sync. The AI generates what's visible and forgets what isn't.

Boxel inverts this. We provide the complete architecture; you only vibe code the domain model. Think of it like a game engine—developers don't regenerate physics engines for every game. They build on proven infrastructure and focus on what makes their game distinctive.

Boxel is that infrastructure for business software. Query system, indexing, security boundaries, real-time updates, computed properties—all built in. You bring the domain expertise. You define Invoices, Customers, Projects. The platform handles everything else.

This is why Boxel applications reach production while most vibe-coded projects die in demo. You're not generating infrastructure—you're configuring it.

Memory That Persists: Breaking Out of Chat

In most AI coding tools, the chat is your project. Your work exists within the conversation thread. Lose the chat, lose the work. Start a new conversation, and you're starting from scratch—re-explaining context, re-uploading files, re-establishing the mental model the AI needs to help you.

This is backwards.

Chat is a wonderful interface for exploration, ideation, and iteration. But it's a terrible container for persistent work. As we established in §4, chat is short-term memory—volatile and expensive. Long-term memory belongs in the Realm.

Boxel inverts this relationship. Chat sessions are temporary assistants—helpers you summon for specific tasks. The workspace remembers. The sessions don't have to.

This enables multi-session workflows. Instead of one enormous thread containing your entire project history, you work with focused, lightweight sessions. Fix this bug. Add this feature. Refactor this component. Each session is disposable—the workspace carries the context.

The technical mechanism is smart context management. When you're viewing a form, the AI loads only that form's schema and template—not the entire codebase. The system's consistent patterns let the AI infer connections without seeing everything. Most changes are local; the architecture takes advantage of this.

The contrast with current tools is stark:

The phrase we use internally is "break out of chat." Chat is a modality, not a container. Use it when it's useful. Discard it when it's not. Your work persists regardless.

Data That Just Works: The Ambient Database

The dirty secret of "vibe coding" tools is that data is an afterthought. AI generates beautiful interfaces, impressive-looking code, functional demos. But when you look closer, the data is fake. Placeholder text. Hardcoded arrays. Sample data that exists only within the generated code.

To make that data real, you need a database. And the moment you need a database, you've left the realm of vibe coding and entered the realm of traditional software engineering. You need to choose a database provider—Supabase, PlanetScale, MongoDB Atlas. You need to configure connections, manage credentials, write migrations. You need to think about schemas, indexes, query optimization. The flexibility that made vibe coding feel magical evaporates the moment you need persistent, queryable data.

This is the data problem, and it's why most vibe-coded applications never make it to production. The demos are compelling. The reality is that turning those demos into real applications requires exactly the infrastructure expertise that vibe coding was supposed to eliminate.

Boxel solves this problem by making the database ambient. You don't configure it. You don't think about it. It just exists.

Here's how it works: Your data lives as JSON files in the file system. When you create a Card—a contact, an invoice, a blog post—Boxel writes a JSON file. That file is automatically indexed into a queryable database. The indexing happens continuously, reactively, in the background. You get a real database without ever setting one up.

This approach gives you two ways to interact with data:

Direct JSON files are ideal for bulk operations. When AI generates data—customer lists, product catalogs, initial content—it writes JSON files directly. The system indexes them automatically. This is what AI is trained to do: write files. No special database syntax required.

The Card API is ideal for interactive use. When users edit data through forms, they're modifying objects that automatically persist to JSON and update the index. The same data model works whether you're bulk-importing ten thousand records or editing a single field in a form.

The result is that data just works. AI outputs JSON because that's what it's good at. The system turns that JSON into queryable, relational, indexed data. You don't manage the translation—it happens automatically.

Computed Properties: Excel for Applications

One of the most powerful features of this architecture is computed properties. Think of them as Excel formulas for your application data.

In Excel, you can write =SUM(A1:A10) and the cell automatically updates whenever any of those source cells change. It's reactive computation—define the relationship once, and the system maintains it forever.

Boxel brings this pattern to application data. You define computed fields in your schema:

@field totalRevenue = @field.computed(() =>
  this.invoices.reduce((sum, inv) => sum + inv.amount, 0)
);

@field lastActivity = @field.computed(() =>
  Math.max(...this.activities.map(a => a.timestamp))
);

These aren't queries you run; they're fields that exist and update continuously. Change an invoice amount, and totalRevenue recalculates. Add a new activity, and lastActivity updates. The computation happens both in the browser (as you type) and on the backend (during indexing). The computed values are written into the documents themselves, so they're searchable and queryable like any other field.

Why does this matter? Because AI already understands this paradigm. Every LLM has been trained on countless Excel tutorials, spreadsheet documentation, and formula examples. When you ask AI to "add a field that shows the total value of all orders," it knows exactly what you mean. It doesn't have to learn a new paradigm—functional reactive computation is already in its training data.

Query System and Dashboards

The query system powers dashboards. A single query can span all your applications—CRM, invoicing, projects, HR—because it's all stored in the same underlying system. Every Card can reference every other Card. Every dashboard can pull from every data source. The silos that plague traditional software don't exist here.

The Type Catalog: Standing on Shared Foundations

Boxel ships with an extensive catalog of field types, card types, and UI patterns that grows with the ecosystem.

Field types range from basic (text, numbers, dates) to semantic (emails, phone numbers, addresses, currencies with denomination awareness) to specialized (digital signatures, file attachments). Card types include business objects (Contacts, Companies, Invoices, Products) and containers (Calendars, Kanban boards, Workflows).

This isn't just convenience—it's a strategic advantage. When you build using the standard Invoice card type, your invoices are automatically compatible with every other application that understands invoices. Someone else's reporting dashboard can display them. A third party's payment integration can process them.

This is the network effect of shared types. Every builder who uses standard types instead of inventing their own makes the ecosystem stronger. You're not locked in—you can always create custom types or extend standard ones. But starting from the catalog means starting with compatibility, faster AI generation, and interoperability by default.

The catalog grows continuously as builders contribute.

The phrase we use is "the database just ambiently exists." You don't install it, configure it, or maintain it. This is what infrastructure should be in the age of AI—invisible until you need it, automatic when you do.

A System You Can't Outgrow

The most common failure mode for tools that promise simplicity is that users outgrow them. You hit a feature the builder doesn't support, and suddenly you're choosing: stay constrained, or rebuild from scratch.

This is the "graduation problem." Tools easy to start with are hard to extend. Tools powerful enough to extend are hard to start with.

Boxel, built on the compressed architecture described in §3, is designed to be a system you can't outgrow.

The architecture supports this through several interlocking mechanisms:

Cross-Application Data Composability

Every application you build in Boxel can tap into data from every other application. There's no integration step, no API configuration, no data synchronization to manage. It's all the same data, in the same system, queryable through the same interface.

This sounds simple, but the implications are profound. Build a financial application, and it can automatically access your HR data, employee records, and payroll information. Build a game, and it can reference existing images and characters you've designed elsewhere. Build a dashboard, and it can pull from every data source across your entire workspace.

Traditional software requires building and maintaining integrations between each pair of applications. The complexity grows quadratically—ten applications require forty-five potential integrations. In Boxel, the complexity is constant. Every new application automatically has access to everything that came before.

Building Tools Within the Platform

When you need capabilities that don't exist, you don't have to leave Boxel to build them. You create new skills, new commands, new workflows—all within the same environment. And once built, these capabilities are available everywhere.

Integrate with an external API once, and you can create a command that's available in every application. Build a data transformation pipeline, and it becomes a reusable component. The work you do to extend the system compounds, making the system more powerful for everything you do afterward.

Automatic Modularization

Everything in Boxel is a module. Cards, fields, commands, skills—they can all be combined, extracted, and reused. This isn't something you have to think about or configure. The architecture is modular by default.

Once you figure out how to integrate with Cloudflare, you don't need to figure it out again. That knowledge becomes a module you can reuse. And you can share that module with others, contributing to a growing catalog of capabilities that reduce the code anyone needs to generate.

The contrast with traditional "template" systems is important. Templates give you a starting point, but you diverge from them immediately. Every modification takes you further from the original, and you can't easily incorporate improvements to the template into your modified version. Modules compose. You can update a module, and everything that uses it benefits from the update.

Extension Without Breaking

Perhaps the most powerful mechanism for avoiding outgrowth is extension through inheritance. You can take anything you've been using and extend it without breaking compatibility.

Say you have a CustomerContact card with fields for name, email, and company. Your enterprise customers need additional fields: contract value, account manager, SLA level. In traditional systems, you'd either modify the original (breaking everything that depends on it) or create a completely separate type (duplicating code and losing the connection).

In Boxel, you extend:

// Original card type
export class CustomerContact extends CardDef {
  @field name = contains(StringField);
  @field email = contains(StringField);
  @field company = contains(StringField);
}

// Extended card type — inherits all fields from CustomerContact
export class EnterpriseCustomer extends CustomerContact {
  // name, email, company inherited automatically
  @field contractValue = contains(NumberField);
  @field accountManager = linksTo(Employee);
  @field slaLevel = contains(StringField);
  
  // Computed properties — like Excel formulas for app data
  @field totalRevenue = @field.computed(() =>
    this.invoices.reduce((sum, inv) => sum + inv.amount, 0)
  );
  @field lastActivity = @field.computed(() =>
    Math.max(...this.activities.map(a => a.timestamp))
  );
}

The EnterpriseCustomer card is a CustomerContact card—anything that works with CustomerContact automatically works with EnterpriseCustomer. No migrations required. No breaking changes. The extension adds capability without removing compatibility.

This mechanism scales arbitrarily. You can extend extended types. You can have multiple extensions of the same base type. The inheritance hierarchy is explicit and navigable, so you can always understand what capabilities a card has and where they came from.

External Integrations and AI Flexibility

Boxel doesn't exist in isolation. The architecture supports deep integration with external systems:

• API and Cloud Integrations: Connect to any external service—Stripe for payments, Twilio for messaging, cloud storage providers, enterprise systems. Build a command once, use it everywhere.
• Local LLMs and On-Device Models: Run models locally for privacy-sensitive work or offline operation. The multi-model architecture (§11) extends beyond cloud providers to models running on your own hardware.
• MCP Client: Boxel can consume any MCP (Model Context Protocol) server, giving the assistant access to tools and resources from other systems. Connect to databases, APIs, or specialized services that expose MCP interfaces.
• MCP Server: Boxel itself can act as an MCP server. Your Cards become resources. Your Commands become tools. Other AI agents and applications can interact with your Boxel workspace programmatically.

This bidirectional MCP support is significant. It means Boxel isn't a walled garden—it's a node in a larger ecosystem of AI-enabled tools. Your workspace can both consume external capabilities and expose its own capabilities to others.

The result of these mechanisms is a system where complexity is additive rather than multiplicative. Each new application, each new capability, each new integration makes everything else more powerful. You don't hit walls. You don't need to rebuild. You don't graduate to a "real" platform. Boxel is the real platform, from day one through whatever scale you eventually reach.

Software as Media: The Paradigm Shift

Now that you've seen how Boxel works—the modes, the memory, the database, the extensibility—let's step back and consider what this architecture means.

There's a deeper shift happening here, one that goes beyond tooling or architecture. It's a shift in what software is.

For decades, we've thought of software as applications—discrete programs that run in isolation, each with its own data, its own interface, its own boundaries. You use Word for documents. You use Excel for spreadsheets. You use Salesforce for CRM. Each application is a world unto itself, and moving between worlds requires explicit translation: export, import, copy, paste, re-enter.

But this isn't the only way to think about software. Consider how we think about media.

A photograph can be embedded in a document. That document can be shared via email. The email can be archived in a folder. At no point do you worry about "which application" the photograph belongs to. It's just a photograph—a piece of media that flows between contexts as needed. The photograph doesn't care whether it's being viewed in Photos, embedded in Pages, or attached to Mail. It's self-contained. It carries its own meaning.

What if software worked this way?

This is the "software as media" paradigm—the conceptual foundation of everything described in this paper. The Card (introduced in §2 as a reusable domain concept, stored as JSON per §3, indexed per §7) is a piece of software that carries its own data, rendering logic, and behavior. Cards can be embedded, linked, composed, and remixed just like media files.

A Contact Card contains contact information and knows how to display itself—as a full profile when you're focused on it, as a compact summary when it's embedded in a project, as a tiny badge when it appears in a list, or as an editable form when you need to update it. An Invoice Card contains invoice data and knows how to render appropriately in each context. A Project Card contains project data and adapts its presentation automatically—detailed view, embedded summary, grid thumbnail, inline reference—all from the same underlying definition.

This adaptability isn't magic—it's a formal system. Every Card defines how it renders in multiple formats: isolated for full detail, embedded for inclusion in other cards, fitted for grid layouts and dashboards, atom for inline references, and edit for forms. The same underlying data, multiple presentations, all defined once in the Card's template. When you compose Cards together, each one knows how to present itself appropriately for the context it finds itself in.

These Cards flow between contexts like copy and paste. You don't worry about the runtime—you just use them like Notion docs. Embed a chart in a report. Link a contact to a project. Compose a dashboard from a dozen different data sources. The Cards know how to render themselves. The Cards know how to relate to each other. You just compose.

This is a profound shift in how we think about building software. Traditional development asks: "What application am I building?" The software-as-media paradigm asks: "What components exist, and how should I compose them?"

The Composition Model

Boxel supports several forms of composition:

• Delegate Rendering: Let a Card render itself in your context. You don't need to know how an Invoice Card displays an invoice—just embed it, and it handles the rest with its own templates, styling, and interactive behaviors.
• Linking (via linksTo): Reference another Card by identity. A Project Card links to Contact Cards that exist independently. Change a contact's email, and it updates everywhere that contact is linked.
• Containing (via contains): Embed a component directly. A Report Card contains a Summary Field, Charts Section, and Recommendations List. These don't exist independently—they're part of the report—but they're still reusable patterns.
• Composing: Combine multiple Cards and Fields into new structures. Take a Blog Card, add a Payment Field, link to an Author Card, embed a Comments Section. You haven't written a new application—you've composed existing components.

The taxonomy of components looks like this:

Cards are complete data objects with UI. Document, Contact, Invoice, Image, Event, Task—each is self-contained and self-rendering.

Fields are data types that compose into Cards. Primitive fields like String, Number, Date, Boolean. Compound fields like Address, Phone, Duration, Currency, Location. Fields carry semantic meaning that Cards can leverage.

Commands are actions that do things. Generate Image, Save File, Convert Format, Run LLM, Query API. Commands are the verbs of the system.

Skills are AI capabilities you can invoke. Prompt templates with context, domain-specific workflows. Skills teach the AI how to operate in particular domains.

Most of the time, you're not building software in the traditional sense. You're composing media—arranging existing components into new configurations, linking data across contexts, embedding functionality where you need it. The components do the heavy lifting. You do the composition.

Why This Matters

The software-as-media paradigm changes the economics of software creation.

In traditional development, building an application requires building everything that application needs—even if similar functionality exists elsewhere. Want a comment system? Build it, or find a library, or integrate a service. Each integration is friction. Each custom build is cost.

In the composition model, functionality that exists anywhere is available everywhere. Someone builds a great comment system as a Card. Now anyone can embed that Card in any context. The investment in building the comment system pays dividends across the entire ecosystem.

This is why we talk about "remixing" rather than "building." When you need a blog with tipping, you don't build a blog with tipping. You take a Blog Card, compose it with a Payment Card, and you're done. The components exist. The composition is trivial. The result is production-ready because the components are production-ready.

The shift from "software as application" to "software as media" is, we believe, as significant as the shift from desktop software to web applications. It changes not just how software is built, but how it's distributed, monetized, and evolved. The implications ripple through every aspect of the software industry.

The Skill System: Teaching AI to Do Anything

Boxel's vibe coding capability—the feature that generates schemas, templates, and complete applications—is powered by skill cards that you can inspect, modify, or replace entirely.

The core skills that enable the experience:

• Boxel Environment orchestrates the assistant's behavior—understanding which mode you're in, what card you're viewing, when to switch contexts. It's the "conductor" that coordinates everything else.
• Boxel Development teaches the AI the Cardstack syntax: how to define Cards and Fields, how to structure templates, how to write idiomatic code for the platform.
• Source Code Editing integrates with our Monaco editor (the same editor that powers VS Code) to read and write files using precise search-and-replace patterns.

These aren't hidden system components. They're cards in the catalog—visible, forkable, replaceable.

Override or Extend

Don't like how we generate code? Fork Boxel Development and teach it your patterns. Want the assistant to understand a different framework? Create a skill that teaches it. Need specialized behavior for your domain? Write a skill that overrides the defaults.

The skill system is hierarchical. You can:

• Add skills that layer new capabilities on top of existing ones
• Replace skills that swap out our implementations for yours
• Extend skills that inherit from ours and add domain-specific knowledge

This means:

• Customize code generation: Train the AI for different APIs, different patterns, different styles
• Build tools for any domain: Design systems, automation workflows, data pipelines, content creation
• Genuine openness: The tools we use to build Boxel are the tools you use to extend it

The Skill Evolution Journey

Skills progress from ad-hoc prompting to reusable automation:

1. Prompt: Figure it out with AI. Ephemeral but valuable.
2. Capture: Save as a reusable skill. Repeatable.
3. Code: Convert to automated logic. Faster, cheaper, no tokens.
4. Share: Submit to the catalog. The ecosystem grows.

You don't decide upfront whether something is worth building. Start with prompts, capture what works, optimize what matters, share what's valuable.

The Extensible AI Bot

Most AI assistants are limited to specific domains—legal, finance, creative. Boxel's assistant extends through skills to do anything. One bot, infinite domains, shared context.

Instead of switching between specialized tools, you teach your assistant new capabilities. It remembers you, remembers your projects, and applies whatever skills are relevant.

Custom Commands as AI Tools

The skill system integrates with the Model Context Protocol (MCP). Custom commands become tools the AI can invoke directly—no generating code for you to run. As you build more commands, your AI assistant becomes more capable.

The Custom Menu System

Skills and commands power contextual menus. Right-click an image card:

These aren't built-in features—they're user-created skills. The phrase we use: "you are the MCP server." You're not just using AI tools—you're creating them.

From Artisan to Factory

Vibe coding, even with AI assistance, is still artisanal. One prompt, one output, one piece of software at a time. Each creation starts from scratch—or at best, from a template.

The skill system enables something different: a software factory.

Here's how it builds: A successful sequence of prompts gets captured as a skill. Useful patterns of tool calls get distilled into scripted commands. The outputs—Cards, templates, workflows—become components in the catalog. Each cycle refines the machinery.

You develop and steer your first creation through familiar prompting—conversational, exploratory, hands-on. It works. Then you use our skill and command creation tools to design and build the factory that makes it repeatable. You codify conversational prompts into repeatable loops.

Now you don't build another invoice system. You build the purchase order. The inventory tracker. The vendor portal. The factory handles the how. You direct the what.

Once the learnings are captured, human attention shifts. You stop thinking about implementation. You start thinking about what to build next. Strategy, not syntax. The factory runs. You point it.

This pattern isn't limited to software. Business workflows, creative pipelines, content production—anything repeatable follows the same arc. Develop the first iteration conversationally. Codify what works. Run the factory.

This is the difference between using AI and molding AI. Prompts are conversations. Factories are infrastructure. Build the factory, and every artifact after the first becomes faster, cheaper, and better than starting from scratch.

The Programmable Assistant: AI That Knows Your World

Generic assistants help with generic tasks—but most tasks that matter to you are specific. ChatGPT doesn't know your project data. Claude doesn't understand your business processes.

Boxel's assistant, extended through the skill system described in §10, is fully programmable. It can be taught to understand your domain, your data, and your workflows.

Multi-Model Freedom

You're not locked into a single AI provider. The system routes tasks to the right model:

• Claude Sonnet or Opus for code generation and complex reasoning
• Gemini for multimodal work and speed-critical tasks
• OpenAI GPT models for debugging and general tasks

Switch models mid-conversation. Different models have different strengths—the right model for each task, without leaving the environment.

Real-Time App Interaction

The assistant doesn't just help you think about your applications—it interacts with them directly.

Need help planning a potluck? If you've built a potluck planning app with the right skills, the assistant can help you in real time. It can see who's signed up, what dishes are claimed, what's still needed. It can suggest assignments, send reminders, update the schedule. The assistant operates through your application, not alongside it.

This is fundamentally different from copying data into a chat window and asking for advice. The assistant has access to live data. It can take actions that affect your running applications. It's not just an advisor—it's an operator.

Two Ways to Use Intelligence

Conversational: Chat with the AI, iterate together. Ideal for exploration, debugging, complex reasoning.

Packaged: AI wrapped as buttons, menu items, workflow triggers. "Generate summary" becomes a button. "Translate to Spanish" becomes a menu item. Reliable, fast, token-efficient.

Building New Features

The assistant helps you extend applications, not just use them. Want an assistant that understands your industry's terminology? Your coding standards? Your custom integrations? Teach it with skills.

Why Built-In Beats External

We've built Boxel Tools, a Cursor-compatible VS Code extension. But the built-in assistant is better for most tasks—because of context.

In VS Code, you specify which files to edit. In Boxel, the assistant knows what card you're viewing, what template you're focused on. Context is implicit.

The assistant isn't bolted on—it's integral. The environment assumes AI will be helping you.

The Builder Economy: Don't Pay AI Companies—Pay Each Other

Here's an uncomfortable truth about the current AI landscape: everyone is paying the same companies to generate the same things over and over.

Need a CRM? Pay OpenAI. Need a dashboard? Pay again. Each generation from scratch, each risking bugs, each payment flowing to compute providers.

The humans who figure out how to use AI effectively—crafting prompts, debugging outputs, refining to production—capture none of that value.

Boxel proposes: pay each other instead.

Most software creation is recombination. The patterns are well-established; the customization matters. So pay humans who've already done the work. Get proven solutions. Remix for your needs.

The Catalog Model

Boxel includes a catalog where builders can share and monetize their creations. The catalog isn't an app store in the traditional sense. It's more like a component marketplace—a place to find proven building blocks that you can remix into your own applications.

What can you sell? Templates, prompts, skills, complete apps, component libraries, commands, themes. The key: buyers get source plus license—full access to customize, extend, and deploy however they want. Not a black box. Not a SaaS subscription.

Two Monetization Models

Fee-for-service: Set a price, buyer pays once. Best for complete apps and templates.

Royalty system: Included in subscription pool, creators share based on usage. Best for frequently-used skills and prompts.

Earnings: Take as credit (reinvest in AI, hosting, remixing) or cash (bank transfer, PayPal). Many builders operate in a cycle: buy, sell, reinvest. The ecosystem becomes self-sustaining.

Boxel Credit: The Unified Currency

One balance covers everything: AI inference, hosting, catalog purchases. Acquire credits through membership, direct purchase, or catalog earnings. The platform handles metering, pricing, and payment.

Cardstack Rewards: Opt Into the Shared Economy

Everything in Boxel works with standard payment methods. But builders who want deeper participation in the ecosystem can opt into Cardstack Rewards—a membership program that aligns incentives between the platform and its most active contributors.

Why does this matter? In most platforms, value flows one direction: from users to the platform. The people who make the ecosystem valuable—the builders who create great components, the power users who provide feedback, the early adopters who take risks—capture none of that value.

Cardstack Rewards inverts this. Active participation earns rewards. Contribution is recognized. The builders who make the ecosystem stronger share in its success.

How It Works

• Tiered membership: Achieve tiers through activity, contribution history, or direct enrollment—unlocking lower fees, more catalog slots, and higher visibility
• Creator incentives: Builders who participate in the rewards program receive higher take-home percentages on catalog sales
• Tier-gated catalog: Builders can make work available to specific membership tiers, receiving proportional rewards from each tier's pool
• Transparent economics: How fees are allocated, how rewards are distributed, how the ecosystem reinvests—all published openly

This creates a virtuous cycle. Builders who contribute more, earn more. Earnings can be reinvested into the ecosystem or withdrawn. The platform grows because its contributors are invested in its growth—not just financially, but through aligned incentives.

Optional but advantageous. Standard payments work everywhere. Cardstack Rewards is for those who want to participate in the upside as the ecosystem grows.

Details on the Cardstack Rewards program are available separately.

The Economic Shift

Traditional: Pay AI companies, they capture value, start from scratch next time.

Boxel: Pay creators, they capture value, you have proven work to start from. Next time, you might be the creator.

Sharing is how you earn. The better you get at building, the more you can sell. Every builder who contributes makes it easier for the next builder. Not charity—a functional economy where humans who create value capture value.

Security Boundaries: Trust the Container, Not the Code

There's a reasonable concern about AI-generated software: how do you trust code that you didn't write and may not fully understand?

But before we answer that, consider a deeper question: why does your data live where someone else's code runs?

In a world where software was expensive and scarce, this made sense. Building an application required teams of specialists working for months. The code was precious. So we moved people—and their data—to where the code lived. You signed up for Salesforce, uploaded your contacts, and let their servers hold your business relationships. You subscribed to QuickBooks, entered your transactions, and trusted Intuit with your financial history. The SaaS (software as a service) model was built on this premise: the software is valuable, so you come to us.

But that world is inverting. Code is becoming abundant. AI can generate a CRM in an afternoon. The scarce resource isn't software anymore—it's your data, your context, your accumulated knowledge. The workspace full of cards representing your customers, your projects, your creative work. That's what's irreplaceable.

So why are we still moving data to where code lives?

Boxel reverses this. Your data stays in your Realm—the long-term memory introduced in §4. The code comes to you. Skills and cards are activated from within your secure environment, but the data never leaves. The code is a visitor operating under your rules.

This architectural inversion is what makes the security model possible.

Traditional security models put the burden on each application. Every app implements its own authentication, its own authorization, its own data access controls. A bug in any app can expose data it shouldn't. A malicious app can access data it wasn't meant to see. Users must trust not just the platform, but every individual application running on it.

This model breaks down with AI-generated software. Vibe-coded applications are written quickly, iterated rapidly, and may not undergo the rigorous security review that traditional applications receive. Asking AI to "add a login system" produces code that might work, but might also have subtle vulnerabilities that neither the AI nor the user would catch.

Boxel takes a different approach: vibe-coded applications should not be responsible for security. They are files that sit within security boundaries determined by the platform.

The Realm Security Model

In Boxel, security is enforced at the Realm level. A Realm is like a shared folder in Google Drive or Dropbox—a container with defined access permissions. Once you determine who can access a Realm, every application inside that Realm inherits those permissions automatically.

This means:

• Applications don't implement access control—the Realm enforces it
• A bug in your app doesn't expose data outside the Realm
• Vibe-coded apps can't accidentally leak restricted information
• Security rules are set once and apply everywhere

The analogy is physical security. A document in a locked filing cabinet doesn't need its own lock. The cabinet provides security. The document just needs to be in the cabinet. Similarly, a Card in a restricted Realm doesn't need its own authentication. The Realm provides security. The Card just needs to be in the Realm.

This dramatically reduces the risk of AI-generated security vulnerabilities. The boundary of what's visible is independent of the vibe-coded app. Even if the app has bugs, those bugs can't expose data outside the Realm's permissions.

The Unified Identity Model

Boxel uses a unified identity system across both the AI assistant and the workspace. When you chat with the assistant, you're acting as yourself—the same identity that has permissions in your workspaces. The AI can only access what you can access. The AI operates under the same security constraints you do.

This solves a subtle problem with AI assistants: whose permissions should the AI use? In systems where the AI is a separate entity, you have to explicitly grant it access, manage its permissions, worry about what it can see. In Boxel, the AI is an extension of you. Its permissions are your permissions. No separate configuration required.

Federated Identity

The identity system is federated—your organization can run its own identity server while still collaborating with users from other organizations. Neither party gives up control of their user accounts. This matters for enterprises that can't put their identity in someone else's cloud, and for cross-organization collaboration where neither party wants infrastructure dependency.

The Creator Trust Model

Here's something that differentiates Boxel from traditional application platforms: the person who builds an app can't read your data.

In traditional models, you install an app, and that app's developer has some level of access to your information—through analytics, through server logs, through the hosting infrastructure. You're trusting not just the platform, but every individual app developer.

Boxel works more like Dropbox or Google Drive. The app creator provides functionality. You provide the data. The data stays in your Realm. The creator never sees it.

This makes it easier to use apps for sensitive work. You're not trusting the person who built your invoicing template to handle your financial data responsibly. You're trusting Boxel to keep your Realm secure. The creator is just providing code that runs in your secure environment.

The phrase we use is "the app builder can't read your data." This isn't a limitation—it's a feature. It enables a trust model where you can use apps from strangers without giving those strangers access to your information.

Why This Matters for Vibe Coding

Security boundaries become especially important when AI is generating code rapidly. You can't manually audit every line. You can't verify every access control check. The code is changing too fast, and the volume is too high.

The Realm model accepts this reality. It doesn't try to make every piece of generated code secure. It makes the container secure, so the code doesn't need to be. Vibe code freely. Iterate rapidly. Trust the Realm to enforce boundaries regardless of what the code does.

This is what we mean by "trust the container, not the code." The security architecture is designed for a world where code is generated faster than it can be reviewed. The boundaries are fixed. The code is fluid. The combination is safe.

Self-Hosting: A System That Builds Itself

Boxel is complete enough that we build Boxel using Boxel.

New card types are created in Code Mode (§5). Commands integrate external APIs. Skills (§10) are distilled from AI sessions into reusable capabilities. Features begin as Markdown cards, sketched via image generation, with those cards attached to sessions that create the implementation.

This document was written this way. The skills powering vibe coding were built this way. We build Boxel inside Boxel, using the same tools we offer everyone.

This keeps us honest. Every friction point we experience, users experience. Every capability we add, we benefit from. The feedback loop is unforgiving.

The system has crossed a threshold: it participates in its own evolution. Cards created today become building blocks for tomorrow's features. Skills developed for one purpose get repurposed for others.

The workflow for building a new feature: Planning in Markdown cards → Sketching via image generation → Implementation in Code Mode (with planning cards attached for context) → Iteration → Documentation.

Every step uses the platform. Every artifact is a card. Every capability makes the next build easier.

AI Rewards Transparency: Why Open Source Matters Now

Remember "View Source"? In the early web, right-click revealed how anything worked. Transparency accelerated innovation. Then SaaS ate the world—applications moved to servers, source disappeared behind APIs.

Boxel brings it back. But this time, it's not just for humans.

View Source for the AI Age

Every Card ships with visible source—schema, templates, logic. Not compiled, not obfuscated. When you ask the assistant to customize a Card, it reads the source, understands the structure, writes the changes. The AI sees exactly what you see.

Traditional Git ceremony—branches, pull requests, merge conflicts—makes sense for engineering teams. It makes less sense when you're asking AI to "make the header blue" and want the change now. In Boxel, the source is just there. Modify it directly, ask AI to modify it, or extend from it. The transparency that once helped humans learn now helps AI customize.

Training the Models That Train You

The more open source code exists, the better AI gets at writing code like it. GitHub isn't just collaboration—it's a training dataset. Code visible there becomes substrate for future models.

The Cardstack framework is on GitHub. Every Card definition, every Field type, every template pattern. Think of it as a free context window that never expires.

When Claude or GPT encounters Boxel, it draws on patterns from training—patterns that include our code. The Cardstack Catalog extends this further: real use cases in medical, productivity, vertical industries. Each contribution teaches models not just how Boxel works, but what people build with it.

Better training → better AI assistance → more Cards built → richer training data. The ecosystem bootstraps itself.

Lineage and Attribution

Open source solves a harder problem: knowing where code comes from.

Traditional version control records fork relationships explicitly. AI complicates this—patterns blur, code gets remixed, lineage becomes unclear.

The builder economy (§12) depends on fair attribution. The Cardstack Catalog addresses this directly: it tracks remixes and builds a provenance graph. When you extend or fork a Card, the relationship is recorded. The lineage is explicit.

But explicit tracking isn't always enough. Code gets copied, patterns get absorbed, similarities emerge without formal forks. This is where source visibility matters: open code can be analyzed. Embeddings—the numerical representations LLMs use—capture semantic relationships. Similar code produces similar embeddings, even with syntactic differences. AI can validate suspected lineage or annotate ambiguous cases.

The catalog tracks what it can. AI analysis fills the gaps. Together, they enable attribution at scale.

You can't analyze similarity in code you can't see. Open source isn't just sharing—it's accountability.

The Strategic Choice

Most platforms treat openness as concession. We see it differently.

Hidden code is disadvantaged code. Models won't understand it as well. AI won't customize it as effectively. The ecosystem won't learn from it.

Open source isn't altruism. It's competitive advantage—positioning your patterns to become the patterns AI knows how to work with.

The "View Source" ethos turns out to be exactly what AI-assisted development needs. Not nostalgia—architecture. The code is visible. The AI can see it. The improvements compound.

This is why we build in the open. And we think you should too.

The Self-Improvement Loop: Humans With Good Taste

Boxel has reached escape velocity: the platform contributes to its own evolution (as described in §14). But this loop has a crucial component.

It requires humans with good taste.

The "agentic" vision imagines autonomous systems—agents that plan, execute, and iterate without human involvement. We think this misses something essential.

AI is extraordinarily good at pattern matching and generating variations. But it has no taste. It can't distinguish between technically correct and genuinely good. It doesn't know when to stop.

Taste is the human contribution. Knowing when a design is right because it feels inevitable. Recognizing elegance versus mere function. Understanding what users need versus what they say.

The Boxel loop works because humans remain as creative directors, not supervisors. AI generates. Human curates. AI iterates. Human decides when it's done.

Boxel inverts the typical platform asymmetry. Our code is open. Your code is yours. The skills powering our development are the same skills available to you. Improvements flow both ways—platform to users, and users to the ecosystem via the catalog (§12).

This is why we say "Boxel Builders" rather than "users." Users consume. Builders contribute. The AI provides leverage. The humans provide direction and taste.

Fully autonomous agents might produce functional systems. We don't believe they'll produce good systems. Good requires taste. Taste requires humans.

So yes, Boxel can help build itself. But the humans in the loop aren't optional. They're the taste. They're the judgment. They're the reason anything good gets made.

The Messaging Foundation: Where AI Meets Real Communication

A foundational architectural decision: our AI assistant is built on the Matrix protocol—a real chat system, not a proprietary interface.

This means you can invite humans into AI conversations. Colleagues can join sessions, see what the AI has done, work alongside both you and the assistant. Soon: human conversations where AI bots are invited from either side. Agents and humans collaborating across organizational boundaries, using Cards as the medium of exchange.

This points toward workflow as the next frontier.

From Workspace to Workflow

Workspace: the environment where you build applications and AI assists individual work.

Workflow: business coordination through federated chat threads between organizations—not centralized portals like SAP or Salesforce. Participants (humans or AI agents) are authenticated by their own organizations but interact in shared rooms. The thread becomes the shared record of truth. Each organization keeps private data in their Realm; the thread is where specific Cards get shared.

Cards as Business Documents

Cards become the format for business exchange. An Invoice Card isn't a static PDF—it's a live mini-application in the chat stream, with actions like "Pay" built in.

The "adoption chain": Company A sends a Payment Request card. Company B's agent adopts it and offers "Pay with USDC" or "Pay with Stripe." Integration happens during interaction, not months in advance.

Agents as Participants

Agents read threads and act on Cards. A "Checkout Bot" reads previous messages, detects an "Approve" click, and posts a Payment Request. Agents search their organization's private library, find matching records, and share into the thread.

This shifts business software from monolithic silos to composable workflows. Companies agree on Card schemas, not software vendors. Interactions can start unstructured (chat), become structured (Quote Card), and then automated (Sign/Pay).

The Foundation Is Already There

Matrix protocol is battle-tested. The Card format works. The AI assistant participates in chat. What remains: standard business Cards, agent behaviors, cross-organization trust models.

Workspace is the proof point. Workflow is the trajectory.

The Invitation

We began this paper with an observation: the tools we use to build software were designed for a world where humans wrote every line of code. That world is ending.

The infrastructure for AI-generated software is being built now. Some teams are building walled gardens. Some are building point solutions. Some are building incrementally on architectures never designed for this moment.

We've built something different: a complete environment where software creation, execution, evolution, and monetization happen within a coherent system designed for how AI actually works.

The compressed stack (§3). The three modes (§5). The persistent workspace (§6). The ambient database (§7). The skill system (§10). The programmable assistant (§11). The builder economy (§12). The security model (§13).

These aren't features bolted on. They're the foundation of software infrastructure built for the age we're entering.

Who Are the Boxel Builders?

We call the people who use Boxel "Builders" rather than "users" because that's what they do. They build things. Not all of them are programmers in the traditional sense. Some have never written a line of code. But they create—applications, workflows, automations, content systems, business tools. They make things that didn't exist before.

Boxel Builders occupy a unique position in the ecosystem:

• They are both buyers and sellers. You might buy a CRM template on Monday and sell a custom skill you built on Friday.
• They are both users and creators. The same person who uses an app in Interact Mode can extend it in Code Mode.
• They are both learners and teachers. Every skill you develop can become a skill you share. Every problem you solve can become a solution for others.

This isn't a platform where a small number of developers build for a large number of consumers. It's an ecosystem where everyone contributes, everyone benefits, and the line between creating and using dissolves.

The Depth Is There When You Need It

"Easy" tools are only easy for easy things—then you hit walls. Boxel avoids this trap by supporting multiple depths:

You're never trapped. The magic is visible, abstractions penetrable. If you need to understand how something works, you can. If you need to change it, you can.

What You Can Build

Boxel supports personal productivity tools, business applications, content platforms, creative tools, data dashboards, automation workflows, and AI-powered tools.

Large language models already contain the distilled patterns of human knowledge—compressed, latent, waiting. The barrier isn't capability; it's extraction. Boxel solves this with box elements: discrete containers that give shape to the shapeless. Like Minecraft voxels already mined and stacked in your inventory, each element—card, field, skill, or command—represents knowledge and function made tangible, ready to snap together into structures limited only by what we can envision. The constraint isn't architecture anymore. It's imagination: what does infinite software look like?

The Moment We're In

The transition from human-written to AI-generated software will be one of the most significant shifts in technology history. It will change who creates software, how much of it gets made, how it's distributed, what it costs, what it can do.

The platforms emerging now will shape the landscape for decades. Some will be proprietary—walled gardens where your data feeds their models and your creations remain trapped. Boxel is our bet on the alternative: open source all the way down, a system that takes AI seriously as a collaborator, enables creation by anyone, and rewards builders, not platforms.

Start Building

If anything in this paper resonated with you, we invite you to try Boxel:

• Explore: Open a workspace and ask the AI to build something—a CRM, a project tracker, a content system. See what vibe coding feels like when the infrastructure actually works.
• Remix: Browse the catalog for components that match your needs. Customize them. Make them yours.
• Extend: Hit a limitation? Switch to Code Mode and fix it. The depth is there when you need it.
• Contribute: Build a skill, publish a template, share what you've learned. The ecosystem grows with every builder who joins.

The tools exist. The architecture is ready. The ecosystem is growing.

What will you build?