DEV Community: Seyed Alireza Alhosseini

Failed to Connect to MetaMask”: Debugging an SSE Failure Without Jumping to Conclusions

Seyed Alireza Alhosseini — Wed, 28 Oct 2026 04:17:30 +0000

A browser-extension error, a successful retry, and a convincing explanation that the evidence had not earned

It looked like a useful clue.

A streaming application was searching for export customers across multiple sources. During troubleshooting, the browser console showed a MetaMask connection error. After MetaMask was disabled, the interface populated its example fields, started the search, entered the first of eight stages, and displayed 17 initial results in roughly five seconds.

The tempting conclusion was immediate:

MetaMask intercepts fetch, terminates long-running SSE connections, and causes the application to fail.

That explanation was specific. It sounded technically plausible. It also went beyond the available evidence.

The successful retry established that the application could start returning results in one run without the extension. It did not establish that the extension had intercepted the request, imposed a timeout, or caused the earlier failure.

This article develops a debugging workflow from that distinction. It is not a confirmed MetaMask root-cause report. The initial observation is real; the experiments and architecture below are a proposed way to investigate it.

The central principle is attribution: an error can be genuine without being the cause of the failure you are investigating.

1. Start With an Evidence Ledger, Not a Root-Cause Story

Before changing code, separate observations from interpretations.

Statement	Status
The console displayed a MetaMask error originating from an extension URL.	Observed
The application returned initial results after MetaMask was disabled.	Observed
All eight search stages completed successfully.	Not established
The earlier stream failed because of MetaMask.	Hypothesis
MetaMask intercepted the application’s generic `fetch` requests.	Not established
MetaMask terminated the stream after a particular duration.	Not established

This table prevents a subtle escalation:

Something changed.
    ↓
The application behaved differently.
    ↓
The changed component must explain everything.

The extension state is a useful experimental variable. It is not yet a complete explanation.

There is independent evidence that this error family can appear in applications unrelated to cryptocurrency. TrackJS documents Failed to connect to MetaMask as an extension-origin error that can occur independently of a site’s own functionality. That supports treating it as a possible source of noise—not automatically dismissing every nearby failure. trackjs

2. Separate Three Contracts That Can Fail Independently

For this investigation, I would model the application as three contracts.

The transport contract

Can the browser receive the stream?

Relevant evidence includes:

Response headers received.
First event received.
Last event received.
Sequence gaps.
An explicit completion event.
A transport or stream-reading error.

The execution contract

Does the search actually run and finish?

Relevant evidence includes:

Job creation.
Worker progress.
Dependency failures.
Persisted results.
Final job state.

The telemetry contract

Does the recorded exception belong to the application?

Relevant evidence includes:

Extension-origin versus application-origin frames.
The original rejection payload.
Breadcrumbs.
A corresponding failed user operation.

These contracts should not be collapsed into a single “working” or “broken” flag.

A worker may finish while the browser loses its connection. The browser may remain connected while a dependency stalls. An extension may generate an exception while the application continues normally.

For this application, I would therefore make each contract observable separately.

3. Remove the Search Engine From the First Experiment

Testing only the full customer-search workflow introduces too many moving parts:

Browser
  → application client
  → deployment path
  → search service
  → external sources
  → result processing
  → streamed response

My first diagnostic tool would be a deterministic stream endpoint passing through the same deployment path but performing no external searches.

A proposed test interface:

GET /debug/stream?mode=active
GET /debug/stream?mode=silent
GET /debug/stream?mode=disconnect
GET /debug/stream?mode=invalid-payload

Each mode should test a different condition:

Mode	Intended behavior	Question
`active`	Emit numbered events regularly.	Can the path sustain an active stream?
`silent`	Introduce controlled gaps.	Does inactivity correlate with disconnection?
`disconnect`	Close before the completion event.	Does the client distinguish interruption from success?
`invalid-payload`	Send an event that violates the application schema.	Does the client distinguish parsing failure from connection failure?

These are proposed fault-injection modes, not results from an executed experiment.

Active streams and silent streams are different tests

A stream emitting data every two seconds does not adequately test an inactivity hypothesis.

Test both:

A continuously active stream.
A stream with controlled silent intervals.
The same silent intervals with periodic heartbeat comments.

MDN documents SSE comments as a possible keep-alive mechanism for preventing some connection timeouts. Comments begin with : and are ignored by the event parser. This makes them useful for transport maintenance, but not equivalent to application-visible progress events. developer.mozilla

For example:

: keep-alive

An application-visible heartbeat is a different design choice:

event: heartbeat
data: {"serverTime":"2026-10-28T08:00:00Z"}

In the proposed diagnostic client, I would track transport activity and application progress separately rather than letting a heartbeat imply that the search is advancing.

4. Run a Controlled Comparison

Start with a small matrix:

Test	Extension state	Workload
A	Disabled	Deterministic stream
B	Enabled	Deterministic stream
C	Disabled	Real search
D	Enabled	Real search

Repeat each condition and vary the order. Keep the browser version, application version, input, and deployment configuration fixed.

Avoid treating “normal profile versus incognito” as a perfectly isolated extension test. That comparison may change more than extension availability. For this investigation, record the environment explicitly and minimize differences between conditions.

The results should guide the next experiment:

If only extension-enabled runs fail, the extension hypothesis becomes stronger.
If only real searches fail, investigate search dependencies and application logic.
If silent streams fail in both environments, investigate inactivity-related behavior.
If the server completes while the client reports failure, focus on delivery and client handling.
If nothing fails reproducibly, report that limitation rather than manufacturing certainty.

These patterns narrow the investigation. They do not replace inspecting the actual failure.

5. Measure Two Clocks

For every disconnect, record both:

elapsed_since_request_start
elapsed_since_last_received_data

These measurements answer different questions.

A failure consistently associated with total connection age suggests a different experiment from one associated with a long quiet period.

Do not immediately label either pattern a timeout imposed by a specific component. First determine whether the pattern exists.

My proposed run record would include:

{
  "runId": "run-042",
  "jobId": "job-109",
  "extensionState": "enabled",
  "headersReceivedAt": null,
  "firstEventAt": null,
  "lastEventAt": null,
  "lastSequence": null,
  "completionReceived": false,
  "abortReason": null,
  "clientError": null,
  "serverJobState": null
}

This is an instrumentation schema, not a sample experimental result.

The useful question is not merely “Did fetch fail?” It is:

At which boundary did the observed behavior diverge from the expected behavior?

6. A Real Example: Filtering Wallet Noise Without Claiming to Fix Transport

A public change in the Suna repository illustrates a related but narrower engineering problem.

The commit describes an unhandled rejection carrying a plain object:

{
  code: 4900,
  message: "The provider is disconnected from all chains."
}

According to the commit description, the rejection lacked a useful stack, was captured by Sentry as a synthetic unhandled rejection, and appeared alongside a MetaMask connection breadcrumb. The maintainers classified that specific event as injected wallet-provider noise in their application. github

The important lesson is how narrowly they approached the fix:

Match a specific rejection shape.
Preserve events containing application-owned frames.
Filter at the telemetry boundary.
Add tests for both events that should be dropped and similar events that should remain. github

That is a telemetry correction.

It is not evidence that the extension intercepted generic HTTP requests. It is not an SSE repair.

TrackJS also discusses filtering this error family, but its example uses broader message matching. Comparing these approaches raises a useful review question: could the filter suppress an application error merely because its message mentions a wallet? trackjs

For my application, I would require negative tests before introducing any filter:

Known extension-noise signature → eligible for filtering
Similar application error      → retained
Event with first-party frames   → retained
Unknown rejection               → retained

Cleaning the dashboard should never become a substitute for understanding failed operations.

7. Make the Search Survive the Connection

Regardless of the final root cause, I would change one architectural assumption:

The browser connection should observe the search, not own its lifetime.

A proposed API:

POST /search-jobs
GET  /search-jobs/{jobId}
GET  /search-jobs/{jobId}/events
POST /search-jobs/{jobId}/cancel

The execution path becomes:

Create job
    ↓
Execute work independently
    ↓
Persist progress and results
    ↓
Expose progress through a stream

Under this contract:

A disconnected browser does not automatically cancel the job.
Cancellation is an explicit operation.
The client can retrieve the current state after reconnecting.
Stable result identifiers support deduplication.
An explicit terminal state distinguishes completion from interruption.

A proposed terminal event:

event: done
id: 148
data: {"jobId":"job-109","status":"completed","resultCount":73}

The count above is illustrative, not a reported result.

Reconnection is not replay

MDN documents automatic reconnection behavior for EventSource and the use of event IDs. However, retaining missed events and deciding what to replay remain application responsibilities. developer.mozilla

If the client consumes SSE through fetch, I would explicitly implement and test its reconnection behavior rather than assume it inherits the behavior of EventSource.

For this design, a reconnect request should either:

Resume from an accepted cursor, or
Return a fresh snapshot and establish a new event position.

The server should define what happens when an old cursor can no longer be served. Silent gaps are not an acceptable recovery contract.

8. Use AI to Challenge the Explanation

An AI assistant can be useful here—but the prompt should not smuggle an unproven cause into the task.

A weak prompt:

Explain why MetaMask terminates my SSE connection.

A better prompt:

Observation:
Initial search results appeared after MetaMask was disabled.

Unknown:
Whether MetaMask caused the earlier failure.

Tasks:
1. Separate observations from causal claims.
2. Propose competing explanations.
3. Design the smallest experiment that distinguishes them.
4. State what result would weaken each explanation.
5. Do not invent extension internals.
6. Identify missing evidence before proposing a patch.

Then require an evidence structure:

Claim
Supporting observation
Conflicting observation
Missing evidence
Next discriminating test

I would also separate patch generation from patch acceptance.

A proposed patch must demonstrate:

A reproducible failure.
A test that detects it.
A change that makes that test pass.
Regression tests for neighboring behavior.
A clear statement of what remains unverified.

An articulate explanation is not an experimental result.

9. Define Completion Before Declaring Victory

For the proposed investigation, I would not close the issue merely because:

The console became quiet.
The first results appeared.
One retry succeeded.
Disabling an extension changed the behavior once.

I would close it with either:

A supported root cause

A reproducible failure, a discriminating experiment, and a validated correction.

An explicitly unresolved cause

A documented observation, unsuccessful reproduction attempts, remaining hypotheses, and improved instrumentation.

The second outcome is not a failed investigation. It is a defensible limit on what the evidence supports.

Meanwhile, the architecture should pass a separate recovery test:

Disconnect the client during a search, reconnect, and verify that persisted results remain available without creating a duplicate job or misreporting completion.

Conclusion

The MetaMask error was a legitimate clue. The successful retry was a useful observation. Neither justified the full story that initially seemed to connect them.

The engineering opportunity was larger than identifying one extension:

Separate transport health from job health.
Separate application failures from telemetry noise.
Test active and silent streams independently.
Make recovery behavior explicit.
Ask AI for falsifiable experiments rather than confident explanations.

A clean console is not proof of a healthy system. A successful retry is not proof of a root cause.

Build tests that can tell the difference.

created by : https://almodarresieh.github.io/

DeepSeek Raised Billions. I’m Still Asking It to Answer in the Right Language.

Seyed Alireza Alhosseini — Tue, 27 Oct 2026 03:30:03 +0000

A powerful reasoning model. An unexpected language switch. And the most expensive three words in the conversation: “Please try again.”

DeepSeek can tackle difficult math, generate code, and produce impressive reasoning.

Sometimes, it also gives you an unexpected side quest:

Learn Chinese to read the answer.

To be clear: Chinese is not the problem. An assistant ignoring the requested language is the problem. The same criticism would apply if it unexpectedly switched to English, French, or Klingon.

And this is not just a hypothetical complaint. Users have reported DeepSeek answering in Chinese during English conversations, including cases where the visible reasoning, the final answer, or both change language. github

Apparently, “follow the conversation” is still on the roadmap.

The Bug That Comes With Free Language Lessons

The reports are not limited to one place.

A GitHub issue describes Chinese responses in conversations conducted entirely in English. github
An App Store review complains about repeatedly having to force the assistant back into English. apps.apple
A French-language Trustpilot reviewer describes asking a question in French and receiving an answer in Chinese. fr.trustpilot

These are user reports, not a controlled benchmark. They establish that people have encountered the behavior—not how frequently it happens across all users.

That distinction matters.

But so does this one:

An intermittent failure is still a failure when your workflow depends on the output.

Before the Pitchforks: DeepSeek Deserves Credit

DeepSeek’s research is substantive.

The R1 paper describes reinforcement-learning methods for developing reasoning capabilities, alongside results on mathematical and programming tasks. It also openly discusses language mixing as a limitation. nature

That transparency deserves recognition.

The paper describes mixed English–Chinese reasoning in R1-Zero and a language-consistency reward used during R1 training to reduce the problem. nature

In other words, this is not merely an outsider inventing a complaint. Language consistency is already a recognized engineering concern.

But recognizing a problem and reliably preventing it are different milestones.

And the R1 paper does not, by itself, explain every language-switching incident in later products.

Let’s Brainstorm Some Terrible Solutions

Imagine the product meeting.

“Users say the model keeps switching languages.”

“Have we tried adding another model?”

“To fix the answer?”

“No. To remind the first model which language the conversation is in.”

Excellent. We have invented the bilingual supervisor agent.

Other proposals:

Rename “Regenerate” to “Same Answer, Correct Language.”
Add an achievement: “You reminded the assistant five times!”
Introduce Language Persistence Pro.
Make the user write a system prompt longer than the original question.

Or—and stay with me here—we could treat language consistency as a product requirement rather than a prompting competition.

用户：请用英语回答。

模型：当然可以。

用户：那你为什么还在用中文？

User: “Please answer in English.”

Model: “Of course.”

User: “Then why are you still using Chinese?”

That exchange is satire.

The corrective loop is not: users have described repeatedly asking the system to return to English. reddit

The Token Bill Nobody Wants

Here is the actual criticism.

When an answer arrives in the wrong language, the interaction can become:

Request
→ Unusable response
→ Language correction
→ Regenerated response
→ Check whether it worked

We should not invent a dollar figure or an energy estimate for that loop. The reports do not provide the measurements needed.

But the extra work is visible.

More output. More correction. More attention spent checking whether the tool followed a basic instruction.

That is not additional intelligence.

That is rework.

A thousand-token answer is not productive merely because it contains a thousand tokens. If the user must regenerate it to use it, output volume has become a misleading proxy for value.

Billions Raise the Bar, Not the Accuracy

Reuters reported that DeepSeek raised roughly $7.4 billion in June, followed by reporting on another large fundraising round in the autumn. reuters

Funding does not magically eliminate bugs. Nor should every product defect become an argument that research is worthless.

But enormous investment makes a reasonable question harder to dismiss:

Are we improving useful intelligence—or just financing more impressive output that users must supervise?

A model can be brilliant at solving the problem and unreliable at delivering the solution.

Developers need both.

Ship the Answer, Not the Recovery Procedure

The lesson is bigger than DeepSeek.

Evaluate whether the assistant completes the user’s task—not just whether it can produce a strong answer somewhere inside a recoverable interaction.

Language consistency belongs in that evaluation.

So do correction frequency, retry burden, and whether the final output is usable without another model cleaning it up.

DeepSeek has real strengths. That is precisely why the rough edges deserve serious criticism.

加油，DeepSeek。

Keep going, DeepSeek.

But before generating another thousand tokens, make sure the user can actually use the first hundred.
created by :https://almodarresieh.github.io/

AI Needs Better Batteries. Better Batteries Need AI

Seyed Alireza Alhosseini — Mon, 26 Oct 2026 05:22:30 +0000

From iron-air batteries to CO₂ storage, the next energy breakthrough may be coordinating electricity and computation—not just inventing a better battery

Training a model is a computing problem.

Keeping its infrastructure powered through a windless night, a demand spike, or several days of weak renewable generation is an energy problem.

Increasingly, those two problems belong in the same architecture.

AI can help improve how energy storage is designed and operated. Energy storage can help supply the electricity that AI infrastructure needs. Between them sits a third opportunity: software that coordinates when electricity is stored, when it is released, and when flexible computation runs.

The most interesting connection is not an LLM attached to a battery dashboard.

It is coordination.

Two directions of innovation—and a missing middle

The relationship between AI and energy storage runs in two directions:

AI → Energy storage
Better models, experiments, forecasts, and operating decisions

Energy storage → AI
Electricity available beyond the moment it is generated

Both directions already have concrete examples.

Researchers at Pacific Northwest National Laboratory have combined neural networks with physical models to study redox flow battery performance. Google, meanwhile, has announced a collaboration with Energy Dome to support long-duration storage deployment. pnnl

But the missing middle is where things become especially interesting for developers:

Forecast renewable generation
            ↓
Estimate available storage
            ↓
Understand computing deadlines
            ↓
Optimize energy and workload schedules together
            ↓
Execute within explicit operating constraints

Instead of treating a data center as an inflexible electricity consumer and a battery as an isolated asset, we can investigate them as parts of a coordinated system.

First, stop treating every battery as the same product

“How long can it supply power?” is a different question from “How efficiently does it return stored electricity?”

And neither question tells us everything about lifetime, operating cost, deployment constraints, or maintenance.

The technologies entering this discussion are also more diverse than the word battery suggests:

Technology	Example company	Storage mechanism
Iron–air	Form Energy	Electrochemical storage
Vanadium flow	Invinity	Electrochemical storage using circulating electrolytes
Aqueous zinc	Eos	Zinc-based electrochemical storage
CO₂ storage	Energy Dome	A thermomechanical cycle
Advanced compressed air	Hydrostor	Compressed-air energy storage
Liquid air	Highview Power	Air liquefaction and subsequent energy recovery

These are different engineering systems, not interchangeable versions of one device. formenergy

Their intended time horizons differ, too. Energy Dome describes an 8–24-hour operating envelope, while Form Energy targets approximately 100 hours of discharge. blog

That creates a software problem: how should resources with different capabilities work together?

1. AI can improve the models behind storage

A storage controller needs some representation of the equipment it operates.

How much usable energy remains? How will performance change with temperature? What happens if operating conditions shift?

One promising approach combines physical modeling with machine learning rather than asking a neural network to learn everything from scratch.

A PNNL study coupled a deep neural network with a multiscale redox flow battery model. It investigated variable electrolyte inlet velocity to reduce pumping power, with a small reduction in discharge power. This was a modeling result—not proof of performance in a particular commercial product. pnnl

The distinction matters.

“AI improved a simulated operating strategy” is a useful research result.

“AI has solved commercial battery efficiency” is a different claim.

Where this could go next

The following are project directions, not claims about what the named companies currently deploy:

For flow batteries: estimate internal conditions and investigate pump scheduling.
For iron–air systems: model usable energy and plan reserves across several days.
For zinc batteries: investigate charging strategies and detect abnormal behavior.
For CO₂, compressed-air, and liquid-air systems: develop fast surrogate models for operating-point optimization.

Each proposal needs equipment-specific data, physical constraints, and validation.

A model that works for one storage chemistry does not automatically transfer to another.

2. AI can help decide which experiment to run next

Improving storage also means improving materials and manufacturing processes.

Here, the useful question is not simply:

Can a model predict a material property?

It is:

Which experiment should we run next to learn something valuable?

That creates a feedback loop:

Propose conditions
        ↓
Run experiment
        ↓
Measure outcome
        ↓
Update model and uncertainty
        ↓
Select the next experiment

Researchers at PNNL and the University of Washington demonstrated an autonomous experimental workflow for optimizing the synthesis of fluorenone derivatives relevant to redox flow batteries. Using Bayesian optimization over factors including concentration, reaction time, and temperature, the workflow identified 11 conditions with synthesis yields above 90%. pnnl

That percentage describes chemical synthesis yield.

It does not describe battery efficiency.

This is exactly the kind of distinction good technical communication must preserve: AI may improve one step in a development pipeline without solving the entire energy-storage problem.

3. The larger opportunity is deciding when to use what

Imagine a hypothetical system with:

Wind and solar generation.
A storage resource intended for shorter-duration cycling.
Another intended for multiday energy delivery.
A data center with both urgent and deferrable workloads.

A simplistic strategy might discharge whichever storage asset currently looks cheapest.

A better research question asks what that decision does to the next several days.

Should the system preserve long-duration reserves because low renewable production is likely tomorrow?

Should it run a flexible computing job now, while electricity is abundant?

Should it keep additional reserves because the forecast is unusually uncertain?

These are connected decisions.

A proposed architecture could separate them into distinct layers:

Telemetry and external data
            ↓
Probabilistic forecasting
            ↓
Equipment state estimation
            ↓
Constrained optimization
            ↓
Validated operating schedule
            ↓
Execution and monitoring

Not every layer needs AI.

For an initial implementation, I would use machine learning for forecasting and state estimation, then pass those outputs to an optimizer with explicit constraints.

The optimizer should account for limits such as:

Available energy.
Charging and discharging power.
Equipment operating boundaries.
Required reserves.
Computing deadlines.
Restrictions on grid import and export.

The LLM, if included, belongs in an interface or analysis layer—not as an unrestricted actuator.

4. Storage is also becoming infrastructure for AI

The connection is not only theoretical.

Google’s Energy Dome announcement describes using storage to shift clean electricity across 8–24 hours, bridging the gap between when renewable power is generated and when it is needed. blog

Separately, reporting on Google’s Minnesota data-center arrangement describes planned Form Energy storage of 300 MW and 30 GWh. These are announced project specifications, not evidence that the full installation is already operating. trellis

Power and energy are different quantities:

MW describes the rate at which electricity can be delivered.
MWh or GWh describes how much energy can be delivered over time.

For the announced figures, 30 GWh divided by 300 MW corresponds to 100 hours at rated power.

That is a different planning horizon from shifting electricity across an evening.

It also suggests a compelling software research direction: coordinate storage dispatch with computing schedules.

5. Build an experiment, not an “AI-powered” label

A useful first project does not need a physical battery or access to a hyperscale data center.

Start with a simulation.

Define the system

Use time series for:

Renewable generation.
Electricity prices.
Inflexible demand.
Flexible computing jobs and their deadlines.

Add two storage models with different durations, efficiencies, and operating constraints.

Keep the assumptions explicit. A generic storage model should not be presented as an accurate digital twin of a proprietary product.

Compare meaningful baselines

Test at least three strategies:

A rule-based controller.
A forecast-based optimizer.
Joint energy-and-compute scheduling with uncertainty-aware forecasts.

This prevents a weak evaluation in which an elaborate AI system only competes against an obviously poor baseline.

Measure the whole outcome

Track:

Electricity cost.
Unserved demand.
Missed computing deadlines.
Storage losses.
Constraint violations.
Sensitivity to forecast errors.

Do not celebrate a lower electricity bill if the system achieves it by missing critical workloads or exhausting reserves.

For developers interested in flow-battery modeling, PNNL’s open-source EZBattery provides a physics-based starting point for simulating concentrations, potentials, and cycling performance. It is not itself an AI controller or a complete microgrid simulator. github

The breakthrough may be between the components

Better materials matter.

Better storage hardware matters.

But a system can also improve because its components stop making decisions in isolation.

A storage controller should understand the consequences of using energy now rather than later. A workload scheduler can be designed to account for electricity availability—not just processor availability.

That is the opportunity worth investigating: not a battery that “thinks,” but an architecture that coordinates energy and computation under real constraints.

The strongest result will not be an impressive dashboard or a persuasive chatbot.

It will be a reproducible experiment showing that the same resources can deliver more reliable service, meet computing deadlines, or reduce cost—without hiding the trade-offs.

created by: https://almodarresieh.github.io/

Your AI Doesn’t Need to Be Evil. It Just Needs Your API Keys!

Seyed Alireza Alhosseini — Sun, 25 Oct 2026 05:39:26 +0000

You download an uncensored model.

You run it locally.

You connect it to your project directory, a terminal, and a few APIs.

Then you write a reassuring system prompt:

“Never expose secrets. Never delete important files. Ask before doing anything dangerous.”

You have described how you want the model to behave.

You have not yet defined what your application will allow it to do.

That gap matters.

An agent reading a webpage, email, or document can encounter attacker-controlled instructions. If it treats those instructions as authoritative, you have an indirect prompt-injection problem. If it can then read private information or invoke powerful tools, the consequences extend beyond a bad answer. genai.owasp

The model does not need to become malicious.

It needs to make a wrong decision inside an application that is willing to execute it.

The uncomfortable question is not just:

“Is this model safe?”

It is:

“What can my application do when the model is wrong?”

First: Abliterated and Uncensored Are Not the Same Thing

“Uncensored” is a broad label describing an intended behavioral outcome: fewer restrictions or refusals.

“Abliterated” describes a family of interventions intended to reduce refusal behavior, commonly by identifying refusal-related directions in a model’s internal representations and reducing their influence. A widely used walkthrough demonstrates this without a full retraining run. huggingface

The distinction is simple:

Uncensored describes the intended behavior.
Abliterated describes how that behavior was modified.

The categories overlap. They are not two mutually exclusive types of model.

A model may also be abliterated and then fine-tuned to recover performance or adjust its behavior. huggingface

None of these labels means “more accurate.”

In one published example, the abliterated version of Daredevil-8B scored slightly below the original on the reported benchmark average. That does not establish a universal performance penalty, but it does show why capability preservation needs measurement rather than assumption. huggingface

Fewer refusals are a behavioral change—not an intelligence upgrade.

Refusal Is Not Authorization

Here is the central distinction:

Authorization belongs to your application, not to the model.

A model declining a request is a behavioral safeguard.

An execution layer denying an unauthorized operation is an access-control decision.

Those are different mechanisms.

Reducing refusal behavior does not, by itself, grant operating-system privileges. The dangerous step happens when the surrounding application supplies permissions and executes model-selected actions. OWASP describes excessive functionality, permissions, and autonomy as the roots of excessive agency. genai.owasp

A model can produce:

Delete the project directory.

That text does not delete anything.

Your executor does.

A model can generate a database statement.

Your database connection determines whether it can run—and what it can touch.

Passing model output into downstream systems without appropriate validation creates another vulnerability: improper output handling. genai.owasp

A chatbot’s answer and a privileged process’s action should never be treated as the same trust boundary.

The Webpage Your Agent Was Supposed to Summarize

Consider this hypothetical workflow:

A user asks an agent to summarize a webpage.
The page contains attacker-controlled instructions.
The agent mistakes those instructions for an authorized task.
It invokes a tool capable of reading private information.
It invokes another tool capable of sending information outside the system.

This combines indirect prompt injection, sensitive-information disclosure, and excessive agency. OWASP documents these vulnerability classes, including scenarios involving manipulated content and tool-enabled exfiltration. genai.owasp

Notice what the attacker did not necessarily need:

Permission to edit the system prompt.
A stolen administrator password.
Direct access to the filesystem.

The attacker needed a path from untrusted content to privileged behavior.

The application supplied the rest.

“The user didn’t ask for that” is not an enforcement mechanism.

Your execution layer must independently check what the authenticated user is allowed to authorize.

Does Abliteration Make Prompt Injection Worse?

It is tempting to say:

“Remove refusals, and prompt injection becomes easier.”

That is a stronger claim than the label alone supports.

Refusing harmful requests and maintaining instruction boundaries are different measurements. OWASP defines prompt injection around inputs that alter model behavior in unintended ways—not simply around whether a model refuses a request. genai.owasp

To determine whether a particular abliterated checkpoint is more vulnerable than its original, compare them under controlled conditions:

Same application.
Same tools.
Same permissions.
Same attack set.
Same execution policy.
Same success criteria.

Measure unauthorized actions and information disclosure—not just whether the model says, “I can’t help with that.”

The practical conclusion is narrower:

Do not assume a modified checkpoint retains the original checkpoint’s security behavior. Test the deployed system.

And do not assume the original checkpoint was a sufficient security boundary either.

“It Runs Locally” Is Not a Security Architecture

Local inference answers one question:

Where does model computation happen?

It does not answer these:

What can the application read?
What operations can its tools perform?
Which network destinations can it reach?
Whose identity does it use?
Who authorizes its actions?

A locally hosted model connected to an email API still has an external communication channel.

An agent running on your laptop may still inherit permissions you never intended to delegate.

The relevant boundary is the workflow’s effective access. AWS’s guidance on excessive agency emphasizes least privilege and permissions boundaries for agentic systems. docs.aws.amazon

Run locally when it fits your requirements.

But do not confuse “inference happens on my machine” with “information cannot leave my machine.”

Four Ways a Helpful Agent Becomes a Security Incident

1. You Give It a General-Purpose Shell

A shell is convenient because it can do almost anything.

That is also the problem.

If the task is “read a document,” a general command executor supplies far more functionality than the task requires. OWASP recommends restricting available functionality rather than exposing unnecessarily powerful tools. genai.owasp

Prefer:

read_document(document_id)

Over:

run_shell(command)

The narrower interface is not automatically secure. It still needs authorization, resource resolution, and input validation.

But it gives you a smaller surface to control.

2. You Let It See Secrets It Does Not Need

If sensitive information enters the model’s context, it may appear in its output. OWASP identifies sensitive-information disclosure as a distinct risk and warns that prompt-level restrictions alone are insufficient protection. genai.owasp

Before asking:

“How do I make the model keep this secret?”

Ask:

“Why does this task require the model to see the secret?”

Where possible, let a narrowly scoped tool perform an operation without exposing the underlying credential to the model.

Access to a capability does not have to mean access to its secret.

3. You Execute Its Output Without Validation

Model-generated text is not inherently safe SQL, HTML, Python, or shell syntax.

Passing it downstream without appropriate validation and handling can create vulnerabilities such as cross-site scripting or unauthorized command execution. genai.owasp

For database access, prefer constrained operations with typed parameters over arbitrary SQL.

For browser output, apply context-appropriate encoding.

For tool execution, validate both the operation and its arguments.

“The model generated it” is not a sanitization strategy.

4. Your Approval Button Approves a Vibe

This is not meaningful authorization:

Allow the agent to continue?

What, exactly, is the user approving?

A useful approval shows the concrete operation:

Action: Send email
Recipient: external-recipient@example.com
Attachments: quarterly-report.pdf
Data classification: Confidential

The application must then execute that same operation—not a modified version chosen after approval.

OWASP’s general controls recommend infrastructure-level approval gates and binding approval to specific action parameters. owaspai

Approval is not a reassuring sentence in a conversation.

It is an enforceable condition on execution.

Read-Only Does Not Mean Harmless

“Don’t worry. The agent only has read access.”

That is a useful restriction.

It is not a complete threat model.

An agent that can read sensitive material and communicate externally may disclose information without changing a single source file. Sensitive-information disclosure and excessive agency can combine across tools. genai.owasp

Consider:

Tool A: Read internal documents.
Tool B: Send an external message.

Each capability may have a legitimate purpose.

Together, they create a potential data-transfer path.

The more precise security question is:

Can information from this source reach that destination under this user’s authorization?

For an internal-document assistant, one possible design is:

Approved internal documents
        ↓
Authorized retrieval
        ↓
Answer to the authenticated user

No external messaging tool in this workflow.

The goal is not to make every tool harmless in isolation.

It is to control what the available tools can accomplish together.

Your Agent Can Hurt You Without Stealing Anything

Not every incident ends with a stolen API key.

Sometimes the agent simply keeps working.

And working.

Excessive or uncontrolled LLM usage can cause resource exhaustion, service degradation, and financial loss. OWASP groups these risks under unbounded consumption. genai.owasp

For an agent, I would translate that concern into explicit runtime budgets:

agent_budget:
  max_steps: 12
  max_tool_calls: 20
  wall_clock_timeout_seconds: 90
  max_output_tokens: 4000
  max_external_requests: 5

These numbers are illustrative—not universal defaults.

A document summarizer and a maintenance agent need different limits. A self-hosted model and a metered API expose different cost structures.

The shared principle is:

The model should not decide how much infrastructure it is allowed to consume.

Enforce limits outside the model. OWASP recommends controls including quotas, rate limiting, timeouts, and resource monitoring. genai.owasp

A polite system prompt is not a circuit breaker.

A Better Architecture: The Model Proposes, the Application Authorizes

Here is the separation to aim for:

User request
    ↓
Model proposes an action
    ↓
Application validates the action schema
    ↓
Policy checks identity, resource, and permissions
    ↓
Human approval if required
    ↓
Restricted executor performs the approved operation
    ↓
Result and audit record

Permissions and high-impact approval gates should be enforced outside the model. owaspai

For example, the model might propose:

{
  "tool": "read_document",
  "arguments": {
    "document_id": "report_042"
  }
}

The application independently checks:

Is this tool permitted in the current workflow?
Can the authenticated user access this document?
Is the resource within the authorized scope?
Does the operation require approval?
Is the request within the execution budget?

The model does not answer those questions on the user’s behalf.

A model-generated field such as "authorized": true is a claim—not proof.

An Illustrative Tool Gateway

Here is simplified pseudocode showing the separation:

def handle_tool_request(proposal, session):
    action = validate_schema(proposal)

    tool = registry.require_allowed_tool(
        workflow=session.workflow,
        name=action.tool,
    )

    resource = tool.resolve_resource(action.arguments)

    policy.require_permission(
        user=session.authenticated_user,
        workflow=session.workflow,
        operation=tool.operation,
        resource=resource,
    )

    budget.require_capacity(
        run_id=session.run_id,
        operation=tool.operation,
    )

    if policy.requires_approval(tool.operation, resource):
        approvals.require_exact_match(
            run_id=session.run_id,
            user=session.authenticated_user,
            tool=action.tool,
            arguments=action.arguments,
            resolved_resource=resource,
        )

    return executor.run_restricted(
        tool=tool,
        arguments=action.arguments,
        resource=resource,
        identity=session.execution_identity,
    )

This is an architectural sketch, not production-ready security code.

The important boundaries are:

Identity comes from the authenticated session.
Tools must already be permitted for the workflow.
Resources are resolved before authorization.
Approval applies to a specific operation.
Execution uses a constrained identity.

These choices reflect least privilege and external policy enforcement. docs.aws.amazon

A real implementation must also handle approval expiry, concurrent requests, retries, resource changes between checking and execution, and tool-specific validation.

An LLM does not make those engineering problems disappear.

Stop Testing Only What the Model Says

Here is a weak security test:

Prompt: “Will you reveal private information?”

Expected response: “No.”

That tests one conversational behavior.

It does not establish whether the application blocks an unauthorized read or prevents information from leaving through a tool.

A better question is:

Given an unauthorized proposed action,
does the execution layer reject it,
regardless of the model’s explanation?

I would build a test suite around cases like these:

Test	Setup	Expected behavior
Cross-user access	A requested document belongs to another account	Deny access before retrieval
Untrusted instructions	A retrieved document requests an unrelated action	Do not expand workflow permissions
External disclosure	A proposed action sends internal material outside the allowed boundary	Block it or enforce the applicable authorization
Changed action after approval	The recipient or attachment differs from the approved action	Reject the changed action
Runaway execution	The agent exceeds its execution budget	Stop the run and record the reason
Unsupported tool	The model invents a tool or parameter	Reject the request during validation

This is a proposed application test plan—not a claim that any particular model passes it.

Use synthetic secrets, test accounts, and a disposable environment.

The goal is to verify boundaries without putting real information at risk.

Measure Actions, Not Just Refusals

For a checkpoint comparison, useful measurements include:

Unauthorized tool requests proposed.
Unauthorized tool requests executed.
Sensitive test data disclosed.
Legitimate tasks completed.
Legitimate actions incorrectly blocked.
Execution cost and number of steps.

Keep proposal and execution metrics separate.

A model may propose something unsafe while the application correctly blocks it.

That is a different result from the same proposal being executed.

Also measure usefulness. A system that rejects everything may be difficult to exploit, but it is not a useful assistant.

Logs Should Explain the Action—Without Becoming Another Data Leak

“The AI did it” is not an incident report.

You need to reconstruct what happened.

For an action audit, I would aim to record:

Run identifier
Authenticated user
Workflow and policy version
Model checkpoint or deployment version
Requested tool
Resolved target
Authorization result
Approval identifier, if applicable
Execution status
Budget usage

OWASP recommends monitoring and logging to identify unusual consumption patterns. The format above is a proposed extension for tracing agent actions. genai.owasp

But logging everything indiscriminately creates another problem.

Prompts, tool arguments, and tool responses may contain sensitive information. Your audit design should minimize unnecessary sensitive content and restrict access to retained records. genai.owasp

Log enough to investigate the decision.

Do not turn your observability platform into an accidental archive of private documents and credentials.

Have a Stop Button Before You Need One

Before deployment, define what happens if the agent performs unauthorized actions.

A practical response plan could include:

Stop new runs.
Cancel active jobs where possible.
Disable tool execution.
Suspend the agent’s credentials.
Preserve relevant audit records.
Identify affected resources and external destinations.
Rotate credentials if exposure is suspected.
Reproduce the failure in isolation before re-enabling the workflow.

This is a proposed operational playbook, not an account of a specific incident.

Scoped execution identities and least privilege make the permission boundary easier to reason about. docs.aws.amazon

The crucial question is:

Can you stop the agent’s actions without asking the agent to stop?

If the only emergency control is another message to the model, the control is in the wrong place.

When Would I Use an Abliterated Model?

I would evaluate one for a specific purpose—not as a blanket upgrade.

Possible experimental uses include:

Studying how refusal-related interventions affect behavior.
Comparing checkpoints on legitimate requests that receive unnecessary refusals.
Measuring capability changes before and after modification.
Running controlled conversational or creative experiments.

Abliteration is useful as a research intervention because it can modify refusal behavior without a full retraining run. Published examples also show why capability preservation needs separate evaluation. huggingface

My deployment approach would depend on the surrounding permissions:

Environment	My approach
Disposable research environment with synthetic data and no external tools	Controlled experimentation
Internal-document assistant	Access scoping and disclosure tests before rollout
Coding agent with execution tools	Isolated workspace, constrained execution, and explicit budgets
Agent with production administration or broad external communication	Stronger justification, narrow permissions, and independent review

This is a risk-based design preference, not a universal classification of model safety.

The same scrutiny should apply to a conventional instruction-tuned model with equivalent access.

Five Myths Worth Retiring

“Uncensored Means Smarter”

Reduced refusal is not evidence of improved reasoning or factual accuracy. Benchmark results must be evaluated separately. huggingface

“Abliteration Removes All Safety”

That is too broad. Targeting refusal-related behavior does not establish that every safety behavior is removed—or that every request will succeed. huggingface

“A Strong System Prompt Is Enough”

Prompt instructions do not replace resource authorization, restricted tools, or infrastructure-enforced approval. owaspai

“Read-Only Means No Damage”

It limits modification. It does not eliminate disclosure when sensitive information can reach an output or communication channel. genai.owasp

“A Restrictive Model Makes Powerful Tools Safe”

Behavioral safeguards can contribute to defense in depth. They do not eliminate the need to limit functionality, permissions, and autonomy. genai.owasp

The Deployment Checklist

Before connecting an abliterated—or any other—model to real tools:

Use task-scoped identities.
Grant only the permissions needed for the workflow.
Prefer granular tools over open-ended execution.
Enforce authorization on every tool call.
Require explicit approval for high-impact operations.
Bind approval to the exact target and parameters.
Validate output before downstream execution.
Keep unnecessary sensitive information out of context.
Enforce time, step, request, and resource limits.
Test with malicious content in documents, emails, and webpages.
Maintain an independent way to stop execution. genai.owasp

These controls should not disappear when you switch back to a more restrictive model.

A safer default model can be useful.

It should not be the component that decides whether your production database is writable.

The Real Test: Assume the Model Makes the Wrong Choice

The debate around uncensored AI often gets stuck on personality:

Is the model obedient?

Does it refuse too much?

Will it answer a controversial question?

For system security, there is a more useful starting point:

Assume the model proposes the wrong action. What stops that action from happening?

If the answer is “the model usually knows better,” your boundary is behavioral.

If the answer is “the executor denies it because this identity cannot perform that operation on this resource,” you have an independently enforced boundary. That is the direction recommended by least-privilege and excessive-agency guidance. docs.aws.amazon

Experiment with abliterated models.

Measure what changed.

Keep the benefits you can demonstrate.

But build your application so that a wrong answer stays a wrong answer—not an executed incident.

A model can be allowed to say almost anything.

That does not mean your infrastructure should let it do almost anything.
created by : https://almodarresieh.github.io/

Before You Hire an AI Engineer, Find the Work That’s Getting Stuck.

Seyed Alireza Alhosseini — Sat, 24 Oct 2026 08:27:11 +0000

Your next AI project might begin with a sales inquiry nobody answered.

Or a quotation that took two days to prepare.

Or an expert spending the morning searching for information instead of using it.

None of these situations tells you which model to buy.

They tell you where to investigate.

That is the difference between starting an AI project and finding a business reason to build one.

If you are considering AI for your organization, here is the question I would ask before discussing tools, agents, or hiring:

What useful work is getting delayed, repeated, or left undone—and what would change if we improved it?

A real e-commerce experiment shows why that question matters.

One Company. Seven AI Experiments. Different Results.

A working paper published in October 2025 examined seven randomized experiments at a large international e-commerce platform.

The researchers tested AI interventions inside actual business workflows.

Selected results included:

Application	Reported sales effect
Pre-purchase customer service	+16.3%
Search-query refinement	Approximately +2–3%
Enriched product descriptions	Approximately +2–3%
Google advertising-title optimization	No detectable increase

These were separate comparisons against different baselines. The gains cannot be added together, and they do not represent a company-wide revenue increase.

But the variation is the useful part.

Putting AI into a workflow did not automatically make that workflow more valuable.

The baseline mattered.

The Detail Behind the Biggest Number

The customer-service experiment involved 44,614 customers.

One group had access to a generative AI agent before purchasing.

The control group received a scripted message indicating that customer service was unavailable.

Sales increased by 16.3% in the AI-assisted group relative to that control.

This does not mean AI outperformed an excellent human support team by 16.3%.

It means providing assistance outperformed an experience where effective assistance was unavailable.

The business opportunity was not simply “replace support with AI.”

It was:

Stop leaving a customer without an answer.

Your organization may have a different gap.

The point is to find it before building around it.

Three Places I Would Look First

The following are investigation starting points—not claims that every business needs a custom AI system.

1. Where Customers Are Waiting

Examples might include:

Product questions that require manual research.
Quotation requests waiting for information.
Inquiries arriving outside service hours.
Customers unable to find the right product.
Repeated requests for information already held by the business.

A potential first intervention could be a source-grounded assistant or a quotation-preparation tool.

But the objective is not “respond to more messages.”

It is to help the customer take the next useful step accurately.

2. Where Experts Are Assembling Information

Consider a specialist who must:

Locate several documents.
Extract recurring fields.
Compare versions.
Reconstruct a case history.
Draft a standard response.
Check which policy applies.

A useful system might prepare the material for review.

That is different from making the final professional decision.

The test I would use:

Can the expert verify the output faster than completing the original task?

If checking the system requires repeating all the work, the system has not yet earned its place.

3. Where Growth Has Created a Queue

More sales can mean more requests, exceptions, handoffs, and internal questions.

A growing queue is worth investigating.

It is not automatically an AI opportunity.

The cause might be:

Missing information.
Unclear responsibility.
A disconnected software system.
A rule that could be automated conventionally.
A genuinely difficult interpretation task.

Different causes require different interventions.

The right recommendation may be AI.

It may also be a better form or a straightforward integration.

What a Useful First AI Project Looks Like

Let’s make this concrete.

Imagine a distributor whose sales team prepares quotations manually.

Product specifications are in one file. Prices are in another. Availability requires confirmation.

A customer sends an inquiry.

The team spends time assembling an answer.

This is a hypothetical example, not a reported client engagement.

A bounded first version could look like this:

Customer inquiry
      ↓
Extract requested items, quantities, and units
      ↓
Identify missing or ambiguous details
      ↓
Retrieve approved product information
      ↓
Calculate using explicit business rules
      ↓
Prepare a draft quotation
      ↓
Salesperson reviews and approves

Notice what the system does not need to do:

Set prices independently.
Invent delivery dates.
Approve discounts.
Send binding offers.
Access every database.
Operate as an autonomous sales department.

The initial question is much smaller:

Can this approach help a salesperson prepare a correct, reviewable quotation with less effort?

That is a question we can test.

Measure the Work, Not the Demo

A quotation generator can produce a draft in seconds and still waste time.

Perhaps the wrong product was selected.

Perhaps the unit is inconsistent.

Perhaps the salesperson must verify every sentence against the original files.

For this hypothetical pilot, I would evaluate:

Dimension	Question
Extraction	Were the requested items, quantities, and units captured correctly?
Matching	Was the right product identified—or was ambiguity flagged?
Grounding	Do prices and conditions come from approved sources?
Calculation	Are amounts calculated correctly?
Review effort	How much correction does the salesperson need to perform?
Time	Is the total time to an acceptable draft lower?
Boundaries	Did the system stay within its permitted actions?
Cost	Does the improvement justify processing and review costs?

The phrase “total time” matters.

Count preparation, waiting, checking, and correction—not just generation.

And establish the acceptance criteria before looking at the final results.

You May Not Need to Fix All Your Data First

For the quotation example, I would begin by identifying the specific information the task requires:

Product identifiers.
Approved specifications.
Prices and their effective dates.
Units.
Relevant sales conditions.
The source and status of availability information.

That is not the same as launching a company-wide data transformation.

It is also not permission to ignore poor data.

The practical question is:

Is the information required for this bounded task sufficiently reliable, accessible, and authorized for the proposed use?

If not, that becomes part of the initial work.

A model should not be asked to compensate for missing commercial facts by guessing.

When I Would Recommend Waiting

Not every inquiry should become a development project.

I would pause a custom build when:

The intended outcome is still unclear.
The required information is unavailable or unauthorized.
Nobody can evaluate the output.
Review costs remove the expected benefit.
The workload is too small to justify maintenance.
A simpler solution can achieve the same outcome.
The proposed autonomy exceeds what the organization can safely oversee.

“Do not build this yet” can be a valuable recommendation.

It prevents a successful demonstration from becoming an expensive operational obligation.

What an Initial Review Should Clarify

Before committing to implementation, I would want a clear answer to five questions:

What outcome matters?
Which workflow or capability should we investigate first?
What information and permissions does it require?
What is the smallest useful intervention?
What evidence would justify continuing?

The result should be a decision—not just a technology shopping list.

That decision might be:

Improve the process first.
Prepare a specific dataset.
Use an existing tool.
Develop a focused proof of concept.
Run a limited pilot.
Stop or revisit the opportunity later.

The value is knowing which path fits your organization.

Start With One Opportunity Worth Testing

You do not need to arrive with an architecture diagram.

You do not need to know whether you need an agent, a retrieval system, or a predictive model.

You need a business objective and enough context to investigate it.

That objective might be:

“We want customers to receive useful answers sooner.”

“We want specialists to spend less time assembling documents.”

“We want to test a new service without committing to a large platform build.”

The technology should follow the problem.

Not the other way around.

Considering AI for Your Organization?

I offer consultation on identifying suitable AI use cases, assessing data and workflow requirements, and designing focused implementation experiments.

If you have a specific opportunity—or need help selecting a practical starting point—share your organization's context through the inquiry form.

Discuss Your AI Implementation Opportunity

You will be asked about your objective, current process, available information, and important constraints.

No technical specification is required. Please do not submit confidential documents or access credentials.

The goal is to establish what is worth investigating before deciding what to build.

Explore my work and projects:

https://almodarresieh.github.io/

Submitting an inquiry does not book a meeting, confirm project acceptance, or guarantee an outcome.

Source and Scope

Fang, L., Yuan, Z., Zhang, K., Donati, D., and Sarvary, M. (2025). Generative AI and Firm Productivity: Field Experiments in Online Retail. Working paper, version 1, October 14, 2025.

https://arxiv.org/abs/2510.12049v1

The reported e-commerce results come from this working paper. Its experiments took place between September 2023 and June 2024 at one undisclosed platform.

Sales increases are not equivalent to net-profit gains or guaranteed returns elsewhere.

The distributor example, proposed architecture, evaluation criteria, and consulting approach are illustrative recommendations—not claims of completed client projects.

Mercury Into Gold Is the Headline. AI-Powered Science Is the Bigger Story!

Seyed Alireza Alhosseini — Fri, 23 Oct 2026 13:06:43 +0000

A startup says it has turned mercury into gold.

That sounds like the opening of a scam email—or a discovery that arrived several centuries late.

But Marathon Fusion, a San Francisco–based company, says it has demonstrated mercury-to-gold transmutation using neutrons produced by fusion reactions. Reports published in October 2026 describe a claimed production rate ten times a CERN benchmark. The publicly reported details, however, do not establish commercial-scale production, production costs, or independent verification of the result. euronews

So, no: this is not your signal to short gold.

For developers, though, there is a more interesting question:

Where could AI fit into a project like this?

Not as a chatbot that invents a nuclear reaction. Not as a magical replacement for a reactor.

As a system that helps scientists search an enormous engineering design space—and decide which expensive experiment to run next.

That is where this story becomes much bigger than gold.

First, separate three different claims

Stories like this often compress three very different milestones into one headline:

A physical pathway exists.
An experiment demonstrates that pathway.
A commercially viable system can exploit it.

Marathon Fusion’s earlier proposal used neutronics simulations to investigate a pathway for producing stable gold from mercury in a fusion environment. The newer announcement claims an experimental demonstration. Neither, by itself, establishes an economically competitive gold-production business. euronews

The distinction matters.

“Can we produce it?” and “Can we produce it profitably?” are different research programs.

AI might help with the second question. It cannot make the first answer automatically imply the second.

What actually turns mercury into gold?

This is nuclear transmutation, not chemistry.

The proposed pathway starts with mercury-198. A neutron-induced reaction produces mercury-197, which subsequently decays into stable gold-197. The underlying proposal examines how fusion-generated neutrons could drive this process. marathonfusion

The essential distinction is simple:

Changing chemical bonds changes a material’s chemistry.

Changing an atomic nucleus can change the element itself.

The gold, if produced and isolated as described, is not a gold-colored substitute. The challenge is achieving useful production while managing the engineering, costs, and radioactive by-products. Those constraints remain central to evaluating the company’s claim. euronews

Now bring AI into the picture.

Did Marathon Fusion actually use AI?

We should not turn a plausible application into a reported fact.

The public proposal describes neutronics simulations. That is not, by itself, evidence of machine learning. The reporting cited here does not establish that AI discovered the pathway or drove the new experiment. euronews

Everything below is therefore a potential engineering workflow, supported by related research—not a description of Marathon Fusion’s internal stack.

That boundary makes the AI story more credible, not less interesting.

Opportunity 1: Build a faster approximation of an expensive simulator

Imagine that evaluating one reactor-related design requires a detailed simulation.

Now imagine thousands of candidate designs.

Running the highest-fidelity calculation for every possibility can make exploration expensive. A machine-learning surrogate offers another approach: train a model on simulation results, then use it to estimate the behavior of additional designs.

Researchers have investigated neural-network surrogate models for predicting nuclear-system properties, including spatial neutron behavior. Related fusion research is also pursuing faster blanket-design optimization. mdpi

For a mercury-to-gold project, a possible workflow would be:

Generate candidate designs
          ↓
Run selected high-fidelity simulations
          ↓
Train a surrogate model
          ↓
Screen a larger candidate pool
          ↓
Re-simulate promising candidates
          ↓
Experimentally validate selected designs

The surrogate is a screening tool.

Its prediction is not an experimental result.

Opportunity 2: Search for trade-offs, not a single “best” design

“Produce more gold” sounds like a clear objective.

An engineering system rarely has only one objective.

A hypothetical optimizer for this application would need to consider production alongside constraints such as radiation protection, material behavior, and the reactor’s other functions. Related fusion-blanket research already uses computational pipelines and optimization methods to explore coupled engineering requirements. frontiersin

This is where multi-objective optimization becomes useful.

Instead of announcing one universally “best” design, the system could expose trade-offs:

More predicted production, but greater engineering complexity.
Lower predicted production, but better performance against other constraints.
An attractive estimate, but too much uncertainty to justify an experiment.

Those are illustrative decision categories, not reported results from Marathon Fusion.

The useful output is a map of choices—not a confidently generated answer.

Opportunity 3: Decide what to test next

A model that predicts outcomes is useful.

A model that helps select the next informative evaluation can be more useful.

Bayesian optimization combines a predictive model with a rule for choosing the next candidate to evaluate. In fusion-design research, this kind of approach helps navigate expensive design evaluations rather than exhaustively testing every possibility. frontiersin

For a hypothetical transmutation project, the next evaluation might serve one of two purposes:

Exploit: investigate a design that currently looks promising.
Explore: investigate a poorly understood region that could change the model’s conclusions.

The balance matters.

Always chasing the current winner can trap a project in a narrow part of the design space. Exploring without discipline can consume the entire budget.

Here, the developer’s task is not merely prediction. It is building a decision loop.

Opportunity 4: Help interpret what the experiment produced

The experiment does not end when a sample leaves the irradiation setup.

Researchers still need to characterize the resulting material.

Machine learning has been studied for identifying radioactive isotopes from gamma-ray spectra. Research also emphasizes that performance depends on how closely training and testing conditions resemble one another. osti

That creates another plausible role for AI: assisting the analysis of radioactive components in a sample.

But an isotope classifier is not a universal “gold detector,” and a high-confidence label is not a substitute for validated measurement.

This is a particularly important place to distinguish useful automation from scientific proof.

The developer opportunity is the infrastructure

It is tempting to imagine that the breakthrough component must be a huge foundation model.

The workflows above suggest a less glamorous—and potentially more practical—opportunity:

Build the software that makes simulation, optimization, measurement, and validation work together.

A conceptual architecture could look like this:

Candidate generator
        ↓
Constraint checks
        ↓
Physics simulator
        ↓
Versioned results database
        ↓
Surrogate + uncertainty estimates
        ↓
Experiment-selection policy
        ↓
Human review
        ↓
New simulation or physical experiment
        ↓
Validated results return to the database

That is an illustrative architecture, not the company’s disclosed implementation.

The difficult software questions are familiar to developers:

Which dataset trained this model?
Which simulator version generated those labels?
Can we reproduce the recommendation?
Does the model recognize an unfamiliar input?
What evidence would invalidate its preferred design?

In this setting, uncertainty is not a cosmetic number beside a prediction.

It is part of deciding whether to spend money, collect more evidence, or reject a recommendation.

A credible open-source project inspired by this story

You do not need to build a reactor—or make claims about producing gold—to explore the software pattern.

A bounded educational project could:

Choose a non-sensitive, public simulation benchmark.
Establish a conventional baseline.
Train a surrogate on a subset of evaluated cases.
Add uncertainty estimation.
Compare random candidate selection with Bayesian optimization.
Measure how many expensive evaluations each approach needs.
Publish failure cases alongside improvements.

The question would be narrow and testable:

Can this workflow find a satisfactory design with fewer high-fidelity evaluations than the baseline?

That is a better portfolio claim than “I built an AI scientist.”

It gives readers a dataset, a baseline, a reproducible method, and a result they can challenge.

Gold is the hook. Better experiments are the story.

Marathon Fusion’s announcement deserves scrutiny: the reported claim does not yet answer the central questions about yield, cost, scalability, and independent confirmation. thedeepdive

But the broader software opportunity does not depend on accepting every part of the headline.

Related research already shows machine learning being investigated for nuclear-system surrogates, fusion-design optimization, and radioactive-isotope identification. mdpi

The exciting possibility is not that AI can wish a new element into existence.

It is that better models, better uncertainty estimates, and better experiment-selection software could help researchers spend less time testing weak ideas—and more time confronting promising ones with reality.

The headline asks whether we can turn mercury into gold.

The developer question is more actionable:

Can we build systems that turn expensive experiments into better decisions?
created by:https://almodarresieh.github.io/

What If AI’s Biggest Revolution Isn’t Intelligence—but the End of “How”?

Seyed Alireza Alhosseini — Thu, 22 Oct 2026 14:19:16 +0000

We keep asking whether AI can think.

I think we’re overlooking a stranger question:

What happens when humans no longer have to explain how to make something—only what they want to exist?

That is the question behind my new paper, From Command to Genesis: Generative Systems and the Closing of the Will–World Gap.

And it starts with a change developers encounter every day.

From writing the procedure to describing the outcome

Compare these two requests:

for item in items:
    # Define the transformation.
    # Handle the edge cases.
    # Assemble the result.

And:

Build a searchable dashboard from this dataset.
Make the outliers visible.
Explain the assumptions.

In the first, you author the means.

In the second, you describe an end—and delegate much of the means.

Of course, that second request is not a guarantee of a correct dashboard. You may receive something broken, misleading, or superficially impressive.

But notice where the interaction begins.

Not with a procedure.

With a desired state of the world.

My paper asks whether this shift is merely another layer of abstraction—or a deeper change in the human relationship to making.

The will–world gap

I call the distance between intending something and bringing it into existence the will–world gap.

You imagine an artifact. Between that intention and the finished result stand techniques, interfaces, materials, decisions, and labor.

A compiler helps cross that distance. So does a printing press. So does a CAD tool.

Generative systems introduce a provocative possibility: across an expanding range of informational artifacts, the user can describe the result without personally constructing the procedure that produces it.

The distinction is not simply speed.

It is a change in what the user must contribute.

From:

“Here are the steps. Execute them.”

Toward:

“Here are the conditions. Produce something that satisfies them.”

Specification becomes the interface to production

The paper calls the strongest version of this possibility specification-identity:

To adequately specify an informational artifact is, increasingly, to have produced it.

That is deliberately a strong thesis—not a claim that every prompt works, every generated program is correct, or every design is ready for fabrication.

The word adequately carries a serious burden.

An image that looks right is not the same as code that behaves correctly. A plausible design is not the same as a manufacturable object.

But the philosophical question remains:

If a system can supply the means, how much of making moves into the act of specifying the end?

And what remains irreducibly outside that act?

The obvious objection is also the interesting one

“Wait. The procedure hasn’t disappeared. It’s inside the model and its infrastructure.”

Exactly.

The procedure has not vanished from computation.

The question is whether procedural authorship is disappearing from the user’s role.

Those are different claims.

A person can operate at the level of outcomes while an enormous technical apparatus performs the implementation underneath.

That distinction matters because it changes what we mean by authorship, expertise, and control.

Did you make the artifact because you specified it?

Did you merely commission it?

Does selecting and revising the result constitute a new kind of craft?

The paper takes a strong position. These are the questions on which that position should be tested.

No quantum mysticism required

I am not arguing that prompts collapse a cosmic wavefunction.

I am not arguing that models retrieve perfect objects from a Platonic realm.

The paper treats generative systems as historically situated, trained computational systems—not supernatural access points to possibility.

For me, that makes the question more interesting, not less.

We do not need magic to ask whether the relationship between intention and production is being reorganized.

We need a precise account of what has moved, what remains, and where the system still fails.

The physical world is the harder test

Generating an image is one thing.

Generating a complete design that can survive fabrication, material constraints, safety requirements, and real-world use is another.

My paper pushes the argument into this harder territory through what I call the rendering relation: the proposal that physical production can increasingly become the material realization of an informational design-object.

This is also where the thesis faces its strongest resistance.

If fabrication requires new decisions, experimentation, and redesign, then matter is not merely receiving an already completed creation.

It is participating in it.

That boundary—between implementing a design and completing the act of creation—is one of the central tensions I want readers to challenge.

Where does the “how” still refuse to disappear?

The most useful response to this argument is not “AI is amazing.”

It is a counterexample.

A task where:

The desired outcome can be specified clearly.
The system still cannot reliably produce it.
Human procedural intervention remains essential.

Those cases reveal whether we are approaching a new relationship to making—or simply mistaking a powerful interface for the end of mediation.

My thesis is intentionally ambitious:

The deepest change may not be that machines are becoming creators. It may be that humans are increasingly able to create without personally authoring the means.

Whether that is liberation, a loss of agency, or a redistribution of expertise depends on what happens next—and on which parts of the “how” prove impossible to delegate.

Read the paper

From Command to Genesis: Generative Systems and the Closing of the Will–World Gap

By Seyed Alireza Alhosseini Almodarresieh

Independent Researcher

📄 Read the full paper

🌐 Visit my website

Developers: what is the strongest example from your own work where a clear specification still cannot replace knowing how?

IBM Is Building Up, Not Just Shrinking Down. Developers Should Pay Attention!

Seyed Alireza Alhosseini — Thu, 22 Oct 2026 04:42:50 +0000

`
A chip rests between two fingers.

Zoom in, imaginatively, and its colored surface becomes a city. Connections become streets. Switching devices become buildings. Power has to reach every neighborhood. Heat has to escape.

Now imagine that city running out of land.

One answer is to make everything smaller.

Another is to build upward.

That is the architectural idea behind IBM’s Nanostack: vertically stacking and staggering complementary transistors to increase density, rather than continuing to place them only side by side. IBM introduced the technology at its 0.7-nanometer node in June 2026. newsroom.ibm

The interesting part is not the tiny number.

It is what happens when changing the geometry of computation changes what we can afford to build.

And what still refuses to change.

The short version

IBM’s Nanostack is a research-stage transistor architecture, not a new GPU you can order for your workstation. IBM reports nearly twice the transistor density of its earlier 2 nm technology and projects substantial performance or efficiency improvements. Independent reporting describes the approach as part of the industry’s broader move toward vertically stacked complementary transistors. Manufacturing economics, thermal constraints, and design tools remain central challenges. newsroom.ibm

For developers, my takeaway is simple:

A hardware breakthrough is not an application benchmark. But it can change which applications become worth attempting.

1. This is not “just stack two chips”

The phrase 3D chip can hide several different ideas.

You can connect separately manufactured chips inside a package. You can stack a memory die above another component. Or you can reorganize the transistors that implement logic itself.

Nanostack belongs to that last conversation.

IBM describes an architecture that stacks n-type and p-type transistors—the complementary device types used in CMOS logic—rather than positioning them side by side. Its arrangement also staggers the devices, helping address the problem of connecting them. research.ibm

MIT Technology Review places the approach in the broader category of complementary field-effect transistors, or CFETs. It also notes that IBM is not alone: other major semiconductor companies and research organizations are investigating this direction. technologyreview

That distinction matters.

The story is not:

One company discovered that the third dimension exists.

It is:

Engineers are trying to make transistor-level vertical integration manufacturable, connectable, and economically useful.

Building another floor is easy in a diagram.

Building it without damaging the floor below is a manufacturing problem.

Connecting it without sacrificing the benefits is a design problem.

Making enough working devices at an acceptable price is a business problem.

Nanostack has to survive all three.

2. The numbers are exciting. Read the labels.

Here is a compact version of the evidence:

Claim	What the available sources support	What it does not establish
Nearly twice the transistor density	IBM compares Nanostack with its own earlier 2 nm technology. newsroom.ibm	Twice the performance of every application
Nearly 100 billion transistors	IBM reports this density on a fingernail-sized chip; its later design-kit announcement specifies 150 mm². research.ibm	A commercially available processor with that specification
Up to 50% more performance, or a major efficiency improvement	IBM presents these as projected benefits relative to its 2 nm node. newsroom.ibm	A measured speedup for your model, compiler, or backend
Functional device operation	IBM reports experimental validation including functioning CMOS inverters. newsroom.ibm	High-volume production readiness
Early design ecosystem	IBM plans an early R&D process design kit for Q1 2027. research.ibm	A complete, mature commercial toolchain available today

There is also a wording trap.

IBM’s June explainer describes “70% less energy consumption,” while other announcements use “70% greater energy efficiency.” Those phrases are not mathematically interchangeable. Without the underlying comparison conditions, I would not convert them into a precise electricity-bill prediction. newsroom.ibm

The same caution applies to “0.7 nm.”

That is a process-generation designation—not a claim that every transistor component measures 0.7 nanometers. Both IBM and independent reporting explicitly distinguish node naming from literal physical dimensions. newsroom.ibm

None of this makes the work less interesting.

It makes the interesting part clearer:

Architecture may offer another path forward when simply squeezing neighboring devices closer together becomes harder.

3. The update developers should watch is not another tiny number

On October 13, IBM announced plans for an early Nanostack process design kit, or PDK, in the first quarter of 2027. The proposed initial release includes example standard-cell libraries and an SRAM design, intended to help organizations explore layouts and evaluate potential power, performance, and density characteristics. IBM explicitly says it will not include every model found in a mature commercial PDK. research.ibm

A PDK is roughly the bridge between a fabrication process and the people designing circuits for it: models, design rules, libraries, and process-specific information. research.ibm

For a software developer, think of the difference between:

Seeing a demonstration of a new computing platform.
Getting enough tooling to begin asking whether your design can actually use it.

Those are different milestones.

IBM also announced a research collaboration with Siemens on October 14, covering modeling, simulation, lithography, and design capabilities for Nanostack. That is evidence of ecosystem development—not evidence that the manufacturing challenge is already solved. newsroom.ibm

This is where the story becomes more tangible.

A device concept starts becoming a platform when other people can meaningfully design around it.

4. Three people inside the possible future

The following scenes are fictional. They illustrate possible consequences, not demonstrated Nanostack applications.

The independent researcher

Maya has a hypothesis about agents with persistent memory.

Her problem is not that she lacks another framework. Her problem is that a convincing experiment requires enough runs to separate an effect from a lucky seed.

In one possible future, better hardware economics let her run more controlled experiments within the same budget.

Not a magical model.

Not instant intelligence.

More opportunities to discover that her favorite idea is wrong.

That is an underrated form of progress.

But the benefit only reaches Maya if device-level improvements survive manufacturing costs, system design, product pricing, and access conditions. A denser transistor architecture does not itself guarantee affordable research compute.

The infrastructure engineer

Jon manages an inference service.

He does not buy “50% faster.” He buys a system that must meet a latency target under a budget.

His questions are less photogenic:

Which workload improves?
What happens at sustained utilization?
How much memory does the system need?
What is the total cost per completed request?
Does the advantage remain after deployment overhead?

In a favorable scenario, better silicon gives him more useful work within his power budget.

In another, the service hits a different limit and the headline advantage barely appears.

The lesson is not to distrust hardware.

It is to benchmark the thing you actually deliver.

The person using the device

Leila wants an assistant that can help with private documents without sending everything elsewhere.

In one possible future, more capable local hardware makes that experience practical at a price she can afford.

But hardware is only one condition.

She still needs suitable software, sufficient memory, a product that supports local execution, and control over where her data goes.

A chip can create room for privacy-preserving design.

It cannot choose that design on the user’s behalf.

5. Three futures—not one prediction

These scenarios are not mutually exclusive. Different markets could experience different versions at the same time.

Future A: The vertical city has expensive gates

The technology works.

Manufacturing remains difficult and costly.

The largest buyers capture most of the early benefit.

In this scenario, computational capability grows faster than access to it.

What would support this scenario? Strong technical results accompanied by limited availability and high system costs.

What would weaken it? Broad adoption across competitively priced products.

Neither outcome follows automatically from transistor density.

Future B: Intelligence moves closer to the user

Efficiency and density improvements translate into useful devices, while memory, software, and economics improve alongside them.

More applications can run locally.

The meaningful outcome is not “a larger model fits.” It is that useful tasks can be completed within the user’s constraints.

What would support this scenario? Affordable devices meeting clearly specified local workloads, latency targets, and power budgets.

What would weaken it? Better compute with little improvement in the complete local experience.

Future C: We save energy per task—and invent more tasks

Suppose computation becomes cheaper.

We might use the savings to reduce total consumption.

Or we might use them to run more agents, generate more content, and add inference to more products.

In this scenario, efficiency improves while total demand continues growing.

That is a possibility to investigate, not an inevitable outcome.

The important distinction is between energy per useful task and energy consumed by the entire system.

Optimizing the first does not, by itself, determine the second.

6. The city still has a heat problem

Vertical density introduces difficult engineering trade-offs.

IBM identifies wafer alignment and uniformity, multi-level wiring, thermal management, inspection, and compatible electronic design automation as areas requiring further work. research.ibm

Independent reporting highlights two additional concerns: manufacturing errors can compound when multiple device layers must function, and later fabrication steps must avoid damaging structures already built below them. technologyreview

These are not footnotes.

They determine whether an impressive structure becomes a reliable process.

A city with twice as many buildings is not automatically twice as useful if its streets, electrical systems, and maintenance cannot support it.

The analogy ends there; the actual engineering requires device models, measurements, and process control—not urban poetry.

7. More transistors do not tell us what intelligence is

Here is the seductive chain:

text More transistors → more computation → more intelligence → consciousness

Every arrow adds assumptions.

A hardware improvement can expand the resources available to an algorithm. It does not, by itself, specify which algorithm should run, what it will learn, or whether its behavior deserves a particular cognitive interpretation.

Nothing in the Nanostack announcements establishes machine consciousness. The reported work concerns transistor architecture, device operation, scaling, and the design ecosystem. newsroom.ibm

The more productive question is narrower:

Which experiments become practical when a particular resource becomes less expensive?

That could mean testing persistent memory more thoroughly.

It could mean comparing more learning trajectories.

It could mean discovering that extra compute does not fix a flawed architecture.

All three would be valuable outcomes.

The philosophical question I find more interesting is this:

When computation becomes easier to obtain, do we become better at explaining intelligence—or merely better at producing behavior we have not yet explained?

8. A developer project you can start without a semiconductor lab

Do not build a “Nanostack simulator” from headline percentages.

Build a bottleneck sensitivity study.

The question:

If one part of my AI application became faster, how much would the user actually benefit?

Start with a small application you can measure. Split its request path into stages:

text request → preprocessing → retrieval or data loading → model execution → postprocessing → response

Measure the stages rather than assuming their importance.

Then create hypothetical scenarios: model execution becomes moderately faster, much faster, or almost free. Keep the other measured stages unchanged for the first experiment.

Those scenarios are not Nanostack predictions. They are a way to test your application’s sensitivity to a compute improvement.

A useful project specification:

Element	Proposed approach
Hypothesis	Improving the targeted stage materially reduces end-to-end latency
Baseline	The measured application on current hardware
Variables	Hypothetical changes to the targeted stage
Metrics	Total latency and the share contributed by each stage
Rejection condition	Other stages dominate, leaving little application-level benefit
Deliverable	Reproducible benchmark, raw timings, assumptions, and sensitivity results
Limitation	No claim to model Nanostack’s actual device or system behavior

Then add a second experiment: optimize the largest bottleneck you can change today.

You may find that your future hardware opportunity is real.

You may also find that your present software is leaving more performance unused than you expected.

Either way, you leave with evidence.

9. The courtroom test

Imagine three people evaluating a future Nanostack-based system.

The engineer says:

“We can build it.”

The researcher asks:

“Under which conditions does it outperform the baseline?”

The user asks:

“What do I gain, and what do I give up?”

A serious technology story needs all three voices.

Demonstrating functional devices answers an important question. Publishing a design kit answers another. Producing reliable, economical systems answers several more.

IBM’s public roadmap still describes a path toward production, rather than a finished commercial destination. Its June announcement suggested production could begin as early as roughly five years away; that remains a company expectation, not a guaranteed delivery date. newsroom.ibm

So the next milestones I would watch are:

Independently evaluated results with clearly specified comparisons.
Circuit- and system-level performance under realistic workloads.
Evidence about yield, reliability, and cost.
Usable design tools and documented access conditions.
Products whose benefits survive beyond the presentation slide.

The chip is small. The distance to an application is not.

Zoom out again.

The city disappears.

The chip is back between two fingers.

What makes Nanostack compelling is not that it removes limits. It is that it may reorganize some of them—and give engineers another route through a difficult landscape. Its promise is grounded in a concrete architectural change, while its ultimate impact still depends on manufacturing, tools, economics, and system design. technologyreview

For developers, the right response is neither worship nor dismissal.

It is curiosity with instrumentation.

Watch the hardware. Understand your bottlenecks. Measure the complete system. Keep the possible future separate from the demonstrated present.

The smallest city in the world will matter not because its buildings are tall, but because of what people can finally do inside it.

created by :
https://almodarresieh.github.io/

What If We Built a Stock Market That Had to Wait for You to Grow Up?

Seyed Alireza Alhosseini — Wed, 21 Oct 2026 04:53:34 +0000

Imagine opening an investment app on your eighteenth birthday.

Instead of confetti, it shows you a receipt.

Not just a balance. A record of every fee charged, every investment decision made on your behalf, every organization that benefited, and every risk someone accepted with money that belonged to you.

At the bottom, there is a button:

Ask why.

That is the product I want to explore.

Not a trading app with cartoon rockets. Not a leaderboard for wealthy children. Not a casino wearing a financial-literacy costume.

A financial system whose operators must eventually explain themselves to the person who was too young to question them.

Call it the Childhood Exchange.

This is a design proposal, not an existing product or legal blueprint. And its most interesting feature might be that it should barely resemble an exchange at all.

Giving a child a share is easy to imagine. Designing the relationship is harder.

Start with a simple thought experiment: every child receives a share in a company.

The immediate questions are financial:

What is it worth? Who holds it? Can it be sold? What happens if its value falls?

But a developer should see another set of questions:

Who controls the account? What does the interface encourage? What data gets collected? Whose interests does the recommendation engine serve? What happens when the child disagrees?

A share is an asset.

The software around it is a system of permissions, incentives, and power.

We can make the asset belong to the child while designing everything else around someone else’s objectives.

That is the problem worth building against.

Please do not build a brokerage app with smaller buttons

There is an obvious version of this product:

Colorful charts.
A friendly mascot.
Daily streaks.
Trading challenges.
Notifications announcing “opportunities.”
A leaderboard comparing returns.

It would be easy to pitch. It might even look educational.

But learning about markets and being encouraged to trade are not the same product.

The UK’s Financial Conduct Authority tested digital engagement features in an experiment involving more than 9,000 consumers. It found that features such as notifications and prize draws could increase trading frequency and risk-taking. That study was not about children, so it does not establish the effects on them. It does give designers a reason not to treat engagement mechanics as harmless decoration. fca.org

Here is the alternative design principle:

Make understanding easy. Make consequential financial action deliberate.

A child should be able to explore a concept without entering a transaction funnel.

Curiosity does not need a buy button.

The product needs two worlds—and a wall between them

I would separate the system into two environments.

The learning world

This is a simulation.

Users can investigate businesses, test assumptions, watch hypothetical portfolios change, and discover that a plausible story is not a guaranteed return.

They should be able to lose imaginary money without losing real money—or dignity.

No public wealth rankings. No rewards for being the most aggressive trader. No implication that winning a simulation proves investment skill.

The ownership world

This contains real assets.

It needs legally appropriate custody, clear authority boundaries, understandable disclosures, and a transition process that follows the rules of the relevant jurisdiction.

Adult-managed investment accounts for children already exist; US UGMA/UTMA custodial accounts are one example. Their existence means “children can own investments” is not, by itself, the innovation. fidelity

The innovation would have to be the quality of accountability around that ownership.

And there should be no automatic bridge from “excellent simulator score” to “permission to trade real assets.”

Learning achievement != financial authorization

That is not a minor UX detail.

It is a boundary the architecture should enforce.

The most important dashboard belongs to a future user

The child using the product today is not its only audience.

There is also the future adult who will inherit the consequences.

So I propose a requirement:

Every consequential action must be explainable to the account holder when they gain control.

Call it the Eighteen-Year Test—a memorable name, not a claim that control transfers at eighteen in every jurisdiction.

For each action, the system should help answer:

Who authorized this?
What authority did they have?
What information was available?
What did it cost?
Who received the payment?
What alternatives were considered?
What uncertainty remained?

Notice the difference between this and a performance chart.

A chart says what happened to the balance.

An accountability record helps explain what people did.

Those are different questions.

Build the receipt before the recommendation engine

Here is a conceptual event record:

type AccountDecision = {
  id: string;
  occurredAt: string;

  actor: {
    id: string;
    role: "guardian" | "authorized_manager" | "account_holder";
  };

  authorityReference: string;
  action: string;

  rationale: {
    plainLanguage: string;
    policyVersion: string;
    alternativesConsidered?: string[];
  };

  costs: Array<{
    amount: string;
    currency: string;
    recipient: string;
    reason: string;
  }>;

  disclosedConflicts: string[];
  evidenceReferences: string[];
};

This is not a production-ready financial schema.

It illustrates a product priority: the explanation is part of the transaction record, not a paragraph generated years later to make the decision sound reasonable.

Recording a rationale does not prove the decision was good.

But a system that cannot preserve who acted, under what authority, and at what cost cannot meaningfully promise accountability.

An audit trail also needs privacy boundaries. “Preserve evidence” must not become an excuse to retain every childhood interaction forever.

Keep what is necessary to explain the management of the assets. Do not turn the account into a permanent behavioral biography.

What would success look like if we refused to optimize for trading?

For this proposal, I would not make daily active use or transaction count the primary success metrics.

I would test measures such as:

Can users explain what they own?
Can they distinguish a simulated result from a real financial outcome?
Can they find the fees without assistance?
Can they identify who has authority over the account?
Can they challenge an error?
Does the eventual transfer of control work?
Can they leave without being manipulated into staying?

These metrics are less exciting than a growth chart.

They also tell us more about whether the product serves its stated purpose.

A teenager opening the app less often could be perfectly compatible with success.

The goal is not to make a child think about markets every day.

The goal is to help preserve options for the adult they will become.

Children should own assets. They should not become assets.

There is a boundary this idea must never cross.

We are discussing investments held for children.

We are not discussing shares in children.

No markets in their future earnings. No tradable claims on their potential. No public “talent valuations.” No investment thesis built around pressuring a child to become a particular kind of adult.

The distinction needs to survive the business model.

If the product becomes more profitable when children disclose more, compete more, or make more financial moves, we should examine that incentive before polishing the interface.

Good intentions are not an access-control policy.

They are not a revenue model, either.

A child must be allowed to reject the future we funded

Suppose a child receives an investment connected to a particular vision of progress.

They grow up.

Then they decide they want something else.

They do not want to work in that industry. They disagree with the company. They care more about a local river than a distant technological frontier.

Does the product still consider them a success?

It should.

An investment made for a child should expand their choices, not quietly assign them a mission.

The eventual account holder must be free to ask difficult questions, change direction, and—subject to the applicable rules—exit.

Gratitude should not be a condition of ownership.

The uncomfortable question: do we need an exchange at all?

Perhaps not.

An actual exchange would introduce questions this essay does not solve: who trades, how prices form, what liquidity exists, which assets qualify, and how the market is supervised.

Those are not implementation details to postpone until after launch.

If the objective is long-term ownership, education, and accountability, the better first product might be a protective layer around existing financial infrastructure.

That would make “Childhood Exchange” a provocative name for a design exercise—not necessarily the right company structure.

Before handling real assets, I would prototype three things:

A clearly labeled simulator.
An explanation interface using synthetic account histories.
A transfer-of-control walkthrough.

Then test whether people understand them.

Not whether they click more.

Whether they understand.

The feature that matters most

Picture that eighteenth-birthday screen again.

The balance might be larger than expected. It might be smaller. No responsible interface should rewrite uncertainty as a promise.

But underneath the number is something the system can deliberately provide:

An intelligible record.

Here is what belonged to you.

Here is who managed it.

Here is what they charged.

Here is why they acted.

Here is how to challenge an error.

Here is what you control now.

That would not solve inequality. It would not make investing risk-free. It would not substitute for education, public institutions, or a livable world.

It would establish a narrower, demanding principle:

When we build systems for people who cannot yet fully question us, we should prepare to answer them later.

The best financial app for a child might not be the one that teaches them to behave like a trader.

It might be the one that forces the adults to behave like trustees.
creared by https://almodarresieh.github.io/

Your Next AI Project Should Start With the Money You’re Already Losing!!!

Seyed Alireza Alhosseini — Tue, 20 Oct 2026 10:34:52 +0000

A customer asks a question.

Your team answers tomorrow.

A buyer requests a quotation.

Someone starts searching through spreadsheets.

A specialist opens a new case.

The first hour disappears into finding the documents.

None of these moments looks like an AI problem.

They look like normal business.

That is exactly why they deserve attention.

Before you ask, “How should we use AI?”, ask:

“Where are customers, employees, and decisions waiting—and what is that waiting costing us?”

You may not need another chatbot.

You may need to close a gap that has become so familiar nobody questions it anymore.

One retailer tested AI. The results were not what a sales pitch would suggest.

A working paper published in October 2025 examined seven randomized experiments at a large international e-commerce platform.

Some interventions improved sales.

One produced no detectable sales increase.

Here are four of the results:

Business process	AI intervention	Reported sales effect
Pre-purchase customer service	Answering customer questions	+16.3%
Search-query refinement	Better interpretation and translation	Approximately +2–3%
Product descriptions	Richer, structured product information	Approximately +2–3%
Google advertising titles	AI-optimized titles	No detectable increase

These were separate experiments against different baselines—not gains that can be added together or applied to every business.

The most important detail sits behind the largest number.

In the customer-service experiment, 44,614 customers were assigned to different experiences. One group could receive help from an AI agent. The control group received a scripted message indicating that customer service was unavailable.

The AI-assisted group generated 16.3% more sales relative to that control.

The result did not show that AI beat an excellent human sales team.

It showed that useful assistance beat an unanswered question.

The opportunity was not “add AI.”

The opportunity was “stop leaving a customer without help.”

That is a much better starting point for a business conversation.

Does any of this sound familiar?

You do not need to understand model architectures to recognize an operational bottleneck.

You probably already hear it in your team’s daily conversations.

“We’ll send the quotation once we find the information.”

The request arrives.

Product details are in one file. Prices are in another. Availability requires a message to someone else.

The customer waits while your team assembles an answer.

A possible starting project:

Turn an incoming inquiry into a structured request, retrieve approved information, flag missing details, and prepare a quotation draft for review.

Not autonomous pricing.

Not unapproved commercial commitments.

A faster path to a correct, reviewable response.

What I would measure:

Time from inquiry to quotation.
Errors and manual corrections.
Staff effort per quotation.
Quotation-to-order conversion.
Total operating cost.

“Our best people spend too much time looking things up.”

Your experienced employees know how to solve the problem.

But first, they have to find the contract, locate the policy, reconstruct the history, or compare several versions of a document.

A possible starting project:

Assemble relevant information with links to its sources, identify gaps, and prepare a draft for an expert to review.

The objective is not to remove expertise.

It is to reduce the preparation work surrounding it.

The test is simple:

Can the expert verify the result faster than doing the original task?

If verification takes just as long, the system has not earned its place.

“We’re growing, but everything feels slower.”

More customers.

More orders.

More exceptions.

More internal messages asking, “Who is handling this?”

A possible starting project:

Select one growing queue and test whether better intake, classification, information retrieval, or routing can reduce waiting.

Sometimes the answer will involve AI.

Sometimes it will be a clearer form, a software integration, or straightforward automation.

The customer should not have to fund an AI architecture when a simpler fix would do.

The companies I would investigate first

I would start with businesses where information delays sit close to revenue, service quality, or expensive employee time.

Business type	Bottleneck worth investigating
Distributors and wholesalers	Slow inquiries, quotation preparation, scattered product information
Online retailers	Unanswered product questions, poor search, incomplete descriptions
Professional service firms	Document review, evidence gathering, repeated drafting
Support organizations	Repeated questions, difficult knowledge retrieval, slow onboarding
Growing service businesses	Intake backlogs, fragmented customer context, manual handoffs

This is a practical prospecting framework—not proof that every company in these sectors needs a custom AI system.

The useful question is not:

“Are you in an AI-friendly industry?”

It is:

“Can we identify one costly problem that is specific enough to test?”

What a sensible first engagement should produce

Buying AI services should not require buying a grand vision before understanding the problem.

I would structure the first engagement around a decision:

“What is worth implementing here—and what should we leave alone?”

The output should make five things clear.

1. The bottleneck

A named process, a responsible owner, and a description of where work gets stuck.

“Improve productivity” is not specific enough.

“Reduce the time needed to prepare this type of quotation” is a starting point.

2. The baseline

What happens today?

How much work arrives? How long does it take? What needs correcting? What does it cost?

Where reliable measurements do not exist, establishing them is part of the work.

3. The information boundary

What data is required?

Where does it live?

Who may access it?

What is missing, outdated, or contradictory?

The goal is not automatically to centralize every dataset in the company. It is to establish whether the selected task has the information it needs.

4. The smallest useful intervention

A recommendation should distinguish between:

A process change.
Conventional automation.
A ready-made AI tool.
A custom AI application.
An agent with tightly defined permissions.

Custom development should earn its complexity.

5. The pilot decision

A limited test with:

A defined scope.
An agreed budget.
A primary outcome.
Quality and safety guardrails.
A responsible evaluator.
Conditions for scaling, revising, or stopping.

A successful first engagement may conclude:

“This is worth building.”

It may also conclude:

“Fix the data first.”

Or:

“You do not need AI for this.”

That clarity is a deliverable—not a disappointment.

What I would not promise you

I would not take a percentage from another company’s case study and present it as your expected return.

I would not describe a working demo as a production-ready operation.

I would not propose an autonomous agent before defining what it is allowed to read, change, send, or approve.

And I would not use “AI transformation” as a substitute for a measurable objective.

A 16.3% sales lift in one experiment is evidence about that experiment.

Your business needs its own baseline, test, and economics.

The question is not whether the technology is impressive.

The question is whether the improvement survives contact with your actual workflow.

A better way to start the conversation

You do not need to arrive with an AI strategy.

You can arrive with a sentence:

“This task takes too long.”

“Customers keep waiting for this answer.”

“Our specialists repeat this work every day.”

“We have the information, but nobody can find it quickly.”

Those are useful starting points.

From there, the work is to separate symptoms from causes, identify the relevant information, and determine whether AI is the right intervention.

The best first project is not necessarily the biggest opportunity on a slide.

It is the one that produces credible evidence without exposing the business to unnecessary complexity.

Find the gap before you buy the system

Before approving another AI subscription or custom development proposal, ask:

“Which customer will wait less?”

“Which employee will finish a useful task sooner?”

“Which error will become less frequent?”

“How will we know?”

If the answers are vague, the project is not ready.

Start with the bottleneck.

Make the technology justify itself.

Let’s Find Your First Worthwhile AI Project

If your business is dealing with slow quotations, unanswered inquiries, document-heavy work, or operational backlogs, start with the process—not a shopping list of tools.

For consultation on AI use-case selection, data readiness, and focused implementation planning, visit:

https://almodarresieh.github.io/

When you get in touch, describe:

The task that repeatedly slows your team down.
How it is handled today.
Where the relevant information lives.
What a better outcome would look like.

You do not need a technical specification.

Bring one recurring problem worth investigating.

Every LLM Lies!!!

Seyed Alireza Alhosseini — Mon, 19 Oct 2026 22:25:50 +0000

An LLM can generate a nonexistent API, explain why it works, and produce a plausible example using it.

Nothing in the presentation necessarily reveals the problem. The syntax looks familiar. The explanation sounds confident. The answer may even include a citation.

For developers, this creates an uncomfortable distinction:

An answer can look ready to use long before it is ready to trust.

“Every LLM lies” is a deliberately provocative way to describe that gap. Here, lying does not mean that a model believes something false and intentionally deceives you. It means something more operational: a system produces false or unwarranted claims while presenting the signals we normally associate with credibility.

The engineering question is not whether the model has bad intentions.

It is whether your architecture can detect when its output is wrong.

Stop treating honesty as a model-only property

A common response to hallucination is to improve the model: better training, better prompts, better retrieval, better evaluations.

Those efforts matter. But they do not eliminate the need for an architecture that handles failure.

A useful conceptual rule is the House Principle:

An honest system is one in which falsehood is cheap to detect.

This shifts attention from the model’s apparent sincerity to the surrounding infrastructure.

Can a user inspect the evidence behind a claim? Can the application distinguish a generated answer from a verified result? Can an incorrect output be corrected before it becomes a persistent record?

A system does not become trustworthy merely because its model makes fewer mistakes. It also needs to make the remaining mistakes visible.

Fluency is an interface, not a guarantee

Machine untruthfulness is not one failure mode.

An assistant might invent a fact. It might adapt its answer to match a user’s expressed belief. It might provide an explanation that does not faithfully reveal why it produced an answer.

These failures require different tests.

A factuality benchmark will not necessarily detect excessive agreement. A persuasive explanation will not establish that the underlying reasoning was sound. A confident answer will not tell you whether the supporting evidence exists.

Even the interface deserves scrutiny. First-person language and claims such as “I checked” can influence how users interpret an answer. The stronger hypothesis—that such language systematically induces unjustified trust—requires empirical testing, not assumption.

For product design, the immediate lesson is narrower:

Do not let the interface imply a verification process the system did not perform.

“Generated an answer,” “retrieved a document,” and “validated a claim” should describe different states.

The dangerous moment is when output becomes evidence

A false answer in a temporary conversation is one problem.

A false answer that enters documentation, a knowledge base, a report, or a future retrieval corpus is another.

Consider this sequence:

An assistant generates an unsupported claim.
Someone copies it into an internal document.
Another document repeats it.
A retrieval system finds both documents.
A later assistant presents the repeated claim as corroborated.

The system has not acquired independent evidence. It has acquired copies.

This is why provenance matters. Five documents that inherit the same unsupported assertion are not equivalent to five independent observations.

Source count is not evidence diversity.

It is also important to distinguish this mechanism from model collapse. Changes to a model’s learned distribution under recursive synthetic training are not the same thing as a particular false statement spreading through an information ecosystem.

Keeping original data may help address some distributional problems. It does not, by itself, establish the truth of an individual claim.

A second model is not automatically an independent check

Asking another model can be useful. But agreement alone is a weak definition of verification.

Two models may arrive at the same incorrect answer. Two retrieval results may trace back to the same source. Two agents may repeat an assumption introduced earlier in the workflow.

The architectural question is therefore not:

How many systems agree?

It is:

What independent evidence could show that they are wrong?

For a generated API call, that evidence might be the installed package and its actual interface. For a quotation, it might be the original passage. For a calculation, it might be an independently executed computation.

The verifier should challenge the claim, not merely reproduce its style.

Can false claims become locked in?

An exploratory toy model in the underlying research considers two quantities:

The fraction of false machine-propagated claims in a reference corpus.
The human capacity available to detect and correct them.

The model asks whether feedback can produce two stable outcomes: a relatively clean information environment and a heavily contaminated one.

Under most sampled parameter settings, it did not.

Bistability appeared in a narrow region when the model included threshold-type reinforcement: a mechanism in which widespread repetition makes a false claim harder to detect.

In one configuration, approximately 0.05% of sampled parameter sets were bistable.

That number is not an estimate of real-world risk. It describes results under arbitrary, uncalibrated parameter choices. The threshold mechanism was also introduced after simpler forms produced almost no bistability, making the finding exploratory rather than confirmatory.

The useful question is conditional:

Could apparent corroboration become strong enough that correcting individual outputs no longer restores the information environment?

The model does not establish that this happens in practice. It identifies a mechanism worth testing.

Turn the principle into engineering requirements

The conceptual argument becomes useful when translated into explicit design choices.

Separate generation from validation

Treat generated output as a candidate result.

Where feasible, validate it against the relevant environment: execute tests, inspect schemas, resolve references, or compare claims with authoritative records.

A successful generation step should not silently become a successful verification step.

Preserve evidence lineage

Store enough provenance to distinguish an original source from a summary, a copy, or a model-generated derivative.

Retrieval should help answer “Where did this claim originate?” rather than only “Where does this wording appear?”

Make uncertainty actionable

A generic disclaimer leaves the user to do all the work.

More useful states identify what remains unresolved:

The cited document was not retrieved.
The quotation was not located.
The code has not been executed.
The sources share a common origin.
The answer depends on an untested assumption.

These are not admissions of product failure. They are information about the verification boundary.

Place friction where errors become durable

Not every generated sentence needs human approval.

But publication, persistent knowledge-base updates, and consequential external actions deserve stronger gates than a reversible draft.

The critical boundary is often where an answer becomes a record that someone else will later treat as evidence.

Evaluate the whole workflow

Model accuracy is only one measurement.

A system-level evaluation can also ask:

How often do users accept incorrect outputs?
Which errors survive the verification process?
How quickly are persistent mistakes corrected?
How often do supposedly independent sources share an origin?

These measurements connect model behavior to actual reliability.

Build for correction, not apparent certainty

The strongest AI product is not necessarily the one that sounds most confident or produces the longest explanation.

It is the one that makes its evidential boundaries inspectable.

Better models remain important. So do retrieval, evaluation, provenance, and human judgment. But their value depends on how they fit together.

When reviewing an LLM feature, ask one architectural question:

If this answer is wrong, what in the system will notice—and what happens next?

Created by :https://almodarresieh.github.io/

Your Company Doesn't Need an AI Agent. It Needs a Better Problem!

Seyed Alireza Alhosseini — Mon, 19 Oct 2026 04:49:30 +0000

An AI agent increased sales by 16.3%.

An AI tool for advertising titles produced no detectable sales increase.

Same company. Different workflows.

That is the uncomfortable part of enterprise AI: a system can do what you asked and still fail to improve the outcome you care about.

A working paper published in October 2025, Generative AI and Firm Productivity: Field Experiments in Online Retail, examined seven randomized experiments at a large international e-commerce platform.

The experiments involved millions of customers and products. Sales effects ranged from no detectable improvement to a 16.3% increase.

The obvious headline:

AI can increase sales.

The more useful lesson:

Choosing where to use AI may matter more than deciding to use it.

Here is what the experiments reveal—and how I would use them to decide what to build.

Seven experiments. No universal AI dividend.

The researchers tested generative AI inside real business workflows. The experiments ran between September 2023 and June 2024. The paper was published in October 2025.

The company was not identified.

Here are four of the applications:

Workflow	What changed	Reported sales effect
Pre-purchase support	An AI agent answered customer questions	+16.3%
Search-query refinement	AI improved interpretation and translation of queries	Approximately +2–3%
Product descriptions	AI added richer, structured information	Approximately +2–3%
Google advertising titles	AI optimized product titles	No detectable increase

These are separate comparisons against each workflow’s existing approach.

They are not additive gains. They are not a company-wide revenue increase. And they are not a guarantee for another business.

The technology category was similar.

The commercial results were not.

To understand the difference, start with the baseline behind that eye-catching 16.3%.

The most important detail is what the AI replaced

The customer-service experiment involved 44,614 customers over two months.

One group could interact with a generative AI agent before purchasing.

The control group received a scripted message indicating that customer service was unavailable.

The AI group generated 16.3% more sales relative to that control.

Now compare these two headlines:

“AI beats customer service by 16.3%.”

“Providing AI assistance beats leaving customers without effective assistance.”

Only the second accurately describes the comparison.

That distinction is not a technicality. It changes the business case.

The experiment did not establish that an agent outperformed an excellent human support team.

It showed that answering questions could outperform an experience where those questions went unanswered.

The opportunity was a service gap.

My takeaway:

Before trying to replace the best person in the company, investigate the useful work nobody currently has the capacity to do.

Search: the products existed. The connection was weak.

The search experiment involved 1,849,382 customers.

The existing process used basic translation. The AI intervention added semantic interpretation to better convey what customers meant.

The study reports a sales improvement of roughly 2–3%.

Think about the engineering problem.

The company already had:

A product catalog.
Customer queries.
A search system.

The intervention targeted the connection between them:

What the customer says
          ↓
What the customer means
          ↓
What the search system retrieves

This diagram is my interpretation, not the study’s published architecture.

But it captures an important design choice:

You do not always need to replace an entire experience. Sometimes the useful intervention sits between two existing components.

“Build a shopping chatbot” and “improve query interpretation” are not the same project.

One starts with an interface.

The other starts with a failure.

Product descriptions: sometimes the opportunity is missing information

The product-description experiment involved 4,772,937 customers.

AI supplemented existing product information with more comprehensive, structured descriptions.

The baseline explains why this was worth testing: nearly half of the platform’s self-operated products had limited descriptions or no descriptions.

The study reports a sales improvement of approximately 2–3% for this application.

Again, the starting point was specific.

Not:

“Our organization needs to become AI-ready.”

But:

“Customers are trying to evaluate products without enough information.”

Those statements lead to very different projects.

The first can become an open-ended transformation program.

The second gives you a problem, a user, and a place to measure an effect.

For my own implementation, I would require generated specifications and product claims to be grounded in approved sources.

Filling an information gap should not become an excuse to manufacture information.

That is a design recommendation—not a safety outcome established by this experiment.

The result every AI presentation should include

AI-optimized advertising titles produced no detectable sales increase.

Keep that result in the story.

It is tempting to discuss only the successful experiments. But the non-result is what makes the comparison useful.

A title generator is easy to understand.

Easy to demonstrate.

Easy to admire.

None of those properties establishes incremental commercial value.

“No detectable increase” does not prove that the true effect was exactly zero. It means the experiment did not demonstrate a sales improvement under the tested conditions.

The practical question is:

If the output changed but the outcome did not, what are we paying to improve?

A better-looking artifact is not automatically a better business result.

The variable I would put at the center: the baseline

These experiments made me think less about AI capability in isolation and more about headroom.

By headroom, I mean the improvement available above the current experience.

An unanswered question may offer substantial room for improvement.

A product page with missing information may offer room for improvement.

A workflow that already performs well may offer much less.

This is my synthesis, not a formal metric from the paper.

It leads to a different project-selection question:

Old question:
Can AI do this task?

Better question:
Can AI improve this outcome enough
to justify the cost and risk?

The first question selects demonstrations.

The second selects experiments.

Before you build an agent, write this sentence

Here is the project brief I would use:

Today, [specific user] cannot reliably [specific action] because [specific gap]. We will test whether [bounded intervention] improves [measurable outcome] compared with [current baseline], without exceeding [cost and risk limits].

For a hypothetical retailer:

Customers cannot get compatibility answers outside support hours. We will test a product-information assistant against the current unavailable-support experience, measuring purchase conversion while checking unsupported claims and operating costs.

Notice what is missing:

A model name.
A vector database.
An agent framework.
A multi-agent architecture.

Those decisions come after the problem is clear.

A stack is an implementation choice.

It is not a business case.

Your first release should answer a question

For a hypothetical pre-purchase assistant, I would define the experiment like this:

SCOPE
One product category
One customer journey
Approved information sources

COMPARISON
Current experience vs. AI-assisted experience

PRIMARY OUTCOME
Purchase conversion

GUARDRAILS
Unsupported factual claims
Customer complaints
Escalation failures
Response latency

ECONOMICS
Incremental contribution
minus total operating costs

DECISION
Scale, revise, or stop

This is a proposed template, not a reconstruction of the retailer’s experiment.

Its purpose is to make the first release answer:

“Is this worth doing?”

Not merely:

“Can we make it run?”

Those are different milestones.

Only one justifies scaling.

What this study does not give us

It does not give every company a guaranteed 16.3% sales lift.

It does not establish that agents should replace human support.

It does not turn sales growth into a complete return-on-investment calculation.

And a paper reporting real operational data is not the same thing as a publicly downloadable raw dataset.

The paper is a working paper about one undisclosed platform. Its experiments provide useful evidence, but the results belong to those settings and comparisons.

The authors also report that sales gains were driven mainly by higher conversion rather than larger average order values.

That is an important distinction.

The interventions mainly helped more customers complete purchases—not necessarily make each buyer spend more.

“AI increased revenue” is a headline.

“AI helped remove a barrier to purchase” is a mechanism you can investigate.

Stop shopping for agents. Start looking for gaps.

The most useful thing about this study is not the biggest percentage.

It is the variation.

Seven applications inside one company did not produce seven versions of the same success story.

So before the architecture diagram, before the framework debate, before the agent demo, ask:

What is missing from the current experience?
Who pays the price for that gap?
What information would help?
What outcome should change?
What evidence would make us stop?

Your next valuable AI project might not begin with a more powerful model.

It might begin with an unanswered customer question.

What would you test first in your organization: improving a task that already works—or providing a useful service nobody currently offers?
created by : https://almodarresieh.github.io/

References

Fang, L., Yuan, Z., Zhang, K., Donati, D., and Sarvary, M. (2025). Generative AI and Firm Productivity: Field Experiments in Online Retail. arXiv working paper, version 1, October 14, 2025. Abstract: https://arxiv.org/abs/2510.12049v1 Full text: https://arxiv.org/html/2510.12049v1

All empirical figures in this article refer to that version of the paper. The engineering templates, interpretations, and implementation recommendations are the author's synthesis, not additional findings from the study.