TL;DR for operators
- Do not ask, “Can the model do the task?” Ask, “Does the model use the capabilities it already has when the task becomes messy?”
- Hallucination is not one thing. In a medical, legal, financial, or investment workflow, it is a defect. In a labelled creative mode, it can be a feature. Revolutionary stuff: context matters.
- Goal-directedness is also not one thing. More goal pursuit can improve execution, but it also raises safety and governance questions.
- The sensible business pattern is not “deploy an autonomous AI analyst and hope it behaves”. It is mode governance: separate factual, creative, and decision-support modes with different metrics, interfaces, and controls.
- High-stakes workflows need scaffolding: memory, rule extraction, refinement loops, ensemble checks, scoring, audit trails, and humans who can edit policy rather than merely admire the model’s prose.
AI products are currently being sold with a suspiciously convenient promise: one conversational interface will reason, search, write, create, decide, advise, analyse, and maybe spiritually support the quarterly planning meeting if procurement approves the invoice.
The trouble is that these behaviours are not the same behaviour.
A model that invents surreal images for an immersive theatre installation is doing something very different from a model screening startup investments. A model that knows how to measure a variable in isolation may still fail to use that capability when the variable is only step one in a longer plan. A model that explains its decision fluently may still be wrong, overconfident, or built on a rule nobody in the business has agreed to use.
Three recent arXiv papers help clarify this mess. One evaluates whether LLMs actually pursue a stated goal by comparing their composite-task behaviour with their measured sub-capabilities.1 Another proposes deliberately inducing hallucination for creative and mixed-reality contexts, but only where users understand they are entering an imaginative mode.2 A third builds a memory-augmented decision framework for startup evaluation, turning LLM reasoning logs into explicit rules and refining them through multi-step scaffolding.3
Taken together, they do not say, “LLMs are now agents.” Nor do they say, “Hallucination is secretly good.” Nor, thank mercy, do they say, “AI can now pick unicorns from LinkedIn profiles.”
They say something more useful: LLM systems need operating modes.
The shared problem: raw output is not a workflow
The common thread across the three papers is not hallucination alone, or agency alone, or decision support alone. It is the gap between model output and usable behaviour.
That gap appears in three forms:
| Paper role | What it studies | What it reveals | Business translation |
|---|---|---|---|
| Diagnostic foundation | Goal-directedness in LLMs | Models may have a capability but fail to deploy it in a larger task | Do not confuse demo capability with operational reliability |
| Creative boundary case | Deliberately induced hallucination | Non-factual output can be useful when framed as imagination | Separate creative exploration from factual service |
| Applied scaffold | Startup decision support | Reasoning can be distilled into explicit, editable rules | High-stakes AI needs controls, not just fluent explanations |
This is a complementary chain. First, diagnose whether the model pursues the stated objective. Then classify whether the context tolerates imaginative deviation. Then scaffold the workflow so reasoning becomes inspectable, correctable, and governed.
That chain matters because many enterprise AI deployments currently collapse these categories. A single model is asked to “think creatively”, “be accurate”, “make recommendations”, “explain its reasoning”, “avoid hallucinations”, and “move fast”. This is not a product strategy. It is a wish list wearing a roadmap badge.
Step one: measure whether the model actually pursues the goal
The goal-directedness paper begins with a simple but uncomfortable question: to what extent do LLMs use their available resources and capabilities towards a given goal?
That distinction matters. A model might be able to estimate noisy measurements when asked directly. It might be able to evaluate configurations. It might be able to execute a plan. But when those capabilities need to be combined inside a longer task, the model may underuse them.
The authors define goal-directedness as the model’s propensity to use available resources and capabilities to achieve a given goal. They evaluate this in a Blocksworld environment where models must perform tasks such as gathering information, expending cognitive effort, planning, executing, and combining these subtasks. The clever part is that they estimate the model’s relevant capabilities separately, then compare actual composite-task performance against what would be expected if the model fully used those capabilities.
In plain business English: they do not merely ask whether the model succeeded. They ask whether it tried properly, given what it demonstrably knows how to do.
That is a different metric.
The paper’s results are not a comforting bedtime story for agent vendors. The authors find that most tested models are not fully goal-directed. In particular, models often take fewer noisy measurements when height estimation is merely a subtask inside a larger goal than when height estimation is the entire task. The model can know that repeated measurement improves accuracy and still move on too early when the larger workflow begins tugging at its sleeve.
This should feel familiar to anyone who has watched an LLM summarise a contract beautifully, then skip the one clause that mattered.
The key lesson is that capability tests are insufficient. If your AI procurement checklist asks only whether the model can perform subtasks, you are measuring ingredients, not cooking. The operational question is whether the model reliably uses those ingredients when the task has dependencies, distractions, uncertainty, and competing incentives.
What the paper shows
The paper shows that goal-directedness can be separated from task performance. A model with imperfect raw capability can still be highly goal-directed if it uses that capability fully. Conversely, a capable model can score poorly if it fails to apply its own strengths inside a broader task. The authors also report that goal-directedness appears relatively consistent across several tested tasks and only moderately responsive to motivational prompting.
Business interpretation
For operators, the lesson is not “make models more goal-directed at all costs”. That would be delightfully reckless. Stronger goal pursuit can make systems more useful, but it also connects to the safety concern that a system may pursue objectives in ways users did not intend.
The better takeaway is diagnostic: before deploying an LLM agent, test whether it persists, gathers enough information, uses known tools, revisits uncertain assumptions, and executes subgoals in the correct order.
A useful enterprise metric might look less like:
Accuracy on isolated benchmark tasks.
And more like:
Capability utilisation under composite workflow conditions.
That is less glamorous than a leaderboard score. It is also closer to how work actually works.
Step two: decide whether hallucination is defect or design material
The second paper turns the usual hallucination conversation sideways. Its proposed system, Purposefully Induced Psychosis, or PIP, deliberately encourages surreal, metaphorical, speculative outputs through fine-tuning and prompt-level control. The authors apply this to creative writing, interactive storytelling, and mixed-reality simulations.
The title is intentionally provocative. The underlying product question is less theatrical: when should non-factual generation be allowed?
In most business workflows, hallucination is a failure. If an AI system fabricates a compliance requirement, invents a supplier’s certification, or creates a fake financial ratio, nobody should praise its “computational imagination”. That is not creativity. That is liability with adjectives.
But the PIP paper argues that in explicitly creative settings, hallucination can be reframed as imagination. The system fine-tunes a small Llama model on a dataset of creative instruction-following pairs designed to evoke metaphor, speculation, and surreal reasoning. The mixed-reality prototype then uses the model’s outputs to generate immersive objects and experiences. The paper also reports preliminary observations from a small early-user group, who found the system’s surreal suggestions creatively generative, though the authors do not present this as a formal quantitative evaluation.
The paper’s strongest practical contribution is not the claim that hallucination is good. It is the insistence that hallucination needs a boundary.
The authors discuss consent, labelling, and mode separation. They explicitly distinguish creative environments from high-stakes domains such as law or medicine. They also suggest separate imaginative and factual modes so users understand which norm they are operating under.
That is the point businesses should steal.
Not the branding. Please do not name your customer-support bot “Purposefully Induced Psychosis”. Legal will age visibly.
What the paper shows
The paper presents a design prototype and conceptual framework for harnessing non-factual generation in creative contexts. It shows how fine-tuning, prompt controls, a secondary structuring model, and XR components can turn surreal LLM output into an interactive experience. Its evidence is exploratory, not definitive.
Business interpretation
The paper is useful because it prevents a common overcorrection. Some organisations treat hallucination as a universal contaminant and try to eliminate all generative looseness. Others, usually after a keynote with too much fog machine, celebrate “AI creativity” without sufficient boundaries.
Both are clumsy.
The practical distinction is mode-specific tolerance:
| Mode | Output norm | Hallucination tolerance | Main control |
|---|---|---|---|
| Factual mode | Verifiable, sourced, conservative | Very low | Retrieval, citations, refusal, verification |
| Creative mode | Novel, exploratory, speculative | High, if labelled | Consent, framing, user control |
| Decision-support mode | Structured, justified, reviewable | Low | Rules, scoring, audit, human review |
A creative agency may want a model to produce strange metaphors, unexpected concepts, and speculative prompts. A bank does not want its risk engine to “taste the colour of liquidity exposure”. One hopes.
The same base model family can support both use cases, but the product must make the operating mode explicit. Users should not have to infer whether the system is currently telling the truth, brainstorming, or making a recommendation under uncertainty.
That interface ambiguity is where hallucination becomes dangerous.
Step three: scaffold high-stakes reasoning into policy
The third paper, R.A.I.S.E., moves into applied decision support. It proposes a framework for startup evaluation that combines LLM reasoning with structured decision rules. The system ingests founder profiles, company descriptions, and outcome labels; generates reasoning logs; extracts logical rules; compiles those rules into decision policies; then uses the policy to predict startup success on a test set.
The system adds several scaffolds: two-step refinement, ensemble candidate sampling, simulated reinforcement-learning-style scoring, and persistent memory. The combined pipeline reportedly improves precision from 0.225 to 0.346 and accuracy from 0.467 to 0.700 compared with a standalone o3-mini baseline on the authors’ curated test setup.
These numbers should be interpreted carefully. Precision of 0.346 is not “AI has solved venture capital”. It is more like “we have reduced some obvious false-positive chaos while keeping the process interpretable”. Which, in venture capital, may already qualify as cultural progress.
The paper is valuable because it treats reasoning as something to be converted into policy, not merely displayed as prose.
That matters. A chain-of-thought-like explanation is not governance. It may be persuasive. It may be coherent. It may even be useful. But until it is turned into rules, checked against outcomes, refined, versioned, and made editable by domain experts, it remains a performance of reasoning rather than a managed decision process.
What the paper shows
The paper shows that a modular LLM decision pipeline can improve reported metrics over a baseline in a curated startup-evaluation task. It also shows the value of persistent memory, ensemble sampling, simulated scoring, and explicit decision policies in reducing false positives and improving interpretability.
The authors are also clear about remaining work: deeper reasoning verification, human-edited policies, stability testing across domains, adaptive policy documentation, executable rules, hallucination detection, and cost optimisation.
Business interpretation
The R.A.I.S.E. framework points to the architecture high-stakes AI actually needs:
- Generate reasoning.
- Distil reasoning into explicit rules.
- Apply rules to new cases.
- Score outcomes against known labels.
- Refine policies.
- Preserve useful memory.
- Let humans inspect and edit the policy.
That sequence is not limited to startup investing. It maps to hiring, underwriting, grant selection, supplier screening, incident triage, procurement risk, and any workflow where judgement is necessary but opaque automation is unacceptable.
The system is not a substitute for expert judgement. It is closer to a policy workbench: a machine-assisted way to turn fuzzy expert reasoning into a living decision document.
That is much more interesting than yet another chatbot that says, “Based on my analysis…” before confidently walking into a rake.
The combined lesson: mode governance
Put the three papers together and the larger conclusion becomes clear.
LLM deployment should not be designed around a single generic assistant. It should be designed around operating modes, each with distinct goals, acceptable error patterns, controls, and metrics.
Here is the resulting governance stack:
| Layer | Core question | Failure if ignored | Practical control |
|---|---|---|---|
| Behavioural diagnosis | Does the model use its available capabilities towards the stated goal? | Capability demos overstate real workflow reliability | Composite-task testing, subtask benchmarking, persistence checks |
| Context classification | Is this a factual, creative, or decision-support task? | Hallucination is either over-suppressed or dangerously tolerated | Explicit modes, labelling, user consent, UI boundaries |
| Reasoning scaffold | Can outputs be inspected, corrected, and reused? | Fluent explanations masquerade as governance | Rule extraction, memory, ensemble checks, scoring |
| Human control | Who can revise the policy and override the model? | Automation becomes brittle or unaccountable | Editable policies, audit trails, expert review |
| Performance monitoring | What metric reflects the real business risk? | Optimisation targets the wrong behaviour | Precision, recall, false-positive cost, capability utilisation |
This is not an anti-agent argument. It is an anti-mush argument. The enterprise does not need a vague intelligent blob. It needs systems whose behavioural expectations are explicit.
A factual assistant should be conservative, source-bound, and willing to say it does not know.
A creative assistant should be allowed to roam, but behind a clearly marked gate.
A decision assistant should be structured, auditable, and corrigible. It should not merely generate an answer; it should expose the policy path that produced the answer.
What managers should do with this
The practical implication is to stop writing AI requirements as personality traits.
Bad requirement:
The AI should be accurate, creative, proactive, reliable, transparent, and strategic.
This is how one accidentally designs a committee.
Better requirement:
The system must support three operating modes: factual retrieval, creative ideation, and decision support. Each mode must have separate success metrics, hallucination tolerance, UI labelling, audit requirements, and escalation rules.
That sounds less magical because it is more operational. Good.
1. Test goal pursuit under realistic task chains
Do not only test whether a model can perform isolated tasks. Test whether it performs the right subtasks in the right order when the workflow contains uncertainty.
For example:
- Does it gather enough information before recommending?
- Does it revisit assumptions when new data arrives?
- Does it use available tools consistently?
- Does it stop too early?
- Does it degrade when the task becomes multi-step?
- Does it confuse “finishing” with “solving”?
This is especially important for agentic workflows. A model that can write a good email, search a database, and update a CRM may still fail at the composite task of qualifying a lead without skipping verification.
2. Label creative deviation as creative deviation
If you want imagination, ask for imagination. Put it in a creative mode. Use interface labels, disclaimers, toggles, and output styling that make the fictionality obvious.
The user should know whether the AI is:
- producing verified information,
- generating speculative ideas,
- simulating scenarios,
- or recommending action under uncertainty.
This is not merely ethical polish. It is product hygiene.
3. Turn reasoning into editable policy
For high-stakes workflows, do not stop at explanations. Explanations are useful, but they are not enough.
Ask:
- Can the reasoning be distilled into rules?
- Can those rules be reviewed by experts?
- Can the rules be tested against historical cases?
- Can the model’s false positives and false negatives be analysed?
- Can policy changes be versioned?
- Can the business override the model without breaking the workflow?
The strongest version of LLM decision support is not an oracle. It is a structured decision process with a model inside it.
4. Optimise for the cost of being wrong
Different modes have different error economics.
In creative brainstorming, a false idea may be cheap and even useful. In investment screening, a false positive can waste diligence time or capital. In medical or legal advice, a hallucination can cause direct harm. In customer support, a fabricated policy can create contractual and reputational mess.
So the metric must follow the business risk.
Accuracy alone is usually too blunt. Precision, recall, calibration, false-positive cost, escalation rate, correction latency, and auditability may matter more.
5. Keep the human in the loop where judgement carries consequences
Human-in-the-loop should not mean “a person reads the AI output after the decision has effectively been made”. That is theatre. Not even good theatre.
A serious human-in-the-loop design gives experts real control:
- review extracted rules,
- edit policy,
- approve deployment,
- inspect borderline cases,
- reject model rationales,
- and feed corrections back into the system.
The goal is not to preserve human dignity through decorative approval buttons. The goal is to prevent brittle automation from quietly becoming policy.
The boundary conditions
The papers are useful, but their limits matter.
The goal-directedness paper uses controlled Blocksworld tasks. That is a strength for isolating behaviour, but it is not the same as measuring enterprise agents across messy real-world workflows.
The PIP paper is a creative prototype with preliminary user observations. It is a design argument, not evidence that induced hallucination improves creativity across populations or settings.
The R.A.I.S.E. paper reports promising improvements, but on a curated startup-evaluation benchmark with modest final precision. Its framework is best read as a scaffolded decision-support pattern, not as proof that LLMs can reliably identify future unicorns. If that were solved, the paper would presumably be a fund, not a PDF.
These limits do not weaken the combined lesson. They sharpen it.
The lesson is not that any one technique is deployment-ready everywhere. The lesson is that LLM behaviour must be governed by context, measured by the right behavioural property, and wrapped in explicit workflow controls.
The operator’s checklist
Before deploying an LLM workflow, ask these questions:
| Question | Why it matters |
|---|---|
| What mode is this: factual, creative, or decision-support? | Prevents users from confusing imagination with verification |
| What kind of hallucination is tolerable here? | Aligns system behaviour with risk |
| What capability must the model actually use, not merely possess? | Avoids overtrusting isolated benchmark performance |
| What is the cost of false positives and false negatives? | Selects the right evaluation metric |
| Can reasoning be converted into policy? | Makes decisions inspectable and improvable |
| Who can edit or override the policy? | Keeps accountability outside the model |
| How will the system detect drift, shortcuts, or premature stopping? | Monitors real workflow reliability |
If a vendor cannot answer these questions, they are not selling a governed AI system. They are selling a talking interface with optimism attached.
The crossroads
The phrase “AI hallucination” has become too overloaded to be useful on its own. So has “agentic”. So has “reasoning”. These words now carry more marketing weight than diagnostic precision.
The three papers, read together, push us towards a better vocabulary.
A model can be capable without being sufficiently goal-directed.
A hallucination can be harmful in factual mode and useful in creative mode.
A reasoning trace can be persuasive without being governed.
A decision-support system can improve when its reasoning is distilled, scored, remembered, and made editable.
This is the crossroads of reason: businesses must decide not only what they want models to output, but what mode of behaviour they are licensing.
The future of enterprise AI will not be won by the company with the most charming chatbot. It will be won by the company that knows when its AI should verify, when it should imagine, when it should decide, and when it should shut up and ask for review.
A radical concept, admittedly.
But an excellent one.
Cognaptus: Automate the Present, Incubate the Future.
-
Tom Everitt, Cristina Gârbacea, Alexis Bellot, Jonathan Richens, Henry Papadatos, Simeon Campos, and Rohin Shah, “Evaluating the Goal-Directedness of Large Language Models,” arXiv:2504.11844, 2025. ↩︎
-
Kris Pilcher and Esen K. Tütüncü, “Purposefully Induced Psychosis (PIP): Embracing Hallucination as Imagination in Large Language Models,” arXiv:2504.12012, 2025. ↩︎
-
Jack Preuveneers, Joseph Ternasky, Fuat Alican, and Yigit Ihlamur, “Reasoning-Based AI for Startup Evaluation (R.A.I.S.E.): A Memory-Augmented, Multi-Step Decision Framework,” arXiv:2504.12090, 2025. ↩︎