3D agent
A 3D agent is defined by what it can see and touch
Every 3D tool now has a chat box. Very few of them have an agent. The difference is not the model behind it, it is whether the thing can read the live scene, act on it, look at what changed, and correct itself without a human relaying the state back and forth.
Mixar is a 3D editor built on Blender with an agent of that third kind running inside it — the Blender toolset, shortcuts and .blend files unchanged, on Windows, macOS and Linux. Here is the kind of instruction that distinction makes possible.
The definition
Three levels that all get called an agent
Level one is a code generator. You describe what you want, it writes a script, you paste the script into your application and run it. Useful, and about as much an agent as a search engine is: it never sees the scene, never sees the result, and cannot tell you that it failed.
Level two is a bridge. An external client drives the application through a protocol — the open-source blender-mcp project is the reference implementation for Blender, and a good one. This is a real step up because the model can now query and act. The constraint is architectural: it sees only what the protocol chooses to expose, every operation is a round trip, and long chains get slow and can time out mid-sequence.
Level three runs inside the application against live state. It reads the scene graph directly, performs operations, inspects the result and adjusts. There is no serialisation boundary to design around and no round trip to pay for, so a fifty-step pass is not fifty times more fragile than a one-step pass.
Why it matters
Scene state is the whole argument
Ask any of the three to clean up a scene and the difference shows immediately. The code generator writes a plausible cleanup script for a scene it has never seen, and it will happily merge vertices by distance on a mesh where that destroys a deliberate detail.
An agent with scene access starts by looking: how many objects, how many are meshes, which have unapplied scale, which have loose geometry, which have flipped normals, which already have UVs, which share materials. Then it proposes a pass shaped by what is actually there, runs it, and checks the counts moved the way it predicted.
That inspect-act-verify loop is not a refinement of the script-writing approach. It is the thing that makes multi-step work survive contact with a file somebody else made.
How to judge one
Five questions worth asking before you trust it
Does it read the scene before acting, and can it tell you what it found? An agent that cannot describe your scene back to you is not reading it.
Does it stop for approval on destructive work? Anything that renames forty objects or merges geometry should be able to draft a plan and wait. If approval is a prompt convention rather than a feature, it will be skipped exactly when it matters.
Does it verify its own output? Acting and checking are different capabilities, and an agent that only acts will report success on a pass that silently did nothing.
Is its tool surface scoped? One flat list makes every decision harder for the model, and the list always grows. Mixar routes work across twenty-one specialist agents, each seeing only the domains its job needs, out of roughly 116 tools across twenty domains: a UV task never has to reason past a rigging tool. That is an architectural difference, not a detail.
What happens when it fails? The useful answer is a specific error tied to a specific object. The unhelpful one is a confident summary of work that did not happen.
The three levels, side by side
| Code generator | Protocol bridge | In-application agent | |
|---|---|---|---|
| Reads live scene state | No | Through the protocol | Directly |
| Runs the operation | You do | Yes, per round trip | Yes, in process |
| Sees its own result | No | Yes, at a cost | Yes |
| Cost of a long chain | Your time | Latency and timeouts | Low |
| Fails visibly | Only when you run it | Usually | Yes, tied to the object |
| Setup | None | Add-on, server, client | Built in |
The honest version
What no 3D agent does well yet
Aesthetic judgement
An agent will follow a stated rule accurately and consistently. It will not tell you the silhouette is boring, that the composition needs the camera moved, or that the wear pattern makes no sense for how the object would be used.
Deformation topology
Retopology guided by curvature is not the same as edge loops placed for a shoulder. On anything heading into a rig, an agent gets you a better automatic result faster and still hands the hero pass back.
Knowing your project
Naming conventions, density budgets, material libraries and what counts as done are studio facts. An agent applies them once told, and invents something plausible when not, which is worse than asking.
Where this gets concrete
Frequently asked questions
What is a 3D agent?
A 3D agent is a system that operates a 3D application on your behalf: it reads the scene, performs operations in it, checks the result and adjusts. That is distinct from a chat assistant that writes a script for you to paste in, because the agent has the scene state and can tell whether what it did worked. The practical test is whether it can describe your actual scene back to you before it changes anything.
How is a 3D agent different from a text-to-3D generator?
A generator produces an asset from a description. An agent operates on assets that already exist: cleaning, retopologising, unwrapping, baking, renaming, laying out and exporting. They solve opposite ends of the pipeline. Most of the scheduled hours in a 3D project sit at the agent's end, which is why it is the more interesting of the two for anyone shipping work rather than posting renders.
Is a 3D agent safe to run on a production file?
It depends entirely on whether approval is a feature. Look for a mode that drafts the full sequence and waits for you to accept it before anything executes, and prefer working on a copy the first few times regardless. Destructive passes such as merge-by-distance, normal recalculation and bulk renaming are hard to undo selectively, so the approval step matters most exactly where automation saves the most time.
Do I need to know how to script to use one?
No, and that is somewhat the point. The instruction is a brief in plain language, the same way you would brief a junior technical artist: what to do, to which objects, to what standard. Knowing what you are asking for still matters, because an agent will carry out a badly specified pass just as accurately as a well specified one.
Try it on a scene you already have
Mixar is a Blender-based editor with the agent running inside it rather than bridged to it. Windows, macOS and Linux, and your existing shortcuts and muscle memory come with you.