How to Build a Complete Game with Unity AI and Bezi: A Practical Workflow

Why Combine Two AI Tools Instead of Picking One?

Since Unity AI moved into open beta in May 2026 as part of Unity 6.2, every Unity developer has had a native, in-editor AI assistant to work with. Around the same time, third-party tools like Bezi have carved out a different niche: a project-aware coding agent that lives inside the editor and specializes in generating, modifying, and debugging your actual C# codebase. The two aren't competitors so much as they cover different parts of the same workflow — and understanding where each one is strongest is what actually determines whether "AI-assisted development" saves you time or just adds another tool to babysit.

This post walks through a practical way to sequence the two: where to use Unity's native assistant, where a specialized project-aware agent like Bezi earns its keep, what it actually costs to run both, and where the whole approach still falls short of the marketing around it.

What's Actually Different Between Unity AI and Bezi?

Unity AI is Unity Technologies' own in-editor assistant, built into Unity 6.2 and beyond. It understands your project's scene graph, GameObjects, components, and packages, and can generate C# scripts, build out scenes from reference images, create placeholder assets, and suggest performance optimizations. It's powered by third-party frontier models (Gemini among them), and its AI Gateway lets you bring your own model — Claude, GPT, or others — without spending Unity's own credits on those requests. Unity AI also ships an official MCP server, which matters if you're already using MCP-based tooling elsewhere in your pipeline. It replaces Unity Muse, which is now deprecated.

Bezi is a separate, third-party product that also lives inside the Unity Editor, but it's built specifically around indexing and modifying an existing project rather than generating new visual content from scratch. It real-time indexes your scripts, assets, scenes, packages, and even local docs like your GDD, and offers two modes: Ask Mode, where it answers questions and proposes changes for you to apply manually, and Agent Mode, where it auto-implements changes directly. Under the hood, Bezi's Agent Mode generates TypeScript that runs in a sandboxed environment, produces validated JSON actions, and applies those actions to your project — with every change reviewable as a diff and checkpointed so a bad suggestion is one click to undo.

In short: Unity AI is better at "generate me a scene and some placeholder assets from this reference image." Bezi is better at "here's my existing player controller, add a dash ability that respects my existing input system and doesn't break the animation state machine." One leans toward content generation from a blank slate; the other leans toward understanding and extending something that already exists.

There's also a practical, structural difference worth knowing before you commit to either: Unity AI is built into the engine itself, so it inherits whatever Unity version policy applies to your project. Bezi runs as an editor plugin on top, which means its update cadence and feature rollout is decoupled from Unity's own release schedule — useful if you want faster iteration on the coding-agent side, but it also means the two products can drift out of sync in how they represent the same underlying project.

What Pricing and Team Plans Actually Look Like

Neither of these tools is free to run past an initial trial, and the cost structure matters for planning a real project rather than a weekend experiment. Unity AI gives personal users a 14-day free trial with 1,000 AI credits, then runs $10/month for another 1,000 credits after that. Pro, Enterprise, and Industry seats include credits and MCP Server access by default, which is worth factoring in if you're already paying for one of those tiers for other reasons.

Bezi runs its own separate, proprietary credit-based billing on top of whatever AI subscription you're otherwise using, in the $20–$200/month range depending on usage. For teams, Bezi also offers a Team Plan: three seats, a shared pool of 5,000 credits, and team-management features, including Shared Pages with real-time collaboration — multiple people can see each other's cursors and watch edits merge as they're typed, which matters more than it sounds like it should once more than one person is prompting the same agent against the same project.

The practical takeaway: budget for both a Unity AI subscription and a separate Bezi subscription if you want the full workflow described in this post, not just one or the other. For a solo hobby project, the free trials are enough to evaluate the workflow shape below without spending anything; for a real production, plan on both running concurrently as a recurring cost, not a one-time purchase.

Connecting External Coding Agents via MCP

Both products intersect with the Model Context Protocol (MCP), but in different ways, and it's worth being precise about which is which. Unity's own official MCP server ships with Unity AI and is included by default on Pro, Enterprise, and Industry seats. Separately, the broader Unity MCP ecosystem — including third-party implementations — exposes the Unity scene graph to external coding agents running in IDEs like Cursor, Claude Code, Antigravity, and Windsurf, so you're not limited to prompting from inside the Unity Editor window itself if your team already lives in one of those tools. Using the MCP server does not consume Unity AI credits, since it's a separate access path rather than a generation request, though it strictly requires Unity 6.0 or newer.

This matters for the workflow in this post because it means you don't have to choose between "prompt Bezi inside Unity" and "prompt Claude Code or Cursor from your normal terminal-based workflow." If your team already has strong habits built around an external IDE-based agent, MCP is the bridge that lets that agent see the same scene graph, GameObjects, and components that Unity AI and Bezi see natively, without forcing everyone to relocate their entire workflow into the Unity Editor's own AI panel.

Setting Up a Project So AI Tools Are Actually Useful

Neither tool does its best work in a messy project. Before bringing either one into a real project, a few habits pay off disproportionately:

• Commit before you prompt. Both tools apply changes directly to your project files. Make sure version control is set up and you've committed a clean baseline before your first Agent Mode session, so "undo" is never your only safety net.
• Write a short design doc. Bezi explicitly indexes local documentation alongside your code. A one-page GDD with your core mechanics, naming conventions, and architecture decisions gives the agent real context instead of forcing it to guess your intent from code alone.
• Keep your naming and folder structure consistent. Both native and third-party AI tools lean on pattern-matching across your project. A consistent structure (one folder per system, consistent script naming) measurably improves how relevant generated suggestions are.
• Decide your review discipline up front. Agent Mode auto-applies changes; Ask Mode doesn't. Pick which one you default to based on how much you trust a first-draft script to land in your codebase unreviewed — for anything touching core gameplay systems, Ask Mode or a mandatory diff review is the safer default.
• Confirm your Unity version up front. Unity AI requires Unity 6.2 or newer, and MCP access strictly requires 6.0 or newer. If you're maintaining an older project, factor an engine upgrade into the plan before you budget time for an AI-assisted workflow — there's no version of either tool that works around this.

Step 1: Blocking Out the Prototype with Unity AI

The fastest way to go from an empty scene to something you can actually walk around in is to lean on Unity AI's scene generation and placeholder-asset features early, before any gameplay code exists. Feed it a reference image or a written description of the space you want — a corridor, an arena, a small town square — and let it build out a rough version populated with placeholder geometry and materials. The goal at this stage isn't final art; it's something in-engine you can block gameplay against instead of iterating purely on paper.

Treat the first pass as disposable. The value of scene-from-image generation isn't that the output is final — it's that "roughly right, in-engine, in minutes" beats "exactly right, on paper, in a day" for the purpose of testing whether a layout actually plays the way you imagined. Expect to regenerate or manually adjust proportions, sightlines, and navigation once you can actually walk through the space; that's the point of blocking out early rather than trying to nail it on the first attempt.

This is also the point to use Unity AI's performance suggestions as a sanity check, not a final pass — run it early so you catch obviously expensive placeholder setups (unbatched draw calls, oversized textures) before you build gameplay systems on top of a scene that's already fighting your frame budget. Catching an unbatched, oversized placeholder set now costs you a regeneration; catching it after three more systems are built on top of it costs you a much larger refactor.

Step 2: Wiring Up Gameplay Logic with Bezi's Agent Mode

Once you have a space to move through, the next problem is almost always the same one: a player controller, some interaction logic, and the connective tissue between systems. This is where Bezi's project-aware indexing earns its keep — because it's read your existing scripts and assets, a prompt like "add a dash ability to the player controller that respects the existing input system and doesn't interrupt the current animation state" produces something that at least attempts to match your existing patterns, rather than a generic script that assumes a project structure you don't have.

A simple illustrative example of the kind of script this step produces — not a literal AI output, just a representative shape for a dash ability layered onto an existing controller:

public class PlayerDash : MonoBehaviour
{
    [SerializeField] private float dashSpeed = 18f;
    [SerializeField] private float dashDuration = 0.18f;
    [SerializeField] private float dashCooldown = 0.6f;

    private CharacterController controller;
    private Vector3 dashDirection;
    private float dashTimer;
    private float cooldownTimer;

    void Awake() => controller = GetComponent();

    void Update()
    {
        cooldownTimer -= Time.deltaTime;

        if (dashTimer > 0f)
        {
            controller.Move(dashDirection * dashSpeed * Time.deltaTime);
            dashTimer -= Time.deltaTime;
            return; // dashing overrides normal movement this frame
        }

        if (Input.GetButtonDown("Dash") && cooldownTimer <= 0f)
        {
            dashDirection = transform.forward;
            dashTimer = dashDuration;
            cooldownTimer = dashCooldown;
        }
    }
}

The point of running this through Agent Mode rather than writing it by hand isn't that the script is hard to write — it's the second and third iteration, where the agent already knows your input system is the legacy Input Manager, not the new Input System, and that your animation state machine has a specific transition it needs to trigger. That project-specific context is what a generic code-generation prompt can't give you.

The same pattern applies once you move past movement into interaction logic. A follow-up prompt like "add a pickup interaction to collectible objects that raises an event my scoring system already listens for" is a reasonable next step once the dash ability is in and tested — a representative shape for that kind of script:

public class Collectible : MonoBehaviour
{
    public static event System.Action OnCollected;

    [SerializeField] private int scoreValue = 10;

    void OnTriggerEnter(Collider other)
    {
        if (!other.CompareTag("Player")) return;

        OnCollected?.Invoke(scoreValue);
        gameObject.SetActive(false);
    }
}

Notice the pattern in both examples: a static event rather than a direct reference to a scoring manager. A project-aware agent that's already indexed your scoring system's listener pattern should follow that same convention automatically, rather than inventing a new coupling style that doesn't match the rest of your codebase — that consistency is the actual time saved, more than the raw act of typing the script.

Step 3: Reviewing Diffs Instead of Trusting Blindly

Agent Mode auto-deploys its suggested actions directly into your Unity project so you can test them in Play mode immediately, then decide whether to keep or undo them. That workflow is genuinely fast, but the speed is exactly why the diff-review habit matters more here than in almost any other coding-assistant context. Get in the habit of:

• Reading the diff before pressing Play, not after — catching an obviously wrong change in the diff is faster than debugging its symptoms in-game.
• Testing the specific behavior you asked for, not just "does the game still run." A dash ability that doesn't crash anything but breaks your jump buffering is a regression you won't see from the console.
• Using the checkpoint/undo system liberally. Reverting a bad Agent Mode change and re-prompting with more context is almost always faster than trying to manually patch a generated script that's headed in the wrong direction.
• Watching for silent scope creep. An agent asked to "add a dash ability" that also quietly refactors an unrelated movement script is a diff worth rejecting and re-prompting more narrowly, even if the refactor looks reasonable on its own.

Step 4: Closing the Loop with Performance and Polish

Once the core loop is playable, run Unity AI's performance-suggestion pass again against the fuller project — the placeholder-stage pass and the pre-ship pass will surface different problems, since gameplay code and additional assets change your actual runtime profile. This is also a reasonable point to use the AI Gateway if you want a second opinion from a different model on a specific tricky script, without burning Unity's own credits on a request that's really a code-review task rather than a generation task.

This is also the point in a project where credit budgets start to matter in practice rather than in the abstract. Blockout and early prototyping tend to be generation-heavy (scenes, placeholder assets) and land more on the Unity AI side of your credit pool; the scripting and debugging loop in the middle of a project tends to be iteration-heavy and lands more on Bezi's side. Tracking which phase you're in helps you predict whether a given month's usage is going to land near the low end or high end of that $20–$200 Bezi range.

A Realistic End-to-End Example

To make this less abstract, here's how the four steps above would actually play out for something small — a single-room collectible prototype, the kind of scope you'd reasonably finish in a weekend:

• Blockout (Unity AI, ~15–30 minutes): describe or reference-image a single interior room, generate placeholder geometry and lighting, run an early performance check, and adjust proportions until it's walkable and reads clearly.
• Core movement (Bezi, Agent Mode, ~30 minutes): prompt for a basic character controller and camera rig matching your project's existing input setup if one exists, or a clean default if this is a fresh project; test in Play mode; keep or undo.
• Collectibles and scoring (Bezi, Agent Mode, ~30–45 minutes): add the collectible/event pattern shown above, then a simple scoring UI listener; review each diff before testing, since this is the step most likely to introduce an unwanted coupling between systems.
• Polish pass (Unity AI, ~15 minutes): a second performance-suggestion run against the now-fuller scene, plus any placeholder-asset swaps you want before calling it done.

None of that removes the need to actually design the room, tune how the dash feels, or decide what makes the collectible loop satisfying — it compresses the mechanical setup time around those decisions, which is a meaningfully different claim than "the AI built my game."

Where This Workflow Falls Short

It's worth being honest about the limits here, because the marketing around AI game-development tools tends to outrun the reality. Neither tool understands your game's design intent the way you do — they pattern-match against your code and assets, which means they can confidently produce a script that compiles cleanly and does something subtly different from what you meant. Complex, interconnected systems (a save/load architecture, a networked multiplayer state sync) are exactly where "auto-implement" is the wrong default; that's Ask Mode territory, reviewed line by line.

Cost is a real constraint too, not just a footnote: running both tools concurrently on a real production is a recurring monthly cost on top of your engine and any underlying model subscription, and it's worth tracking actual credit usage against actual time saved rather than assuming the workflow pays for itself by default. Version requirements are another practical wall — Unity AI needs 6.2+, MCP access needs 6.0+, and a project stuck on an older LTS branch for good reasons won't get access to any of this until that's resolved first.

And both products are evolving quickly in 2026 — Unity AI is explicitly in open beta, and third-party agents like Bezi are iterating fast enough that specific UI details, pricing, and even credit allotments in this post may shift under you. Treat this as a workflow shape and a set of trade-offs, not a fixed set of menu paths or prices.

Is This Workflow Worth Adopting?

For a solo developer or a small team, the realistic gain isn't "the AI makes my game for me" — it's compressing the boring 80% (blockout scenes, first-draft scripts that follow your existing patterns, routine performance passes) so more of your actual time goes to the 20% that needs real design judgment. If that's the trade you're looking to make, pairing Unity's native AI Gateway flexibility with a project-aware agent like Bezi for the code side is a reasonable way to structure the workflow today, and the 14-day Unity AI trial plus Bezi's entry tier are cheap enough to validate that before committing to a subscription.

For a small studio rather than a solo developer, Bezi's Team Plan (three seats, a shared 5,000-credit pool, real-time Shared Pages) is the more relevant reference point than the personal tier — the collaboration features matter once more than one person is prompting against the same project, and the credit pool needs planning the same way any shared infrastructure cost does. If you're working on a large, highly interconnected codebase with a team that already has strong review discipline, the calculus shifts further still — the tools are additive there too, but the review overhead matters more relative to the time saved, and MCP-based access from whatever IDE your team already standardizes on may be a better fit than adding another in-editor panel to everyone's workflow.

Common Questions About This Workflow

Do I need both tools, or can I get by with just one? If your project is mostly about generating content quickly — blockouts, placeholder assets, iterating on a level's layout — Unity AI alone covers most of that. If your project is mostly about extending and debugging an existing, non-trivial codebase, a project-aware agent like Bezi carries more of the load on its own. The combined workflow in this post is aimed at the middle case: a real prototype that needs both a space to exist in and gameplay systems wired into it, which is most small projects.

Does using an external IDE agent through MCP replace Bezi? Not directly. MCP gives an external agent (running in Cursor, Claude Code, Antigravity, or Windsurf, for example) visibility into the Unity scene graph, but it doesn't automatically give that agent Bezi's specific indexing of your project's conventions, GDD, and prior change history the way Bezi's own Agent Mode does. They can coexist — use MCP-based access for team members who prefer their existing IDE, and Bezi's in-editor Agent Mode for the deeper, project-specific iteration loop.

Is it safe to let Agent Mode touch a shared team codebase? Only with the same discipline you'd apply to any teammate's unreviewed pull request: commit before prompting, review every diff, and don't grant Agent Mode free rein over systems with high blast radius (save data, networking, monetization) without a human reading the change first. The checkpoint/undo system reduces the cost of a mistake; it doesn't eliminate the need to catch it.

Does this workflow only apply to Unity, or does it generalize to other engines? The specific tools in this post are Unity-specific — Bezi runs as a Unity Editor plugin, and Unity AI is obviously built into Unity itself. The underlying shape of the workflow (use a content-generation tool for blockout, a project-aware coding agent for logic that has to match existing conventions, and keep a human reviewing every non-trivial diff) generalizes reasonably well to other engines as their own AI tooling matures, but the concrete credit costs, version requirements, and MCP details covered here are specific to Unity's 2026 tooling landscape and won't carry over one-to-one.

References & Further Reading

• Unity AI: AI Game Development Tools & RT3D Software (Unity) — official product page.
• Bezi — Unity AI Assistant — official product page.
• Bezi Documentation: Agent Mode — how Agent Mode's sandboxed action pipeline works.
• Bezi: Introducing Actions — technical detail on how Bezi applies changes inside the editor.
• Bezi Pricing — current plans, credits, and Team Plan details.
• Bezi for Game Studios — team collaboration features.