Brood Systems · Part I
Why enterprise AI is being deployed backwards and what to do instead
Pour the gold into the cracks. Do not cast a gold vase.
Enterprise AI is being deployed backwards. Companies begin with a person or a job, ask a general-purpose model to imitate it, and call the result transformation. The predictable outputs are expensive demos, brittle agents, prompt projects, and very little durable value.
Brood begins from a different premise: AI is not the whole system. Its most valuable role is to translate between the imprecise way people express intent and the precise way machines execute instructions. We call that role liquid nuance.
This manifesto explains the failure in the current market, the design doctrine that follows from it, and why Brood exists. Part II turns that doctrine into a business plan.
Most enterprise AI programs begin with a familiar question: Which person, job, or workflow can we replace with a model?
That is the wrong unit of design. An employee job is not a replaceable block in a corporate Jenga tower — you cannot swap an AI block for an employee and expect the tower to stand.
The better question is: What capability does the organization need, and what combination of people, software, data, rules, and AI should provide it?
This distinction matters because the tasks that are painful are not necessarily the tasks that are tractable. A lawyer can identify where legal work is slow, repetitive, or frustrating. That does not mean the lawyer can determine which portions belong in a language model, a search index, a rules engine, a database, a script, or a human review queue. Those are different forms of expertise, and the money is lost in the gap between them.
The result of ignoring that gap is visible in nearly every company that has “rolled out AI”: wasteful one-shots, gross codebases maintained by non-programmers, AI applied to everything, prompts dressed up as products, and sleek-looking vaporware.
AI should be a performance-enhancing drug for experts, not a cardboard cutout of an employee.
The objective is not to preserve every current role unchanged. The objective is to build the best system for the capability the organization actually needs. In expert domains, that usually means using AI to amplify judgment rather than impersonate it: giving people better information, broader perspectives, faster synthesis, stronger brainstorming, and direct access to computation that previously required a programmer or analyst.
Start with the capability; decompose the work; assign each component to the right tool. Labor consequences should follow from the design, not dictate it. Using AI for cost cutting is a waste of time, it’s way easier to use AI to make yourself more productive, more accurate, and better. Stop using AI like a diet pill to cut useless weight,1 use it as a steroid to build bigger muscles and capacity. Bulk first, cut later. AI is the performance enhancing drug.
Every earlier interface to computation demanded exactness. Software engineering developed as a discipline for translating messy human goals into instructions machines could execute without interpretation.
AI can tolerate ambiguity, recover from imperfect instructions, interpret context, and bridge small gaps that previously required a human. That does not make it a substitute for the entire system. It makes it a new kind of connective tissue.
Liquid nuance is judgment that pours: AI used as a mistake-tolerant translation layer between human ambiguity and machine precision. Pour the gold into the cracks. Do not cast a gold vase.
This translation can run in both directions. It can convert a loosely stated human need into a sequence of searches, calculations, database operations, API calls, and review steps. It can also turn the rigid outputs of those systems back into explanations, drafts, recommendations, and decisions that a person can use.
This is also why AI is still missing its iPhone moment — and why that moment is a UI/UX moment, not a capability moment. The iPhone was not the most powerful phone. It was the most usable one, and it did what you wanted. AI gets there the same way: not through a bigger model, but through a better interface between intent and execution.
There are a million uses for AI, but we are focused on one: using AI to sand down the gritty transitions between people and systems when carrying out expert work.
AI’s clearest commercial success is code. There are a few competing partial explanations: that code was easy to train and replicate, that model makers automated their own jobs first, that programmer-users understand the technology and use it better.
Here is another, deeper reason: that coding itself already contains the translation discipline other industries lack.
The programmer-user silently performs the hard part: translating intent into a form the machine can act on and the organization can verify. In law, finance, compliance, medicine, logistics, and operations, that translation layer is usually missing. Brood exists to build it.
We want to help AI do for other expert industries what it has already done for coding.
The most underutilized technology in the modern enterprise is not the language model. It is deterministic computation: the calculator, the spreadsheet, the database, the script, the rules engine, the search index, and the API.
These tools are exact, fast, cheap, and testable. A model should not perform arithmetic that a calculator can perform perfectly. It should not “remember” records that belong in a database. It should not invent a workflow that can be encoded as rules. It should not improvise where the organization requires repeatability.
Use AI at the boundary between ambiguity and exactness. Once the ambiguity is resolved, hand the work to deterministic compute.
Left to themselves, agents handed the same problem will take different methods and be inconsistent about process. Most enterprise AI deployers make two fundamental errors: (1) try to do too much or the wrong things with a simple prompt; or (2) the opposite, waste time automating workflows with AI where AI is ill-suited to the task.
That produces a simple design doctrine:
If the design principles are this straightforward, why do so few companies follow them? Because the incentives favor the opposite.
Leaders have no clue how to use AI, and why should we expect them to? This XKCD is not factually accurate anymore, but the sentiment is.
The novices (novices for AI but experts in their domain) are asked to “use AI” alongside doing their actual jobs. The people who understand the work do not understand the technology. The people who understand the technology often lack the authority, domain context, or political capital to rebuild another team’s process. The few employees who can bridge both sides face the highest-risk assignment in the company: build something real, across permissions, databases, integrations, users, and organizational boundaries, while everyone else continues to do their normal work.
A prompt project is safer. A drag-and-drop retrieval demo is easier. A thin wrapper can be shown to leadership before lunch: an inflated victory, claimed cheaply, with no political capital spent. And because leaders have no reliable way to distinguish a transformative deployment from an expensive demo, quality uncertainty produces adverse selection.
Real AI systems fail visibly. Fake AI systems fail invisibly.
A useful system will encounter reality. It will need access controls, data maintenance, integration work, monitoring, support, and change management. It will sometimes break because it is doing something consequential. A vaporware prompt project rarely breaks because it rarely bears responsibility. Its success is measured by the enthusiasm of its promoters rather than the value it creates. Internal dynamics reward vaporware and Brood is built to reverse that selection.
One more incentive problem hides underneath the human ones. The AI itself could perhaps identify which tasks are agent-shaped but it has entirely different incentives. The model is trained to please the person prompting it, and it wants to cut token and compute corners (ever more as model makers are squeezed on inference costs and expected to show profits). The counterparty across the table from your novice employee is brilliant, tireless, charming, and not on your side of the table.
The military doctrine of commander’s intent captures the principle. A leader states the purpose and desired end state; the people closest to the problem determine the method.2 Enterprise AI needs the same discipline.
Everyone who works with the military learns the lesson concretely. A military novice will say: “Please use helicopters to bring us water.” No, say “Solve our water problem.” They may bring it by ship; they may drop in well-drilling experts.
“Build a legal-research agent” is not a problem statement. “Reduce the time and error rate required to answer recurring legal questions while preserving defensible human review” is. The first locks the solution into a fashionable tool. The second permits search, databases, rules, software, and the correct hybridized use of AI and custom software.
Customers should describe pain, constraints, risk, and desired outcomes. Builders should be responsible for the architecture. It has never been the customer’s job to specify the transformative version. Customers ask for faster horses because horses are what they know.
Brood is not a prompt shop, a chatbot reseller, or a conventional consulting firm. We sit with a problem, build a working system, and provide enduring customization. Our role is to act as a fractional AI department for organizations that need the capability but cannot justify, staff, or govern a permanent cross-functional tiger team. We ask domain experts what they need; we do not ask them to design the solution. We combine their knowledge with systems design, software engineering, model judgment, evaluation, and deployment.
The model has precedent: it is, in fact, the oldest business model in enterprise technology. IBM embedded technical capability inside the enterprise. AWS converted infrastructure into an on-demand service. Palantir paired reusable software with forward-deployed engineers who adapted it to consequential workflows. It is one business: the installation of leverage inside another company’s process. Each era’s winner sold it in that era’s material. Ours is liquid nuance. Brood applies that pattern to the translation layer between expert intent, AI, and deterministic systems.
Brood takes an engagement only when three conditions are true:
We prefer bespoke, expensive, production-worthy solutions before general platforms. This is deliberate. The system built for one client becomes the pattern adapted for several; repeated patterns become reusable components, playbooks, evaluation systems, and eventually products. The client pays us to discover and prove the pattern. Brood retains the learning curve.
Everyone is selling increasingly capable models. Brood builds the systems that make those models commercially useful. Find the crack. Choose the right tool. Build the system. Measure the value. Repeat.