TALAMANA · THE AI LITERACY MAP FOR ARCHITECTURE AND DESIGN · Studio Practice · AGE 20—22 · POSITIONAL · HELD
Two paths to capability
Most small and mid-sized studios should default to the run end, which bends as models improve.
Our position
When a studio wants more than the apps give, the choices run along a spectrum, not between two doors. At one end, build: a custom tool, coded for one job, owned outright, maintained forever. At the other, run: an agentic workflow on general-purpose systems — a model, a set of permissions, a library of briefs, a few connectors — orchestrated rather than built. Between them sit buying software as a service, configuring a platform, scripting around one, fine-tuning a model, self-hosting an open one, commissioning a system from someone else, and combining several of these. This is a way to decide, not a list of products to buy. For most small and mid-sized studios we hold that the run end is the right default: it bends as the models improve, and it fails in ways a non-programmer can see and fix.
Why we hold it
Because the thing that changes fastest is the model, and a custom tool freezes today's model into tomorrow's liability. Orchestration opens selective points of access to what the studio already has — its drawings, its files, its spreadsheets — and asks "what should the system be allowed to touch?" rather than "can it connect to everything?" A principal can answer that question. A principal cannot fix the code.
The strongest objection
Build versus run is not the axis that matters. Who owns the code, where it is hosted, which model it uses, whether the model's weights are open, how deep the integration goes, how much is customised, where the data lives and who maintains it are separate dimensions, and a studio can sit anywhere on each. "Build" does not mean owned outright: a custom tool usually rents its model through an API and its hosting from a cloud. "Run" does not mean rented ground: an agentic workflow can run on an open model on a machine in the studio. Collapse eight dimensions to one and the decision looks simpler than it is, and the real objection to orchestration — that a studio on a provider's general system controls neither pricing, nor terms, nor data handling, nor the day the model is retired — is an objection to one hosting choice, not to a path. For anything load-bearing — a compliance check, a fee calculator — the studio may need to hold some of those dimensions tightly whichever end it starts from.
What would make us revise it
If the dimensions stop moving together — if, say, self-hosted open models make ownership cheap without losing adaptability — the spectrum stops being a useful shorthand and this card becomes a matrix: one row per dimension, the studio's choice in each. Evidence from small studios that orchestrated workflows broke more often, or cost more over three years, than built tools of the same scope, or a provider event — a retirement, a terms change — that damaged studios at the run end in a way the build end would have survived, would move our default. Reviewed against what we run ourselves.
Try it
Take one real studio need — precedent search, minute-taking, bye-law checking. Place it on the spectrum and name the trade-offs: cost, ownership, hosting, model choice, maintenance, who can fix it at midnight. Then say where a studio of five people with no programmer can actually sit, and which two dimensions it must hold tightly whatever it chooses.
Take it to crit
Given a studio scenario, does the student reach for the decision — where on the spectrum, and which dimensions matter here, and why — or for a brand name?
What this idea builds on
What this idea opens up
- Nothing yet names this as a foundation.
Sources
Open this idea on the map · The complete map · Logika · RBDS AI Lab, India · revised every edition.