What Predictive Processing Can and Cannot Teach AI Engineers

Predictive processing is most useful to AI engineers when treated as a disciplined comparison, not as proof that a model works like a brain.

The central proposal

The paper frames perception as hierarchical inference. Higher levels generate predictions about lower-level activity. Lower levels return differences between predicted and observed signals. The system adjusts its internal estimates to reduce consequential prediction error.

This is not simply "guess the next input." The account includes hierarchy, uncertainty, recurrent exchange, learning at different timescales, and an embodied loop in which action can change incoming observations.

What transfers usefully

1. Residual information can be more valuable than raw repetition

Engineering systems often become clearer when they make mismatch explicit. Validation errors, evaluation residuals, failed tool preconditions, retrieval misses, and user corrections carry information about where the current model of the task is wrong.

The lesson is not to label every error signal "predictive coding." It is to design feedback so the system can localize a mismatch and choose a bounded response.

2. Hierarchy changes what counts as an error

A low-level mismatch may be harmless if a higher-level objective is still satisfied. Conversely, fluent text may be a severe error when it violates a clinical, legal, or financial constraint. Evaluation therefore needs layers: representation, task behavior, workflow outcome, and consequence.

3. Confidence should control attention and escalation

Predictive-processing accounts assign different influence to signals according to expected precision. An engineering analogue is confidence-aware routing: uncertain evidence should trigger retrieval, tool use, abstention, or human review rather than be hidden behind a confident interface.

Where the analogy breaks

Current foundation models are trained through optimization over datasets and then executed inside engineered systems. They do not automatically possess biological embodiment, homeostatic needs, human memory organization, or the same learning loop as a living nervous system.

Transformer prediction objectives, predictive coding, Bayesian brain theories, and active inference are related at a high conceptual level, but they are not interchangeable implementations. Similar mathematical language does not establish functional identity.

The strongest practical rule is therefore negative: never use a neuroscience metaphor as evidence for a capability claim. Use it to generate questions, then test those questions against the actual system.

Engineering decision table

| Question | Useful implication | Unsafe leap | |---|---|---| | What does the system expect? | Define schemas, constraints, and evaluation criteria | Assume the model has human-like expectations | | Where does mismatch appear? | Capture validation, retrieval, tool, and outcome failures | Treat all token loss as product-level error | | How should uncertainty change action? | Route, abstain, retrieve, or escalate | Convert model confidence directly into truth | | What updates after feedback? | Separate prompt, state, retrieval, policy, and model changes | Assume the deployed model learns from every interaction |

A practical architecture exercise

For one AI workflow, write down five things: its current hypothesis, the evidence it observes, the mismatches it can detect, the actions it may take, and which state is allowed to change. If any update is implicit, the system will be difficult to evaluate and govern.

Bottom line

Predictive processing offers a rigorous vocabulary for hierarchy, error, uncertainty, and feedback. Its engineering value comes from forcing clearer system questions. Its danger comes from turning an explanatory theory of biological perception into an unsupported claim about machine understanding.