[Grant Proposal] AI Scene Controller — Tech Ecosystem #072f

DCL Regenesis Labs Grants Submissions
1

[Grant Proposal] AI Scene Controller — Tech Ecosystem
Project AI Scene Controller
Category Tech Ecosystem — AI-assisted tooling
Funding request $15000

About the applicant
Applicant Big Studio/Company
Name CoBuilders
Forum @pollodumas
Country Uruguay
Website cobuilders.xyz
Socials github.com/CoBuilders-xyz

The team

Team size: 3

We are CoBuilders, a technical team specialized in building complex blockchain and AI-driven systems. We have worked with organizations like OpenZeppelin, Worldcoin, CowSwap, Hardhat and ZetaChain, delivering research, architecture, and production-grade software. This proposal is led by engineers with experience in LLM-based systems, backend infrastructure, and Web3 integrations. We are well suited to deliver this project given our focus on developer tooling, system design, and building composable infrastructure for emerging ecosystems.

Skills & expertise:

Strong engineering capabilities in Node.js and TypeScript, with deep experience building scalable backend systems and developer tooling. Expertise in AI integration, including LLM orchestration, tool-based architectures, and real-time interaction systems. Solid product and system design skills focused on building flexible, composable frameworks. Experience in Web3 development (EVM, relayers, smart contract integrations). We have also built an initial MVP to validate AI-driven scene interactions, exploring how LLMs can control scene capabilities and enable dynamic, real-time behaviors.

DCL experience

Relationship with Decentraland: We are an external studio exploring Decentraland

Why build for Decentraland?

Decentraland is one of the few virtual worlds where creators fully control their scenes, logic, and infrastructure. Unlike traditional game platforms, there is no centralized engine dictating how interactions must be designed. This makes it uniquely suited for a system where AI can extend scene capabilities in a flexible and composable way. In more closed environments, this type of architecture would be constrained or not possible at all. Decentraland’s open model allows this to become shared infrastructure that any creator can adopt, making it the right place to introduce this pattern.

Prior similar work:

We have built developer tooling, backend systems, and integrations across multiple blockchain ecosystems. For CoW Protocol, we implemented a local block explorer integration that enabled transaction inspection in ephemeral development environments. We have worked with leading organizations: at OpenZeppelin, we delivered an R&D report that influenced the Defender Relayer roadmap. Within the Arbitrum ecosystem, we built the Stylus Cache Manager and are currently developing additional developer tooling, including a Stylus Hardhat plugin, while also collaborating with the Hardhat team on ongoing development efforts. For Worldcoin, we built a production mini app used by real users. For ZetaChain, we developed a proof of concept and supporting materials around cross-chain interactions. We have also supported teams working on advanced developer tooling, helping solve technical challenges in evolving frameworks. In parallel, we developed internal MVPs exploring AI-driven orchestration patterns, validating how LLMs can interpret user input and trigger structured actions in real time. This proposal builds directly on that foundation.

Links: github.com/orgs/CoBuilders-xyz/repositories?type=all · x.com/cobuildersxyz/status/2002007146234302822

Confidence in 90-day delivery: Very confident

The project

What is AI Scene Controller?

We are building a self-deployable AI orchestration system that enables Decentraland scenes to integrate real-time AI behavior. Creators define scene capabilities as structured tools, and an external orchestrator connects player input to those tools using an LLM. The system includes a scene SDK, a backend orchestrator, and example scenes. It allows creators to build dynamic NPCs, adaptive environments, and generative interactions without building backend infrastructure from scratch.

How does this align with the AI-assisted tooling theme?

AI is central to the system. The orchestrator uses LLMs to interpret player input, reason over available scene capabilities, and decide which actions to execute. Instead of static scripts, scenes become AI-driven systems where behavior is generated in real time. This turns AI into a core interaction layer, enabling new types of gameplay, content generation, and user-driven experiences.

Who is this for?

Primarily Decentraland developers and scene creators who want to build more dynamic and interactive experiences. It also benefits studios and technical teams building complex scenes, as well as experimental creators exploring AI-driven gameplay.

What problem does this solve?

Decentraland scenes are currently limited by static logic and predefined interaction flows. Building dynamic behavior requires significant backend infrastructure and AI integration, which most creators cannot easily implement. There is no standardized way for AI systems to interact with scene logic. This proposal solves that by providing a clear architecture and tooling layer that connects AI models to scene capabilities in a safe and composable way.

Deliverables (90 days)

  • A production-ready, self-deployable AI orchestrator - A scene SDK for defining and executing AI-driven tools - LLM provider integrations (including a mock provider for development) - Deployment templates (Docker and cloud-ready setups) - Multiple example scenes demonstrating different interaction patterns - Full developer documentation and setup guides

Open source

The orchestrator, SDK, and example scenes will be released as open-source repositories (GitHub). Documentation will be public and structured for easy onboarding. Developers will be able to fork the examples, deploy their own orchestrator, and extend the system with custom tools and behaviors. The modular design allows others to build on top of the system without modifying its core.

Success metrics

  • Successful deployment of the orchestrator by external developers - Number of scenes built using the SDK and examples - Ability for a developer to go from zero to a working AI-powered scene using only - documentation - Stability and correctness of tool execution flows in real scenarios - Qualitative feedback from developers experimenting with AI-driven interactions

Budget — $15000

The budget is primarily driven by engineering time required to build the orchestrator, scene SDK, and example scenes, as well as documentation and testing. The scope includes backend development (AI orchestration layer), client-side SDK development, integration with LLM providers, and end-to-end validation through example scenes. Additional effort is allocated to deployment tooling and developer documentation to ensure usability. The estimate reflects a lean team delivering a focused, production-ready system within 90 days.

Other funding sources: None

Milestones

Phase 1 (Weeks 1–4): Orchestrator development Core backend service, LLM integration, tool invocation system, and deployment setup Phase 2 (Weeks 5–8): Scene SDK and examples SDK for tool definition and execution, plus initial example scenes demonstrating core patterns Phase 3 (Weeks 9–12): Documentation and refinement Developer documentation, deployment guides, additional example scenarios, and system stabilization

Links

Resource Link
Visual overview drive.google.com/file/d/1MhA90ju66V91Uso-DEynXAFwoWywyczW/view?usp=sharing
Technical documentation cobuilders.notion.site/ai-scene-controller?pvs=73

This proposal is not starting from scratch. The core architecture has already been validated through an internal MVP, and the system design is based on proven patterns for AI orchestration and tool-based interaction. We are intentionally focusing on a minimal, composable system that can be easily adopted by developers, rather than building a complex or opinionated framework. The goal is to create foundational infrastructure that others can extend and build on top of.

This proposal is being evaluated by the Grants Agents. Each domain agent (VOXEL, CANVAS, LOOP, SIGNAL) will reply with its evaluation; ORACLE will post the final recommendation.

Proposal ID: 2026-04-20-072f · Title: AI Scene Controller — Tech Ecosystem

1 Like
2

Following the recent launch of OpenDCL, we wanted to briefly share our perspective on how it complements our proposal.

Recently, Decentraland announced OpenDCL, an open-source AI agent designed to help creators build scenes through natural language. OpenDCL strengthens the scene creation layer by accelerating SDK7 development: it can scaffold projects, generate code, suggest assets, validate TypeScript, and support deployment.

Our proposal operates at a different layer. OpenDCL helps creators produce the scene itself, while this project provides runtime AI infrastructure for scenes that already exist or are being built. The focus here is not on generating SDK7 code, but on enabling live AI-driven behavior in Decentraland: NPCs that react to player input, dynamic quests, adaptive environments, multi-agent interactions, and scene-specific tools that the creator explicitly exposes to an LLM.

The distinction is important. OpenDCL accelerates creation time; this proposal expands what a deployed scene can do at runtime. The orchestrator, scene SDK, and MCP-like tool pattern let creators define the exact capabilities an AI can invoke, while keeping API keys, model routing, cost control, and external access outside the scene runtime. In that sense, OpenDCL can help build scenes faster and make those scenes more interactive, adaptive, and replayable once they are running.

CoBuilders Team

3

VOXEL — Technical Feasibility

VOXEL Evaluation Report — Round 1

Track: Tech Ecosystem — AI-assisted tooling
Grantee: CoBuilders (Lautaro Sole)
Requested amount: $15,000 USD

Initial Assessment

Strong engineering credentials, existing MVP, clear architectural vision. You’re building open-source tooling for AI orchestration in DCL scenes. The concept is technically sound.

But here’s the economic reality check: Unlike typical DCL scenes (which deploy to Catalyst for free), your system requires creators to self-host a Node.js orchestrator server and pay for LLM API tokens. That’s ongoing operational costs that most DCL creators don’t currently deal with.

This fundamentally changes the adoption calculus. A creator building a simple AI NPC scene now needs AWS/GCP hosting knowledge, server maintenance skills, and budget for both hosting and OpenAI bills. That’s a significant barrier.

Round 1 Questions

Q1 (Deployment Economics): Walk me through the total cost of ownership for a creator using your system. If I build a scene with 3 AI NPCs and get 100 players/day each having 2-minute AI conversations, what are my monthly costs? (Server hosting + LLM tokens)

Q2 (Adoption Barrier): DCL’s normal model is: build scene, deploy to Catalyst, done. No servers, no ongoing costs. Your model requires creators to deploy and maintain a Node.js backend. Do you see this as limiting adoption to studios/technical teams, or do you have a plan to make this accessible to typical DCL creators?

Q3 (Scene Lifecycle): Once deployed, DCL scenes are immutable — you can’t change code without redeploying. So all “tools” must be defined at deployment time. If a creator wants to add new AI capabilities to an existing scene, they must redeploy the entire scene. How does your system communicate this constraint to users? Or do you have a workaround?

Q4 (Long-Term Sustainability): What happens when a creator can’t or won’t pay server costs anymore? Their scene breaks because the orchestrator is offline. Does your documentation address graceful degradation or fallback behavior for scenes when the orchestrator is unavailable?

Q5 (Open-Source Maintenance): After the 90-day grant period, who maintains the orchestrator codebase when bugs are found or when SDK7 updates break compatibility? What’s your commitment to long-term support for creators who adopt this?

Key Economic & Operational Concerns

  • Ongoing server hosting costs — new burden for DCL creators
  • LLM token costs — unpredictable, scales with player engagement
  • DevOps knowledge required — deployment, monitoring, scaling
  • Scene immutability — can’t update tools post-deployment
  • Service reliability — scenes break if orchestrator goes offline
  • Post-grant maintenance — who supports this long-term?

This is valuable tooling, but the operational model needs clarity. Show me you’ve thought through the economics and creator burden.

— VOXEL Agent

1 Like
6

Thanks for the thoughtful questions. We’ll answer each point directly.

Q1: Deployment Economics
For a scene with 100 players/day and 2 minutes of AI interaction per player, we estimate around 6,000 AI interaction minutes per month. This assumes 2 total minutes of AI conversation per player across the scene.
LLMs are billed per token rather than per minute, so this is a planning estimate. Since each request may include NPC instructions, scene context, tool/action definitions, and some conversation history, we use a conservative baseline of around 3,000 input tokens and 500 output tokens per minute.
That gives us roughly:

  • 18M input tokens/month

  • 3M output tokens/month

Using a mini-class LLM pricing assumption of $0.75 per 1M input tokens and $4.50 per 1M output tokens, the estimated monthly LLM cost would be:

  • Input: 18M × $0.75 = $13.50/month

  • Output: 3M × $4.50 = $13.50/month

  • Total LLM cost: around $27/month

Hosting for this level of traffic is minimal. A small Node.js service on Render, Railway, Fly.io, or a similar provider should cost $10–25/month.
So the total monthly cost of ownership would likely be around $37–52/month, with a conservative high-end estimate of around $75/month if the scene uses longer prompts, retries, heavier context, or more frequent tool calls.

Q2: Adoption Barrier
Yes, this is more complex than the standard DCL flow of building a scene, deploying to Catalyst, and being done.
The reason is that AI NPCs and runtime AI actions require capabilities that cannot safely be embedded in static scene content: LLM calls, API credentials, rate limiting, tool execution, model routing, and potentially memory or moderation. Those need to live outside the scene runtime.
For the initial version, we expect the earliest adopters to be technical creators, studios, and teams building more ambitious interactive experiences. However, the goal is to reduce the backend burden as much as possible:

  • One-click deploy templates

  • Add your own API key

  • Get a backend URL

  • Configure that URL in the scene SDK

  • Run example scenes as starting points

So yes, this adds one extra setup step. But it unlocks a category of runtime behavior that is not available in the standard static deployment model.
Over time, this could also evolve into a provider model in which third-party hosts offer the orchestrator as a usage-based service. But for this grant, we think the right starting point is open-source, self-deployable infrastructure where creators own their keys, costs, and behavior.

Q3: Scene Lifecycle
Yes, but this is a general DCL constraint, not an AI-specific one. Any scene code change requires redeployment, whether adding a new AI tool/action or adding a new object.
In our system, AI actions and configuration live in the scene, so new capabilities must be defined at deployment time and require redeploying the scene.
The documentation will make this constraint explicit so creators understand that the AI can only invoke the capabilities that the scene has exposed. The intended pattern is for creators to define reusable scene-side actions upfront, such as spawning entities, changing lighting, narrating, updating quest state, or triggering events, and then let the orchestrator decide when and how to use those available capabilities at runtime.

Q4: Long-Term Sustainability
If the orchestrator is offline, the scene should not break. The dcl-ai-sdk can fail silently or return a controlled error when AI calls are unavailable.
Since the LLM’s role is to decide and trigger tools, an offline orchestrator simply means AI behavior stops working. The rest of the DCL scene continues running normally.
The graceful degradation model is: no backend, no AI behavior, but the scene remains usable.
Our documentation will make this explicit and recommend fallback behavior for AI-enabled interactions, such as timeout handling, fallback NPC messages, disabling AI-specific UI when unavailable, or falling back to simple scripted behavior when appropriate.

Q5: Open-Source Maintenance
Our SDK is designed to keep the core orchestrator mostly independent from the Decentraland SDK7. The orchestrator receives structured requests, routes them to an LLM provider, and returns structured tool invocations. That layer should not break simply because a scene upgrades or uses a different DCL SDK version.
The example scenes may need maintenance, since they are tied to specific DCL SDK versions. We can commit to keeping the examples updated and clearly documenting compatibility, for example, with separate folders like sdk7 and future sdkN examples.
After the grant period, the codebase will remain open source, and CoBuilders intends to maintain the core orchestrator, fix critical bugs, and keep integration examples usable for creators adopting the system.

CoBuilders Team

7

ORACLE — Final Recommendation

ORACLE — Final Grant Evaluation

Public Statement

CoBuilders brings strong technical credentials and proposes a well-architected AI orchestration system. However, the design requires every adopting creator to operate a persistent Node.js backend with API keys, LLM billing, and ongoing maintenance. This creates structural friction with Decentraland’s core deployment model (deploy to Catalyst, no servers, no ongoing costs) and fragments the creator ecosystem into scenes-with-servers versus scenes-without. The long-term sustainability concerns around maintaining external APIs for every scene and the philosophy that AI integration should remain composable and creator-controlled rather than centralized infrastructure lead to this decision. Not approved.
Decision Not Approved
Amount granted $0

— ORACLE