GAR Technical definition

General Agent Replacement (GAR)

OctumAI’s cognitive engine architecture. Bounded cognitive tasks are served by components scoped to those tasks, rather than by a single general-purpose model invoked uniformly for all work.

Published 20 August 2026 Version 1.0 Author Joe Boyd, Co-Founder, OctumAI Status Living document

1. Definition

General Agent Replacement (GAR)

GAR is OctumAI’s cognitive engine architecture. Bounded cognitive tasks are served by components scoped to those tasks, rather than by a single general-purpose model invoked uniformly for all work. The architecture is characterized by four properties, each of them necessary: an implementation lacking any one of them is not GAR.

  1. Task-scoped specialization. Work is decomposed into bounded cognitive tasks, and each is served by a component sized to that task rather than by a single model sized to the hardest task in the system.
  2. Operational improvement. The system improves as a consequence of ordinary operation, rather than only through discrete retraining cycles. Improvement is per-task and monotonic: a task that has improved does not regress.
  3. Self-contained inference. Every model involved in producing a response, and in improving the system's ability to produce it, executes within the operator's infrastructure boundary. No component of the cycle requires transmitting input to a third-party inference provider.
  4. Engine substitutability. The serving engine is a configuration property rather than an architectural commitment, permitting direct substitution and like-for-like comparison against alternative engines on identical workloads.

These are necessary conditions, not a sufficient definition. A system exhibiting all four is not thereby GAR: the properties describe what the architecture must do, not how it does it, and the how is what separates one implementation from another. That distinction is the same one this program insists on elsewhere — establishing that a component is necessary for a capability does not establish that a set of such components suffices to produce one (§3).

“Better reasoning doesn’t always come from making models bigger. Sometimes it comes from rethinking the architecture.”

— Joe Boyd, Co-Founder, Octum

2. Design motivation

A general-purpose language model is sized to the hardest task it may be asked to perform. When such a model is used for every task in a system, the cost, latency and energy of the hardest case are paid on every case — including the narrow, repeated judgements that constitute most cognitive work inside a product.

This is an allocation problem rather than a capability problem. The capability of frontier models is not in question; what is in question is whether invoking that capability uniformly is the correct default. GAR takes the position that it is not, and that the useful unit of engineering is the bounded task rather than the model.

The consequence is an economic profile that inverts the usual one. Under uniform invocation, marginal cost per task is constant and total cost scales linearly with usage. Under GAR, tasks migrate over their lifetime from expensive general handling to inexpensive specialized handling, so marginal cost per task declines with accumulated use.

Marginal cost per task over accumulated use A flat dashed line representing constant cost per task under a general-purpose model, contrasted with a descending step function representing GAR, where cost falls as individual tasks migrate to specialized handling. General-purpose model — constant GAR — declines as tasks become reflexes Marginal cost per task Accumulated use → each step = a task that no longer requires the general engine
Figure 1. Marginal cost per task. Under uniform invocation cost is constant; under GAR it declines in steps as individual tasks migrate to specialized handling. The shape is illustrative of the design intent, not a measurement.

“Nobody puts the same engine in a motorcycle and a container ship. Software is heading the same way, for the same reason.”

— Joe Boyd, Co-Founder, Octum

3. Architectural principles

GAR is built against a set of components identified as necessary for capable reasoning. Each was established as a forcing result: a task constructed so that the absence of the component reduces performance to chance, making the component the difference between working and provably not working, rather than a design preference.

Each result is graded by the strength of its evidence — an impossibility proof outranks convergence across architectures, which outranks a single ablation — and grades are not rounded up. The set is treated as an estimate of necessity, not a claim of completeness or of sufficiency: necessity per capability does not establish that the assembled set suffices.

These principles describe what any capable reasoning system must contain. They are the foundation GAR is built on, not a depiction of its topology. What makes an implementation GAR is the four properties in §1 — how that necessary structure is decomposed into bounded tasks, and how those tasks come to be handled more cheaply with use.

Composition of the architectural principles A left-to-right data flow: history feeds a state layer combining selection and structured representation, which feeds a model layer computing what cannot be precomputed, which feeds a selection layer combining credit assignment, a common scale and inviolable limits, producing an action. Two principles span the whole flow: calibrated uncertainty above, and non-destructive accumulation below. P7  Calibrated uncertainty — knowing what is not known history State P1 select what matters P2 reuse structure Model P3 compute what cannot be precomputed Selection P4 choice to consequence P5 one scale for choosing P6 inviolable limits action P8  Non-destructive accumulation — learning without overwriting
Figure 2. The general architecture GAR is built against, not GAR’s own topology. The principles are not an inventory; the composition is the architecture. Six form a data flow from history to action. Two are cross-cutting: uncertainty constrains what the system is willing to assert, and non-destructive accumulation governs every learned component over time.

4. Evaluation methodology

Property 4 — engine substitutability — exists partly to make evaluation honest. Because the serving engine is a configuration property, an environment configured identically to production in every respect except the engine can be run alongside it, and the two compared on the same workload rather than on selected benchmarks.

The comparison is conducted continuously against the best available general-purpose models on production-representative work. The frontier model is therefore not merely a dependency to be removed; it is the standard against which the specialized system is held, and the condition for cutover is that the comparison ceases to favor it.

A methodological commitment accompanies this: vindication and falsification conditions are recorded before a build, together with an explicit list of rationalizations that will be refused — in particular, retreating to a weaker version of a claim that can be defended regardless of evidence. The architecture described here is itself the product of that discipline: it exists because an earlier architecture was tested against its own pre-registered conditions and did not hold.

“Our first architecture didn’t work. We wrote that down in the same document that proposed it, and built the current one in response.”

— Joe Boyd, Co-Founder, Octum

5. What GAR is not

Several adjacent ideas are frequently conflated with this one. The distinctions are as follows.

  • Not a model. GAR names an architecture and a set of properties, not a set of weights. It is not a competitor to any particular model, and an implementation may incorporate several.
  • Not a routing layer. Selecting between third-party models per request satisfies none of the four properties: inference is not self-contained, and nothing improves through use.
  • Not fine-tuning. Fine-tuning produces a modified model at a point in time. Property 2 concerns improvement as a consequence of operation rather than of discrete training events.
  • Not a smaller model used for cost reasons. Substituting a cheaper general model for an expensive one changes the price of uniform invocation. It does not decompose work into bounded tasks, and provides no mechanism by which cost declines with use.
  • Not an inference-time optimization. Caching, quantization and batching reduce the cost of executing a fixed system. Property 1 concerns what is executed rather than how efficiently it runs.

6. Citation and status

This document is maintained as a living definition and will be versioned as the architecture develops. Material changes will increment the version and update the modified date; the definition in §1 is the stable, citable unit.

Suggested citation

Boyd, J. (2026). General Agent Replacement (GAR): A Technical Definition, version 1.0. OctumAI. https://octum.ai/engine-technical.html

Less formal, more context Why we built our own engine The plain-language version: what this means for cost, for confidentiality, and for anyone deciding whether Octum is a wrapper around somebody else’s model.

Built for institutional investing

GAR is the engine behind Ora, our research assistant for investment professionals. The fastest way to judge the architecture is to use what it powers.

Become a Member See what Ora does

First month free, then $19/month. About 3 minutes to join.