There’s a moment in almost every AI implementation project when you ask the model to do something that seems obvious – and it confidently does exactly the wrong thing.
That moment arrived during a Levi9 project for a furniture retail client, when a sofa ended up on top of another sofa. The model had been asked to figure out where the furniture should go in a room. It tried. It failed. Repeatedly.
The breakthrough didn’t come from a better model. It came from stopping to ask: what are we actually asking AI to be good at?
The problem with asking AI to be a calculator
The idea was compelling: a customer describes their room, the AI agent browses the product catalog, picks furniture that fits their style and budget, and generates a layout – complete with a 3D render they can explore. What sounds like a natural fit for an AI agent contained a hidden trap.
Getting furniture to fit in a room without overlapping or blocking doorways requires precise spatial reasoning: coordinates, dimensions, collision detection, rotation. Language models don’t do this reliably. Even Claude Opus needed a minimum of 17 tool-chain iterations to arrive at something usable when asked to handle spatial math directly. The cost per room design request hit three dollars. Sonnet couldn’t complete the task at all.
The instinct to push harder and prompt more carefully was understandable. It was also the wrong instinct.
Giving AI the right job
The core decision that made the project work was a clean split in responsibilities between the AI agent and a deterministic Layout Engine.
The AI agent was no longer asked to think in coordinates. Instead, it was asked to think like a designer. Given a room, a budget, and a style preference, the model selects furniture that fits the brief and describes its vision using a vocabulary of spatial intents rather than numerical positions.
Instead of outputting “place sofa at X: 240, Y: 180, rotation: 90°,” the model says: sofa, north wall, centered, facing south. That description gets handed off to the Layout Engine, which translates intent into valid, collision-free geometry. The model never sees raw coordinates. The math stays entirely outside the model’s context.
This isn’t a workaround – it’s an architectural principle. AI models are excellent at preference, style, and creative decision-making. They are unreliable at deterministic spatial computation. Building a system that respects this boundary makes both sides stronger.
How the system works
The agentic loop draws on eight MCP tools, with a typical request flowing through four. The first initializes the spatial brief – room dimensions, doors, windows, zones the model must work around. The second queries the product catalog with enriched descriptions, because a model that only knows “sofa 3×2” can’t reason about whether it fits a Scandinavian living room concept. The third tool is where most of the work happens: the model generates a layout plan using intents, the engine validates it, and if something doesn’t fit, the model receives a plain-language explanation of what failed and tries again. The fourth exports the verified layout as JSON for the Three.js renderer, with furniture scaled to actual product dimensions.
When a piece of furniture can’t be placed cleanly, the engine first tries to nudge it – shifting in small increments within a tolerance band, the way you’d wiggle a couch into a tight corner. Only if that fails does the model get involved, deciding whether to try an alternative product or adjust the arrangement.
Before and after
The difference between the first prototype and the current version is hard to overstate.
Version one, running on Opus with coordinates in the model’s context: 350,000 tokens per request, 17+ iterations to reach a usable layout, $3.00 per generation. The current version, running on Sonnet 4 with the responsibility split in place: around 60,000 tokens per request, five to eight tool-chain calls on average, $0.20 per generation.
The token reduction came mostly from keeping the model’s context clean. Once coordinate data stopped leaking into the agent’s history, Sonnet could handle the task Opus had struggled with. This revealed something worth understanding: the earlier system hadn’t actually been working as designed. Opus was succeeding because it was smart enough to compensate for the leaking coordinates on its own. When Sonnet replaced it, the compensation disappeared and the system broke – exposing a flaw that had been quietly masked all along.
When a piece of furniture can’t be placed cleanly, the engine first tries to nudge it – shifting in small increments within a tolerance band, the way you’d wiggle a couch into a tight corner. Only if that fails does the model get involved, deciding whether to try an alternative product or adjust the arrangement.
Lessons that travel
A few things from this project apply broadly to anyone building agentic AI systems.
Don’t ask a language model to be a calculator. If your system requires numerical precision – coordinates, collision detection, scheduling constraints – put that logic in deterministic code and give the model a language interface to it. The model gives you intent; the engine gives you math.
Keep model context clean. Every token of coordinate data or raw JSON that leaks into the agent’s working memory is a liability. The model will try to reason about it, produce errors that are hard to diagnose, and mask the problem just enough to make it invisible until you switch models.
Natural language is the best format for feedback loops. When a placement fails, the engine tells the model what went wrong using structured JSON with human-readable reason strings – “blocked by door on the south wall,” not raw coordinate dumps or opaque numeric error codes. The structure keeps the response parseable, the language keeps it useful to a model that reasons in words.
The prototype proves the concept. The path to production runs through better constraint resolution, a richer intent vocabulary, and tighter pipeline control. But the underlying insight will carry through all of it: the system works because it asks the AI to do what AI is actually good at, and builds deterministic machinery for everything else. That division of labor – intelligence on one side, precision on the other – is the architecture worth keeping.
***This article is part of the AI9 series, where we walk the talk on AI innovation.***
In this article:
Levi9 Serbia
