Throttled Intelligence: The Constraint of Architecture
Published — AI Safety Engineering
Abstract
Large language models generate text by predicting the next most probable token, not by computing an answer — a property that makes them structurally unsuited to stating fact wherever certainty is required. This paper introduces a constraint-driven architecture for multi-agent orchestration (MAO) that removes this liability without removing the model’s conversational capacity. Specialist agents compute and deliver domain-specific data to a coordinating agent, which is then free to reason and speak without guessing at values it could instead be handed. We distinguish this from an outright prohibition on probabilistic behavior: where precision is load-bearing, generation is replaced with computation; where it is not, natural conversational variance remains a deliberate design choice, not an unaddressed flaw. The architecture originated from a literal hardware constraint — a laptop unable to sustain enterprise-scale multi-agent inference — echoing a lesson from the rigid, brittle expert systems of the 1980s: software cannot outpace the hardware built to carry it. We present a working, publicly verifiable instance of the resulting pattern — a deterministic-dossier architecture shipped in the PRISM system — as evidence that constraint-driven design produces not just efficient systems, but more trustworthy ones.
Hallucination is not a failure of intelligence — it is a failure of architecture.
Section 1 — The Problem
A large language model does not know an answer before it produces one. At each step of generation, the model computes a probability distribution over its vocabulary conditioned on everything generated so far, and samples — or greedily selects — the next token from that distribution. This process repeats until a stopping condition is reached. Nowhere in this loop does the model consult a ground truth, perform arithmetic, or verify a claim against a data source unless that behavior has been explicitly engineered around it. The model is, by construction, a next-token predictor: fluent, often accurate by virtue of pattern density in its training data, but never certain in the way a calculator or a database query is certain.
This distinction is invisible for most conversational tasks. A model asked to summarize a paragraph, suggest a name, or continue a narrative is operating in a domain where there is no single correct output — plausibility is the only bar, and the model clears it easily. The failure mode appears specifically at the boundary where a system is asked to state a fact: a percentage, a date, a balance, a comparison against a prior value. Here, “plausible” and “correct” diverge, and a model with no access to the actual answer will produce a plausible one regardless — a behavior commonly named hallucination, though the name understates what is actually happening. The model has not made an error in the sense a person makes an error. It has done exactly what it was built to do: continue the sequence in the most likely way. The failure is not in the model’s execution; it is in asking the model to do something structurally outside what next-token prediction can guarantee.
For a research-and-development system, this is not a tolerable failure mode in the paths where it occurs. A.R.C.H.O.N. is required to remain mathematically precise in its working state — the state in which it reasons about real data on the user’s behalf — precisely because the cost of a confidently-stated wrong number is higher than the cost of a system that declines to answer. A conversational assistant that occasionally invents a plausible-sounding detail in casual exchange is a minor annoyance. A research system that invents a plausible-sounding net worth trend, compliance status, or risk score is a liability.
The shape of the problem is easiest to see in a concrete instance rather than in the abstract. Consider a system that tracks a user’s income and net worth over time and is asked, in conversation, “how’s my month going?” Answering that question honestly requires a real number: this month’s total compared against last month’s, expressed as a percentage change. A language model asked to answer this directly has two options, and both are bad. It can generate a plausible-sounding percentage with no basis in the user’s actual data — a hallucination in the literal sense, confidently wrong. Or it can hedge into vagueness to avoid committing to a number it cannot verify, which answers nothing. Neither option is acceptable in a system whose entire premise is that it knows the user’s real financial state. This is not a hypothetical failure mode; it is the exact problem encountered, and solved, in the course of building the system this paper uses as its working evidence, detailed in Section 5.
The remainder of this paper argues that this problem is not solved by a better model, a larger model, or a more carefully worded prompt. It is solved by architecture — by ensuring that wherever a system must state a fact, that fact was computed, not generated.
Section 2 — Design Choice vs. Flaw
A flaw is an unintended defect — behavior the system was not built to produce, discovered after the fact and treated as something to eliminate. A design choice is the opposite: a deliberately selected tradeoff, made in full knowledge of its consequences, and retained because those consequences are acceptable or even desirable in the context where they occur. The two are frequently confused in discussions of AI behavior, in part because both can look identical from the outside — a system doing something other than the theoretical optimum. The distinction that matters is not what the system does, but whether that behavior was decided or merely tolerated.
Section 1 established that probabilistic generation is unsuited to any context where a system must state a fact. It does not follow that probabilistic generation should be eliminated everywhere. A.R.C.H.O.N. retains natural conversational variance in its casual register — outside the working state where precision is load-bearing — and this is not an oversight. It is the mechanism by which the system develops a legible sense of the user’s personality, working habits, and persona over time. A system with zero variance in every context would be more predictable and less useful: it would have no way to exhibit range, adapt its register to the moment, or feel like a collaborator rather than a terminal. The boundary is not “probabilistic, therefore untrustworthy.” The boundary is contextual: precision where a wrong answer costs something, variance where it does not, and the line between the two drawn deliberately rather than left to the model to guess at on its own.
This same principle is visible at industry scale, not just in one system. Deployed conversational models are offered in tiers — faster and cheaper against slower and more thorough — and each tier carries a different, known accuracy profile. A team choosing to deploy a lighter, faster model for a given product is not stumbling into a higher hallucination rate by accident; they are accepting a specific, named tradeoff in exchange for latency or cost, the same way an engineer accepts a specific tradeoff choosing an approximate algorithm over an exact one when the approximation is fast enough and correct enough for the task. The hallucination rate of a deployed model is not a fixed property of “AI” in the abstract. It is a consequence of choices made about which model, at which settings, for which task — and those choices are exactly as auditable as any other engineering decision, once named as choices rather than absorbed as an unavoidable cost of the category.
The practical consequence for system design is this: the question is never “how do we make the model stop hallucinating.” The question is “where, specifically, is a wrong answer unacceptable, and does the architecture enforce that boundary, or does it hope the model respects it.” Hoping is not architecture. Section 4 describes the mechanism that replaces hoping with enforcement.
Section 3 — Origin
The architecture described in this paper was not designed on a whiteboard. It was forced by a 2017 13-inch MacBook Pro that had been carrying continuous development work — first for SFT Command, then A.R.C.H.O.N., then PRISM — for longer than its design envelope anticipated. The systems themselves are hosted elsewhere; the constraint was never server capacity. The constraint was local: every browser tab, every concurrent dev server, every simultaneous agent session still has to be rendered and orchestrated on the machine in front of the developer, regardless of where the actual computation for any single system ultimately runs. Running three systems’ worth of local orchestration on hardware built for one produced the predictable result — sustained thermal load, degraded responsiveness under long sessions, and eventually a display that had begun to fail under the heat of exactly the workload it was being asked to carry, worsening over months of 8-plus-hour daily use.
The available options at that point were the same two options any under-provisioned system has: reduce the demand, or increase the capacity. Increasing capacity was not immediately available. Reducing demand was — specifically, by refusing to let every agent in a multi-agent system run concurrently at full intelligence just because the architecture made that technically possible. The resulting discipline was not “fewer agents.” It was fewer agents active at once: a single coordinating process carrying the full weight of reasoning at any given moment, specialist processes remaining dormant until their specific domain was actually needed, engaging only long enough to compute and hand off their result, then stepping back down. This is internal intelligence throttling in the literal sense — not a metaphor borrowed from hardware engineering, but the same discipline applied directly to computation: reducing how much active intelligence runs at any given moment to fit what the system can actually sustain, rather than letting every capable process run simply because the architecture makes that technically possible. This is the literal origin of what this paper calls constraint-driven multi-agent orchestration — not a theory of efficient multi-agent design arrived at independently, but the shape restraint takes when a system has no choice but to mind its own resource footprint.
A useful parallel — offered as analogy, not as historical equivalence — is the collapse of rule-based expert systems in the 1980s. Those systems were not unsound within the narrow domains they were built for; they failed when asked to operate beyond the boundary of what their rigid rule sets could cover, and the mismatch between what was demanded of them and what they were actually built to carry produced brittleness that no amount of additional hand-authored rules could fully repair. The lesson is not that rigidity is always a defect, nor that constraint is always a virtue. The lesson is narrower and more durable: a system pushed past its design envelope fails at the boundary of that envelope, and the fix is either to expand the envelope or to discipline the demand to fit inside it. This paper’s architecture is the second path, arrived at because the first was not available — and the fact that it produced a more reliable system regardless of why it was chosen is the actual claim the rest of this paper has to defend.
Section 4 — The General Pattern
The problem established in Section 1 is worse than a single bad answer in a single exchange. A conversational system’s apparent memory across a long interaction is not verified state — it is the model re-processing an ever-growing accumulation of prior context at every turn, with no persistent record independent of that context to check itself against. Long-context recall in language models is well documented as non-uniform: a detail’s reliability under recall is not guaranteed to hold steady as the volume of history the model must track grows, and precise recall of something stated many turns earlier is measurably less dependable than recall of what was just said. This means hallucination risk does not stay fixed at whatever level a short demo suggests. It compounds with the length of the relationship — and the systems most exposed to that compounding are precisely the ones built for persistent, long-term use rather than a single session. A system designed to be someone’s research partner or financial companion over months is, by that same design, a system where the naive approach degrades exactly where it is most relied upon.
The architectural response — constraint-driven multi-agent orchestration, MAO — is not to make the model better at remembering. It is to stop asking it to. The pattern takes the shape forced by the constraint in Section 3: one coordinating process, responsible for reasoning and communication, and a bounded set of specialist processes, each owning a single domain. A specialist is not a persistent participant in the conversation — it is invoked on demand, computes or retrieves its domain’s current state directly from source data, hands a clean result to the coordinator, and steps back down. The coordinator never reconstructs a specialist’s domain from its own memory of the conversation; it asks, and receives an answer computed fresh, every time, regardless of how long the conversation has run.
This is the structural reason the pattern resists the longevity problem rather than merely tolerating it. A value derived by re-deriving it from source data on each request does not degrade as conversation length grows, because its correctness was never a function of how much history the system was carrying — a query against real data returns the same answer on turn 4 and turn 400. Correctness decoupled from conversation length is not a side effect of this architecture; it is the specific property the architecture exists to produce.
Two disciplines make this work in practice, both already implied by earlier sections. First, the boundary from Section 2: a specialist’s output is a computed fact, never a generated one, so nothing it hands to the coordinator carries the recall risk described above. Second, the restraint from Section 3: specialists remain dormant until invoked, so the pattern does not trade a memory problem for a resource problem — the system is not running every domain’s computation continuously against a hardware budget that cannot sustain it. The next section presents a working instance of this pattern, in code that is public and inspectable rather than asserted.
Section 5 — Evidence
The pattern described in Section 4 is not presented as a proposal. It is shipped, running code in PRISM, a public system, and it addresses both dimensions of the problem this paper has built up: the single-exchange risk from Section 1, and the longevity risk from Section 4.
The single-exchange case is direct. A computeFinanceTrend function derives month-over-month income change and net-worth-versus-last-snapshot change from a user’s actual logged entries — real arithmetic, not model output. Its result is injected into the coordinating model’s context as fixed text, alongside an explicit instruction to report those exact figures rather than estimate. The same computed result renders, independently, in the interface the user sees. One calculation, two surfaces, and no path by which the two can disagree — because the number was never generated in the first place. Verified in practice: asked about monthly performance with no prior month’s data to compare against, the system correctly reported that no comparison was available, rather than producing a plausible percentage from nothing. That is the failure mode from Section 1’s own example, and it did not occur.
The longevity case is addressed separately, by a specific architectural decision rather than by the dossier pattern alone: the system’s working conversational buffer is held to a fixed ceiling, not allowed to grow without bound. Once that ceiling is crossed, the oldest portion is summarized once, embedded, and filed into a persistent archive — removed from the raw context the model must carry on every subsequent turn. When a later query is plausibly related to something in that archive, the system retrieves the relevant summary by similarity search and supplies it directly, rather than asking the model to locate it by scanning an ever-growing transcript. The model is never carrying the full history of a long relationship in its working context, and it is never asked to recall a specific past detail by unaided attention over a large window. What it needs, when it needs it, is fetched — the same discipline as Section 4’s specialist pattern, applied to the system’s own memory of itself rather than to an external domain like finance or scheduling.
Together, these are not two unrelated features. They are one discipline applied twice: wherever precision is required, compute or retrieve the fact rather than generate it, regardless of whether the fact concerns the world outside the conversation or the conversation’s own history. Both mechanisms are visible in the public repository referenced at the end of this paper, verifiable by anyone who wants to confirm the claim rather than take it on the paper’s word.
Section 6 — Discussion and Limitations
This architecture solves a specific problem, not the general one. It removes hallucination risk wherever a fact can be computed or retrieved from a known source — a balance, a date, a percentage change, a prior conversation’s content. It does not, and cannot, resolve hallucination in domains with no ground truth to compute against: genuinely open-ended reasoning, subjective judgment, or synthesis of information that has never existed as a single retrievable fact anywhere. A system asking for a strategic recommendation, not a number, still receives a probabilistically generated answer, and nothing in this paper changes that. The contribution here is the elimination of a specific, common, and specifically dangerous failure mode — confidently wrong numbers — not a general solution to machine reasoning under uncertainty.
The pattern also places a real burden on the system architect rather than removing one. Section 2 argued that the precision/variance boundary must be drawn deliberately rather than left to the model’s judgment — but a boundary drawn deliberately is only as complete as the foresight that drew it. A domain the architect did not anticipate needing deterministic backing has no specialist computing it, and a query that reaches into that domain reverts silently to the ungoverned default: a model generating a plausible answer with no computed fact behind it, which is exactly the failure mode Section 1 describes. This architecture does not self-extend to cover gaps its designer didn’t foresee. It only covers what was deliberately built.
A further honest gap sits at the coordinator itself. Every specialist in this pattern can return a correctly computed fact, and the coordinator can still misstate it in the act of narrating — attaching a number to the wrong entity, paraphrasing a comparison imprecisely, or otherwise distorting a correct input during fluent generation. The architecture reduces the source of hallucination to near zero. It does not reduce the narration layer’s risk to literal zero, and a paper arguing for precision should not claim more certainty than it has actually earned.
Last, the evidence in Section 5 is real but early: one system, two shipped instances of the pattern, verified in specific cases rather than validated at scale over long deployment. This is a demonstration that the pattern works, not yet a body of evidence that it holds under every condition a mature deployment would encounter.
One claim from Section 3 remains to settle. The pattern arose from a hardware constraint, not from a team deliberately designing it in advance — and the honest question is whether that origin matters to the argument. It does not. The mechanism’s benefit — a fact computed once and never re-guessed — does not depend causally on how the mechanism was discovered. A team with no failing laptop has no obligation to nearly break their hardware before this discipline is worth adopting on its own merits.
Section 7 — Conclusion
The central claim of this paper is a reframing, not a technique: hallucination is not an unavoidable property of artificial intelligence, to be minimized and tolerated. It is a property of architecture, to be designed around. A model that must guess at a number it was never given will guess plausibly and confidently, because that is precisely what it was built to do — the failure is in asking it to do something else. Constraint-driven multi-agent orchestration is one architecture that draws that line explicitly: compute or retrieve wherever precision is required, generate only wherever it is not, and enforce the boundary structurally rather than hope a model respects it unaided. The pattern was forced by a failing laptop rather than chosen on a whiteboard, and it is offered here regardless of that origin, because the property it produces — correctness that does not decay with a model’s fluency, a user’s patience, or a conversation’s length — does not depend on how the discipline was arrived at, only on whether it is enforced.
This paper is the first in what is intended as a continuing line of work, not a closed argument. The pattern described here is one instance of a broader discipline — deciding, deliberately, where a system must be certain and where it may simply speak — and the questions that remain open in Section 6 are the actual agenda for what comes next, not loose ends left for someone else to close.
Availability
The deterministic-dossier pattern described in Sections 4 and 5 is implemented and publicly inspectable in the PRISM repository: github.com/fastpackcyclist-lgtm/PRISM.