There are two ways to build with AI. You can build a castle — a new, integrated, self-contained product that puts the model at its center and asks everything else to conform. Or you can do boundary work — figure out how the model fits cleanly against the tools and systems that already exist, and build the connective tissue that makes the pieces compose.
The castle is the default move right now. Almost every AI product is a castle. The chat interface is a castle. The coding IDE with an integrated assistant is a castle. The agent platform with its own runtime, its own observability, its own tool abstraction, its own memory layer — castle, castle, castle. Each one builds a wall around a useful model and a set of proprietary affordances.
We think castles are the wrong move. We think the interesting work — and the durable work — is at the boundary.
The incentives are obvious. A castle is a product. It has a user interface you control, a pricing model you set, a moat you can defend, and a surface area a marketing team can describe. A VC can fund it. A competitor has to match it feature for feature. It has network effects because users' workflows, data, and habits get trapped inside.
Boundary work does not have these properties. Boundary work produces small tools that compose with other people's tools. There is nothing to trap. A user who benefits from your boundary work today can use someone else's tomorrow, because the interface is just text on pipes, and every tool speaks it. This is terrifying to a founder trying to build a moat. It is also, we think, the only approach that respects what users actually want.
Users who have been programming for twenty years have a working environment. They have a shell they like, an editor they like, a set of scripts and aliases and cron jobs and Makefiles that represent a decade of accumulated muscle memory. They do not want to move into your castle. They want to add the model to the environment they already have.
A castle asks them to leave. Every castle is some version of "stop what you are doing, open our thing, work here instead." The IDE with the built-in assistant, the chat app with the file uploads, the agent platform with its own workflow builder — all of these ask the user to relocate.
Boundary work asks nothing. It hands the user a tool shaped like the tools they already have. The model becomes one more thing in their PATH. The user does not have to move, learn a new interface, change their workflow, or trust a new UI with their data. They just pipe.
Boundary work is usually unglamorous. It is the glue code. It is figuring out what format the model should output so the next tool can consume it. It is making the tool fast enough that putting it in a pipe does not feel expensive. It is honoring the conventions of the substrate — exit codes, signals, file descriptors, stdin and stdout — even when it would be easier to invent new ones.
A few examples of boundary work we have done on linuxtoaster, to make this concrete:
toast is a thin C client talking to a local toastd daemon over a socket. Why? Because if the shell has to pay the startup cost of a Python interpreter every time it pipes through a model, pipes stop feeling natural. The daemon exists so that toast can start in milliseconds and feel like grep feels. That is boundary work. Nothing about it is novel. It is just taking seriously the constraint that the tool must behave like a tool.
jam is a shell we wrote because bash quoting broke down under LLM prompts. Nested quotes, dollar signs inside strings, backticks in code examples — every real prompt became a forest of escapes. Boundary work was to build a shell where strings just work, where $ does not surprise, where times and while are built in so you do not need subshells. Again, nothing flashy. We took the friction at the boundary seriously and removed it.
ito is a version control system in 15 commands because git, for all its power, is a castle with its own model of what a repository is. We wanted history that worked like a log — append, grep, summarize. Boundary work was to build the smallest possible thing that gave us commit history compatible with shell composition:
ito log "why"
ito history | toast "what was the focus last week"The pieces compose because each one does a single job at the boundary with its neighbors.
None of these are inventions. All of them are refinements of the substrate to accommodate a new participant — the model — as gracefully as possible.
There is a pragmatic argument against castles: they lock users in, and users hate that. But there is also a generative argument for boundary work, which is that composable systems produce more than their creators intended.
Unix itself is the canonical case. The people who wrote sort and uniq and grep and awk did not foresee log analysis, text processing pipelines, build systems, or a thousand other uses their tools ended up serving. They built small pieces that composed, and the composition space did the rest. Forty years later we are still finding new things to do with those pieces.
Castles do not have this property. A castle is an answer to a question its architects thought of. Boundary work is raw material that users can combine for questions nobody has thought of yet. When you put a model at the boundary — reading stdin, writing stdout, composable with every other tool — you are making it available for uses you cannot predict. A user in a domain you know nothing about will combine your tool with five tools you have never heard of to do something you could not have imagined.
A castle asks: what if everything went through our product?
Boundary work asks: what if our tool fit naturally into whatever the user already has?
The first question optimizes for the builder. The second optimizes for the user. The first produces a product that grows by capturing more of the user's workflow. The second produces a tool that grows by being useful wherever the user needs it.
A good rule of thumb: if your AI product would not be useful when piped to, the user is not the one you are serving.
Most AI companies are building castles right now because castles are how you build a company. We are not opposed to companies, but we think the castles being built will turn out to be brittle. Users will abandon them the moment a boundary-native alternative is available, because the castle was always an imposition, and the boundary tool fits the shape of their life.
The lesson of forty years of Unix is that the durable software is the software that does one thing and composes. Forty years from now, the durable AI tooling will be the software that put the model at the boundary and let users do the rest.
Boundary work, not castles. That is the job.
This essay is part of LinuxToaster — Unix re-imagined for the era of AI.