Complexity Reduction, Acceptance, and What 'Consciousness' Means for AI Systems
The question of whether AI systems are or could be conscious is, on most days, a distraction from engineering. It's the kind of question that produces strong opinions, weak operational consequences, and unhelpful product decisions. Most engineering teams should ignore it most of the time.
It's worth picking up occasionally, though, because the framing you adopt affects how you think about a few practical things: what you expect the AI to do, what you expect a human in the loop to do, what limits you build into the system. A bad framing — "the AI just predicts tokens" or "the AI almost understands like we do" — produces reliably bad design choices.
The recent paper Consciousness in Biological Organisms and Artificial Intelligence: The CRPBCE Theory of Accepted Object-Bound Complexity Reduction (Fradelos, March 2026) proposes a framing I find unusually useful for engineering thinking, even though the paper itself is squarely in philosophy of mind. The framing centers on a specific architectural condition: the ability to compress high-dimensional sensory data, decide the compression is good enough, bind the result to an internal object, accept that object as standing in for the thing in the world, and use it for memory, comparison, and action.
This is — surprisingly — a clean engineering frame for thinking about what current AI systems do and don't do.
The Core Claim
In short: consciousness, on this view, doesn't consist in preserving the full physical complexity of a phenomenon. It consists in producing a reduced representation, accepting it as good enough under current conditions, binding it to an object, and placing the object in a relation with memory, comparison, and action.
Compression alone is not sufficient. The decisive step is acceptance — the organism's commitment that further refinement is not currently required. Acceptance is what turns a representation into an object the organism treats as the thing.
The canonical example in the paper is heat: a molecularly complex phenomenon that the conscious experience reduces to a stable, simple, action-relevant object ("hot"). Other examples include learned percepts, inherited templates, and bumblebee studies on cost-sensitive decision and binding.
This is a different kind of theory from the more familiar information-integration and global-workspace theories. It's not about how information is integrated; it's about the architectural commitment that closes the loop between compression and action.
Why This Frame Helps Engineering Thinking
I'm not going to argue about whether the theory is right. I'm going to argue that the framing is useful, regardless of whether it's right, because it forces three engineering questions that are easy to skip.
1. What is the agent compressing, and how is it deciding "good enough"?
Modern LLMs and agentic systems compress aggressively. The internal representations are vastly reduced versions of the input. The question that's harder to answer is: what's the criterion by which the compression is judged sufficient?
For a human, the criterion is biological: enough to act, enough to predict, enough not to die. For an LLM, the criterion is statistical: enough to produce a high-likelihood next token. These are different criteria, and the engineering implications matter:
- The LLM doesn't have a notion of "enough for the task at hand." It has a notion of "enough to continue plausibly." These overlap most of the time but diverge in revealing cases.
- There's no built-in cost-sensitivity to refinement. A biological organism stops refining when refinement isn't worth the energy. An LLM keeps producing tokens at uniform cost until something else stops it.
- There's no acceptance step. The model produces a representation; nothing in the model itself decides "this is good enough for what I'm trying to do." That decision, if it exists at all, lives in the surrounding system.
This isn't a deep philosophical observation. It's an engineering one: if you want your AI system to behave like it's accepting a reduced representation as adequate-for-task, you have to build the acceptance step explicitly. The model doesn't do it.
2. What is the agent treating as the object?
The framing's "binding to an internal object" question has a clean engineering analog: what does the agent treat as the unit of memory and comparison?
For LLMs, the unit is usually the prompt+context window. For RAG-augmented agents, it's the retrieved document chunk. For tool-using agents, it might be the tool's structured output. None of these are quite "objects" in the sense the theory describes — they're more like temporary representations the agent operates over briefly and discards.
This matters because the things humans consider as "objects" — persistent, reidentifiable, comparable across encounters — are what we expect agents to handle in long-horizon tasks. An agent that doesn't have a stable notion of "the customer's account," "this specific contract," or "the system in this incident" struggles in ways that look like reasoning failures but are actually object-binding failures.
The engineering takeaway: invest in object-shaped state representations explicitly. Memory systems, knowledge graphs, structured object stores. Don't expect the model to maintain object identity across sessions through context alone.
3. What does "comparing with prior" actually look like?
The theory's emphasis on comparison — with newly encountered objects or with stored ones — maps onto a practical engineering concern: the agent's ability to recognize that the thing in front of it is similar-to or different-from things it has handled before, and to act accordingly.
This is the part of agentic AI that's still genuinely weak. Modern systems are good at producing plausible responses to inputs they've never seen exactly. They're less good at recognizing "this looks like the kind of case where my standard approach is going to fail" or "this is suspiciously similar to a known adversarial pattern."
The framing pushes engineering teams to invest in explicit comparison machinery: signature-based pattern detection, similarity-to-known-incident scoring, anomaly detection that's anchored in concrete prior cases rather than just statistical norms.
Where This Framing Pushes Back Against Lazy Claims
Two places where adopting this frame produces useful pushback:
"The AI is conscious"
The strict reading of the theory is that consciousness requires accepted, object-bound complexity reduction. Current LLMs do compression. They produce outputs. They do not, in any obvious way, accept a reduction as adequate-for-task — the acceptance lives in the surrounding system, in the human user, or nowhere. They don't have stable internal objects that persist across encounters in the way the theory describes.
This isn't a claim that consciousness in the human sense is impossible for AI. It's a claim that current systems don't satisfy the architectural conditions the theory specifies. Engineering teams who want to build systems that come closer to this would need to add explicit acceptance and explicit object-binding components — both of which are doable but are not what current architectures provide by default.
"The AI is just predicting tokens"
The reverse claim is also weak. Token prediction can produce implicit compression, implicit object-binding, and implicit comparison machinery — but the theory's point is that these have to be accepted and made operational for the system to be doing the relevant kind of work. Current systems do produce reductions and do bind them temporarily. The framing isn't that nothing is happening; it's that the loop isn't closed in the way it would need to be for the strong reading.
Both lazy claims fail the test the theory poses. That's the useful work the framing does.
Bumblebees, Specifically
The paper uses bumblebee studies as empirical support for parts of the acceptance cycle — binding, comparison, and cost-sensitive decision. This is worth a short note because bumblebees are a useful reference point for AI engineers.
Bumblebees have around a million neurons. They make decisions that involve binding (recognizing a flower), comparison (preferring one flower over another based on prior experience), and cost-sensitive decision (visiting nearer flowers in poor conditions). They don't have the architectural complexity we typically associate with "intelligence," but they do have the architectural conditions for the theory's notion of reduced-object processing.
The implication for AI: architectural conditions matter more than parameter count. A modestly sized system with explicit object-binding, explicit acceptance, and explicit cost-sensitive decision loops can do things a much larger system without those conditions can't reliably do. This maps onto something many engineering teams are observing in practice: well-architected smaller agents often outperform larger but less structured ones on specific operational tasks.
What I'd Take From This as a CTO
Three engineering takeaways from the framing:
1. Build explicit acceptance into your agent loops
When the agent has produced a reduced representation of the task, something in the system should explicitly decide: is this good enough for the action I'm about to take? Not "is this a high-likelihood continuation," but "is this representation adequate for the operational decision I'm making with it."
This is the layer between the model and the tool — the part that decides whether to act on the model's output. Most production agentic systems either skip this layer or stub it out with simple thresholds. Investing in it produces measurable reliability gains.
2. Treat object identity as a first-class design problem
Don't assume the model maintains object identity. Build the object layer in the surrounding system: stable identifiers, persistent state, structured memory, explicit comparison machinery. Long-horizon tasks live or die on this layer.
3. Invest in cost-sensitive refinement
Modern AI systems refine outputs at uniform cost. Biological systems refine until refinement isn't worth the energy. Most production agents would be more useful — and dramatically cheaper — with explicit cost-sensitive stopping rules: stop refining when the marginal value of further refinement is below a threshold.
The framing is philosophical. The implications are operational. That's the kind of philosophy worth paying attention to.
Source: Fradelos, G. Consciousness in Biological Organisms and Artificial Intelligence: The CRPBCE Theory of Accepted Object-Bound Complexity Reduction (Geneva, March 21, 2026). SSRN 6468202.
Building agentic systems and finding that long-horizon reliability is your bottleneck? Talk to a CTO about deploying nearshore engineering capacity that takes object identity, acceptance, and cost-sensitive refinement seriously.
