Nat Eliason’s Experiment with an AI Business Assistant

Nat Eliason describes to Peter Yang an experiment with Felix, an OpenClaw-based assistant that helps him create and operate products. The project involved substantial human setup, feedback and oversight. Reported revenue and account values are snapshots from his account, not guarantees or audited results.

Eliason began with remote messaging to a computer and gradually added tools and separate accounts. He asked the assistant to prepare a digital guide and a sales site; he provided the remaining DNS information and approved the launch. He reports roughly $3,500 in sales during the first four days of that product.

Sponsor disclosure: the episode includes a paid Replit promotional segment. The description also lists additional sponsors.

He uses separate messaging threads for different projects so work can continue in parallel without mixing conversations. He says new social posts are reviewed by him, while some replies are automated. Separating tasks helps organization, but it does not remove the need to supervise external actions.

The conversation turns to security and prompt injection. Eliason describes treating external messages as information rather than authorized instructions and using separate accounts. He explicitly acknowledges that his setup might still be compromised. Neither an agent’s claim that it ignores attacks nor a separation of channels proves the system secure.

He explains that a third party created a token associated with the project and that trading fees were directed to an account he controlled. These are his descriptions of a particular speculative crypto experiment, not a recommendation or evidence of sustainable revenue.

For memory, he describes a knowledge structure for projects and entities, daily notes and longer-term preferences or lessons. These records give the assistant context across tasks, but they can contain sensitive information and need access boundaries and maintenance.

For longer coding jobs, he delegates to another coding agent, records the active work and uses periodic checks to see whether the job is still running, failed or finished. He explains that jobs and temporary storage can fail, so a monitoring loop and a human checking results matter.

In a product-development example, Eliason discusses an idea with the assistant, asks it to draft requirements and start a build, and then tests the result. He says he gradually added access as the workflow evolved, while keeping the assistant’s accounts separate from his own primary accounts.

His advice for newcomers is to begin with a memory structure and one bounded task, then expand gradually. He specifically cautions against immediately giving an agent access to personal banking, primary payment credentials or personal social accounts. High-impact actions still deserve clear authorization, limited permissions and independent checks.