How Our AI Garden Designer Actually Works — From a Photo to a Buildable 3D Project

We get asked a fair bit how the AI garden designer works — usually by people who have tried other AI design tools and found the same thing every time: a beautiful image, and then nothing. No sizes, no materials, no way to actually build the thing on the screen. So here is the whole pipeline, in the order it runs, including the parts that are still rough.

The unusual part: we run the process backwards

A normal design workflow goes from a plan to a picture. You decide the sizes, you draw it, you render it. An AI image tool skips the plan and gives you only the picture — which is why the picture is never buildable.

We do it in reverse. First we let the model design freely, because that is what it is genuinely good at: composition, proportion, what looks right in a real garden. Only afterwards do we go back into that image and ask the harder question — what is actually in here, how big is it, and can we build it from our parts? Everything after the image is a translation job, not an art job.

Stage 1: a free hand, anchored by real photos

The image model works from a written brief that stays the same for everyone — it describes the material, how the blocks stack, what the connectors do, what a finished GridGarden build looks like. Within that brief the model has a lot of freedom. We want it to have that freedom: a garden design that ignores your slope, your fence and the light in your photo is worthless, however tidy it looks.

What keeps it from drifting into a generic AI raised bed is the reference photos. We keep a library of approved photos of real builds — now around twenty of them, covering the whole catalogue: a close-up of how the blocks are bonded with staggered joints, beds with integrated seating, a free-standing bench, a bench on legs, a narrow balcony, an L-shaped bed, a row of separate beds on gravel, a sandbox, a solid wall, steps with retaining walls on a slope. Each design gets a couple of them: one chosen for the setting in your photo, and the bonding close-up so the wood and the joints come out like ours rather than like generic timber.

The library keeps growing for a specific reason — every gap in it shows up in the pictures. When it had no free-standing bench in it at all, the model kept inventing seating we do not make. And a design with both a bed and seating in it used to reach for the wrong reference and merge the two, until we separated "a bench standing next to a bed" from "a bench built into the bed" and gave each its own example.

Two of the newest references are there purely to fix a look. Freshly milled larch is pale, almost yellow; the same wood after two or three seasons in a garden is silver-grey and softer. The model, left alone, always drew it straight from the sawmill — so we now show it what the wood looks like after a couple of years, because that is the garden you will actually be living with.

This is also the honest answer to "is it just a stock AI image generator?" — no, but not because the model is special. It is because it is shown what our product actually looks like, every single time.

Stage 2: reading our own picture back

Now the interesting bit. The image is just pixels — nothing in it says "this is a 2.4 m bed, two layers high". So a second set of agents goes hunting.

Detection runs more than once, independently, and the results are merged, because a single pass reliably misses things — usually the biggest structure in the frame, oddly enough. Then every candidate goes to a reviewer that gets a cropped close-up of that spot rather than a set of coordinates, because judging "is there really a bench here?" from numbers is guesswork. The reviewer can veto a candidate, but it cannot invent new ones.

Measurement then works the same way: one structure at a time, on its own crop, not on the whole image. Scale comes from counting the visible layers of blocks — every layer is a known height, so counting layers gives a height, and the height gives everything else.

Stage 3: into Studio, as a real project

Once each structure has a type and a size, GridGarden Studio builds it — and this is the part we are most careful about. The scene is not a lookalike model made for the picture. It is built by the same code that runs when you drag things around in the 3D editor yourself, running without a screen. Same blocks, same connectors, same rules about what can sit on what.

That matters for a practical reason: whatever comes out is a project you can open, rotate, change and order. If we had modelled it separately "just for the preview", the preview and the editor would drift apart, and the price would stop matching the thing on screen.

The agents, one by one — and why each one exists

"AI" makes it sound like one clever thing doing everything. It is not. A single design is about twenty separate model calls, and each agent has one narrow job it can be held responsible for. Here is the whole cast, in order.

Agent 1 — the landscape architect who has never heard of us

The first agent knows nothing about our product. Deliberately. It gets your photo and your wishes and answers one question: what would make this particular garden better? Where the seating belongs, where the growing area belongs, how the space divides, what fits the slope and the light. It outputs a plan, not a picture.

We keep it deliberately ignorant of the catalogue because an agent that knows the catalogue designs the catalogue. You would get our products arranged in your garden instead of a design for your garden. The commercial thinking has to come after the design thinking, not before it.

Agent 2 — the translator who writes the brief

The second agent is the one that knows exactly what we sell. It reads the first agent's plan and decides which parts of it are buildable from modular blocks and which are just planting, paving or existing features. Then it writes the actual instruction for the image model, and picks the reference photos — up to two, chosen for the setting, with the bonding close-up as the second.

It also handles a trap that cost us a lot of poor results early on. If you uploaded a photo, Agent 2 writes an editing instruction rather than a generating one, and adds an explicit order to preserve your camera angle, your house, your sky, your existing trees. Without that instruction the image model quietly ignores the uploaded photo and invents a completely different garden — technically pretty, entirely useless to you. There is also an intensity setting: a gentle touch-up, a bold intervention (the default), or a full redesign that uses your photo only for context.

The image model — the only part that actually draws

Everything before this was text. Here the brief, your photo and the chosen references go in, and a picture comes out. It is also by far the most expensive single call in the chain, and the least predictable: when it fails it usually fails by returning no image at all, which we retry, because it is a hiccup on the model's side rather than a rejection of the request.

Agent A — the spotter, run three times at once

Now we go back into our own image. Agent A looks for structures and returns a box around each one. It runs three times in parallel, and the three lists are merged into a union by how much the boxes overlap; anything only one run saw, and only as a stray copy of something the others already found, is dropped.

Why three? Because we measured the failure and it was not incompetence — it was variance. On one customer's photo the first run missed the largest structure in the frame, a nearly two-and-a-half metre screen, and priced a wall standing in the tree canopy instead. The same model, same photo, second run, found the screen and the bench correctly. Running a second and third pass fixes that for a fraction of a cent; a smarter, five times pricier model does not.

This is also the agent that costs the most after the image itself, because it is the one we let "think" before answering — that internal reasoning is roughly 45 % of the price of a whole design.

The reviewer — the one that may object, but may not decide

Every candidate then goes to a reviewer. It does not get coordinates. It gets a cropped close-up of that exact spot, with the area outlined in red, and answers one question: what is actually in this picture? On the photo that started all this, it dismissed three of six candidates with the plainest possible verdicts — "tree trunks and green foliage", "ornamental grasses and lawn", "wooden garden shed". A crop of tree canopy cannot argue its way past that question.

For a while this agent could simply delete a structure, and that turned out to be a mistake we had to measure to see. Over two weeks it threw away 232 structures — 116 beds, 40 walls, 37 benches, 30 planters — and 65 of those had been seen by all three detection passes. One quick look at a tight crop was overruling a unanimous vote. The reason was mundane: the reviewer's brief did not describe our own shapes, so a bench with a gap under the seat and a plank screen were foreign objects to it. It called them "wooden garden bench", "wooden fence" — and dropped them.

So the rule changed, and this is the part we would defend hardest. The reviewer no longer has a single hard power in the whole chain. Its objection is packaged as feedback and handed back to the detector, which runs once more, reads the objection and decides for itself. If the detector still reports the structure after being told "that crop is tree canopy", the structure stays.

That has an admitted price: a phantom the detector genuinely insists on will reach your quote. We chose it anyway, because the opposite error — deleting a real bench that the customer can plainly see in their own picture — is worse. Deciding what is in the image is the detector's job; the reviewer is there to argue, not to rule.

Two smaller powers went the same way. The type of a structure is now settled by a vote among the detection passes rather than by whichever reading drew the bigger rectangle — a detail that matters more than it sounds, because a wall is one surface and a bed is a perimeter, roughly twice the material. And when the reviewer disagrees with the surveyor about the number of layers by two or more, its count is neither ignored nor obeyed: it buys two extra measurement runs, and the median is recalculated from the surveyor's own readings. We measured why: three measurement passes agree with each other 95 % of the time, but an independent count differs by two or more layers in a third of all structures — so the disagreement is a signal worth paying for, not a verdict.

The second chance — our own brief, used carefully

One more agent joined recently, after a case where the picture clearly showed a bench standing on legs, the log said in as many words "asked for a bench, not drawn", and the quote arrived with three beds and no bench at all. The signal existed and died in a log file.

Now, if a type of structure we asked for in the brief is missing from the detected list, the detector gets one more question: is this thing in the picture or not? Its answer goes through the same reviewer as everything else.

The constraints here are deliberately tight, because this is the one place where we could start pricing our own wishes instead of your picture. The brief never inserts anything and never overwrites anything — the instruction says outright that the picture may simply not show it, and that a structure must not be invented because the brief mentioned it. Only missing types are asked about, never counts; if we asked for three beds and found two, the generator probably drew two, and we are not going to draw the third for it. One question per design, no recursion.

Agent B — the surveyor, one structure at a time

Sizes are the other half of the problem, and they were wrong for a subtle reason: the surveyor used to look at the whole photograph at once. On a structure occupying eight per cent of the frame you simply cannot count the individual boards — and counting boards is where every dimension comes from.

So each structure now gets its own call with two pictures: the full photo, so the agent knows where the thing stands and whether it sits higher up a slope, and a tight crop of that one structure for counting layers. The same screen that had been measured at 3.3 m, 5.0 m and 6.7 m across three attempts stopped swinging once it was measured on its own crop.

One rule we hold firmly here: when several readings of the same structure are combined, the middle reading is taken for the structure as a whole, never field by field. Taking the height from one reading, the width from another and the step count from a third builds something no agent ever actually saw.

The builder — no AI at all

The last step in the chain is the least glamorous and the one we trust most, because there is no model in it. Studio's own build code takes the list of structures and their sizes and assembles the scene deterministically: same blocks, same connectors, same rules as when you drag things around in the editor yourself. Same input, same result, every time.

The quote — also no AI at all

Worth saying explicitly, because people assume the opposite: no model is involved in your price. The finished project is broken into parts, the parts get prices for your country, the total is arithmetic, and the email is a template. That whole branch costs us nothing per quote and cannot hallucinate a number.

A side door: other AI assistants can talk to Studio too

One clarification, since the two get confused. Our own designer does not reach Studio through any clever protocol — the two services sit on the same machine and it calls a plain internal route. But Studio does speak MCP (Model Context Protocol), the standard that lets an AI assistant call an external tool directly rather than guessing from what it read on the web. Its own documentation puts it more memorably than we could:

"Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems."
— Model Context Protocol documentation

In practice that means an assistant such as Claude or a coding tool can hand Studio a set of structures and get back a real bill of materials and a real price for a given country — the same computation that runs behind the designer and behind the editor, not a summary of our marketing pages. The reason we built it is the same reason this article is honest about the rounding: an AI that can ask for the actual numbers gives people better answers about us than one that has to infer them.

Stage 4: where the price comes from

The finished 3D project is taken apart into the individual pieces it is made of, and each piece is a real product with a real price for your country. There is no rate per square metre anywhere in the chain — we removed it, because when we compared it against the actual sum of parts it was overcharging by roughly a third.

So the number you see is the parts, added up. If we cannot build something from your design, we would rather show you no price and offer a conversation than invent one.

What we do to keep it faithful

• Reference photos in every design — so the output shows our construction, not a generic wooden box.
• A catalogue vocabulary — the agents are taught the shapes we actually sell (beds, beds with integrated seating, screens, walls, steps, planters, sandboxes), so they map what they see onto real products instead of describing furniture in general.
• Cropped close-ups for both judging and measuring — coordinates lie, pictures do not.
• The editor's own build code — one source of truth for geometry, so the preview, the editor and the parts list cannot disagree.
• Prices from real parts — not an estimate multiplied by area.

And where it is not perfect

We would rather tell you this than have you find it yourself.

Sizes get rounded to the system. Everything is built on a fixed module, so a bench the AI drew as 1.8 m long becomes 2.4 m when it is built, because that is where the real parts land. We tell you when that happens: the quote describes the structure as it was built, not as it was measured on the image. It is the built version you would receive.

Scale rests on counting layers. If a structure sits in the background with its base hidden behind planting, a miscounted layer stretches or shrinks the whole thing. Long, low walls are where this shows the most.

Not every design can be translated. Sometimes the picture contains something lovely that simply is not our system. We say so rather than substituting the nearest thing we sell — and the quote now names what was left out and why. There is a real difference between "we know this shape but could not read its size from the picture, write back and we will work it out" and "this is not something we build", so those get different sentences. Until recently a dropped structure vanished silently: you saw a bench in your picture, it was not in the price, and nothing anywhere told you why.

The 3D looks emptier than the render. The generated image is full of planting, light and life; the 3D project is honest bare timber and soil. Even when the sizes are right, the first reaction is often "this isn't my design" — the difference is the greenery, not the geometry.

Why "good enough" is the right target

None of this is trying to replace a garden architect, and it is not a rendering competition. The job is narrower and much more useful: turn a vague idea about your garden into something with a size, a parts list and a price, in a couple of minutes, for free, before you have spoken to anyone.

Measured against that job, a bench that comes out 2.4 m instead of 1.8 m is not a failure — it is the real answer, because 2.4 m is what actually gets built. And every project lands in the editor, where you can move it, resize it and make it yours. That is the whole point of running the process backwards: you do not end up with a picture, you end up with a plan you can build.

The economics, honestly: this only works because we sell something physical

Every design costs us real money. Not much on its own — a few cents — but it is never one model call. There is the drawing itself, then several independent detection passes over the result, the reviewer that checks each structure on its own crop, a measurement pass per structure, and the build. Roughly nine cents a design, all in, and the ones that fail and get retried cost the same as the ones that work.

The tool is free, needs no account for a first look, and we do not sell your design to anyone. So on its own it is a pure cost line, running every day, with no income attached to it.

What pays for it is on the other side of the process: a garden that actually gets built. A GridGarden project is typically several hundred euros of timber and connectors, so a single built garden covers several thousand free designs. That ratio is the entire business case. It is also why we would rather the tool sends you away with a realistic parts list than keep you clicking — time spent in an app does not pay for the app; a built garden does.

It is worth saying plainly what this means for AI design tools in general. Look at what people actually type into Google when they go looking for one: the words free, gratis and kostenlos are attached to almost every one of those searches. The demand is explicitly for something that costs nothing. A standalone AI garden designer therefore has to charge for precisely the thing its visitors arrived hoping to get for free, while paying model costs on every single generation, including the ones that go nowhere. That is a hard business to run.

With a physical product behind it, the same numbers turn friendly. We can afford to be generous with the tool, to keep improving the parts that are still rough, and to tell you where it is wrong — because we are not trying to monetise the design. We are trying to help you decide whether to build the garden.

Frequently asked questions

Do I need to upload a photo of my garden?

A photo gives much better results, because the design then reacts to your actual space, light and boundaries. You can also describe what you want in words instead. What we cannot do is design from nothing at all — with neither a photo nor a description, there is nothing to work from.

Is the price I get binding?

It is a real calculation from real parts for your country, not a rough guess — but it describes the structures as they were built on the module, and it does not include delivery, which depends on weight and destination and is calculated at checkout.

Can I change the design afterwards?

Yes, and most people should. The project opens in GridGarden Studio, where you can move structures, change sizes and add or remove parts; the parts list and price follow along as you edit.

Why does the 3D project look different from the generated image?

The image is a visualisation with planting and atmosphere; the 3D project shows only what you would actually receive and assemble. The sizes are meant to match — the greenery is not part of the delivery.

Do I need tools or building experience to assemble it?

No sawing, no drilling and no carpentry. The blocks are cut to size and pre-drilled, and they are joined with connectors, which is what makes a complex-looking structure achievable by someone who has never built anything before.

If you want to see it run, the AI garden designer is free to try, and every design it produces can be opened and edited in GridGarden Studio. And whichever route you take, it is the same parts at the end of it — every design on this page is built from the same modular larch blocks and connectors.

Sources & further reading

• Model Context Protocol — the open standard Studio speaks, so other AI assistants can request a real bill of materials rather than infer one.
• Gemini API: image generation — the documentation for image generation and editing from an input image, which is the mechanism behind editing your uploaded photo instead of replacing it.
• Google: creating helpful, people-first content — the reason an article like this one exists: "Does your content clearly demonstrate first-hand expertise and a depth of knowledge?"