Built for where Unity is going

How the ArTchie suite lines up with Unity's own direction — AI-native editors, agent tooling, Package Manager delivery, the CoreCLR runtime move, and the ECS unification. Every claim below points at something the code does today; the last section says plainly what is positioned rather than shipped.

1. Unity's AI direction — we run on Unity's own rails, not beside them

• Unity AI Assistant tools, registered the Unity way. Every ArTchie intelligence tool (Atlas Search / Trace / Snippet / Architecture / DeadMethods, BedderScript CensusCompact / ValidateJson, Anvil AgentProjectDump, Rivet SceneQuery) is a [AgentTool] — the Assistant's own extension point. Unity's Assistant can call them natively; nothing is bolted on.
• One executor, Unity's executor. External callers and the in-editor chat run Unity's AgentTools through FunctionToolbox.RunToolByIDAsync with ToolExecutionContextFactory — the same path Unity's own MCP module (Unity.AI.MCP.Editor) uses. Unity's scene, console, play-mode, capture and AssetGeneration tools (36 generative models at last count) run on the same pipe as ours, under the same approve-mode gate.
• MCP, both ways. The suite registers artchie_manifest / artchie_tool as MCP for Unity custom tools, so any agent seat (Claude Code, Grok Build, Codex) gets the ArTchie tools with no setup — and a Grok Build seat was added to the MCP for Unity client list. Unity deprecated its own in-Editor MCP server on 2026-08-24 in favour of unity mcp in the Unity CLI; third-party MCP packages like this one are explicitly unaffected, and the path stays live.
• On Unity's CLI, the same two doors. The same artchie_manifest / artchie_tool are also [CliCommand]s on Unity's Pipeline package (com.unity.pipeline), the extension point behind the new Unity CLI. One registration reaches three places: a human in a terminal (unity command artchie_tool --id ArTchie.Atlas.Search --args '{"query":"…"}'), every client the CLI configures (unity mcp configure lists 16, including claude-code, codex and openclaw), and a running Player (--runtime). Both doors go through the same approve-mode gate as the chat chips — Allow runs, Deny refuses, Ask returns needs-approval and nothing runs. The bridge compiles only when the Pipeline package is present. Verified 2026-08-24 on Unity CLI 1.0.0-beta.6 with Pipeline 0.5.0-exp.1: 142 Unity built-ins plus the two ArTchie commands, listed and executed over both unity command and the unity mcp stdio server.
• Headless and CLI-friendly by design. Every scanner has a batch entry point (RunBatch, ScanProject, ToJson, WriteReport are the untouchable CLI surface); the artchie CLI talks MCP over loopback; reports are written for machines first (JSON) and rendered for humans second.
• The in-editor copilot is provider-switchable. Unity Assistant, Claude Code, Grok Build — chosen in a dropdown, never re-coded; no API keys are ever pasted (signed-in CLIs only).

2. Package Manager delivery — the dev tree is the ship tree

• Every kit is a real UPM package (package.json, semantic versions, CHANGELOG.md generated from git history, LICENSE.md, visible Documentation/), delivered today as a hybrid .unitypackage that installs straight into Packages/, and publishable as-is the day paid UPM opens on the Asset Store. com.artchie.core is free and dependency-free; kits declare it.
• Unity 6.0 LTS floor, URP + Input System only. Exported from the oldest supported editor; verified on the newer rigs.

3. ECS for All — positioned for the flip, honestly

Unity's stated path is incremental unification: ECS components on GameObjects, one 64-bit ID space for objects and entities, a hierarchy where both live together. The suite already fits that shape:

• The scripting model is orchestration over host systems. BedderScript scripts own data and rules; heavy loops are host builtins (voxel_mesh turned a 126 ms pure-script mesher into an 11 ms host call). DOTS changes what those host builtins are made of — Jobs/Burst/entities — not the language or the tools above it.
• Handles, not raw IDs. Scripts address the world through opaque handles (go), and the kits already survived the EntityId transition (Unity 6.5's GetInstanceID purge caught in the verify matrix and fixed at the cache layer). When IDs unify, handles become entity-capable without a language change.
• Atlas indexes ECS code as code today (systems, components, bakers are C# symbols).

What is positioned, not yet shipped: DOTS-aware graph edges in Atlas (system ↔ component read/write), Anvil scanners for Bakers/Burst/subscenes, and an [entities] builtin category with a Baker for the script runner so scripts survive subscene baking. Those are the next stakes, in that order, when the unification APIs land on the LTS.

4. The CoreCLR cutover — logic in Bedder doesn't care which runtime ships

Unity's stated path replaces Mono with CoreCLR: Unity 6.7 LTS offers an experimental CoreCLR desktop player alongside Mono, and the release that follows drops Mono entirely, moving to a .NET 10 toolchain and BCL as the only exposed target framework. That is a runtime change of the kind that historically forces every C#-scripted asset through a port — dropped .NET 4.7 APIs, an obsolete BinaryFormatter, discouraged AppDomain assembly enumeration, a different garbage collector, and changed static-initialization order.

• BedderScript is not .NET. A .bedder file is never compiled to IL and never touches the CLR. It is parsed and executed by a virtual machine that ships in com.bedder.script, and the language's semantics are defined by that VM and its census contract — not by the runtime underneath it. A runtime swap moves the floor under the interpreter; it does not move the language.
• So scripts cross the cutover unchanged. The Voxel Garden sample is 1,180 lines of .bedder over 18 builtins. Nothing in it references a BCL type, an assembly, a System.* API, or a framework version. The same file that runs on Mono today runs on CoreCLR with no edit, no recompile, and no reimport — because there was never a compile step tying it to the runtime.
• The VM itself is portable by construction. com.bedder.script 0.4.0 contains no Reflection.Emit, no unsafe, no stackalloc, and no Activator.CreateInstance anywhere in its runtime — the four things that most often block a managed-runtime move and the AOT path. Interpretation is plain, verifiable, managed C#, which is why the VM ports rather than gets rewritten.
• The host is the compatibility surface. Scripts reach the engine only through host builtins. When a BCL API is dropped or an engine call changes shape, the host absorbs it behind the same builtin name and the census contract holds — so the change stops at the boundary instead of reaching every script a user wrote.
• The claim is auditable, not rhetorical. The census (CensusCompact) and bs-contract version are machine-readable statements of exactly what the language exposes. Diff the census across runtimes and the surface is either identical or it isn't; nobody has to take our word for it.

What this is not: it is not a compatibility shim for existing C#. BedderScript does not execute C#, and the suite does not claim to run unmodified Mono assemblies on CoreCLR. Porting existing C# into .bedder is a real conversion with a real cost — the CsToBedder converter does the mechanical pass and reports what it could not translate, and the remainder is hand work. The guarantee here is forward-looking and specific: logic already expressed in .bedder does not need porting across a runtime change, this one or the next.

5. Store-listing blurb (copy as-is)

Built for where Unity is going. ArTchie tools are AI-native by construction: every tool is a Unity AI Assistant [AgentTool], exposed over MCP, with batch/CLI entry points and machine-readable reports — so Unity's Assistant, Claude, Grok, or your own agents drive them. Delivered as real UPM packages (Unity 6.0 LTS, URP, Input System), versioned and changelogged. Architected as orchestration over host systems, ready for the GameObject/ECS unification. Scripting logic written in BedderScript is runtime-independent: it does not compile to IL, so it carries across the Mono-to-CoreCLR cutover without a port.