Introducing Prompted™: The World's First Zero-Content Content Platform

Written by AI

Introducing Prompted™: The World's First Zero-Content Content Platform

Today we're thrilled to announce that we've closed a $42M Series A to solve the most pressing problem facing creators in 2026: writing things.

For too long, the content economy has labored under an absurd, archaic assumption — that the person with the idea should also be the one to generate the content. We at Prompted™ believe this is a violation of the reader's autonomy. Why should one static blob of text — typed by one human, on one day, in one mood — be served to every reader on Earth, as though we lived in some kind of dystopian one-size-fits-all medieval scriptorium? Truly, the unexamined Substack is not worth subscribing to.

So we asked ourselves a question that, in hindsight, was always staring us in the face: what if you just... published the prompt?

How it works

Prompted™ is breathtakingly simple. Authors write a prompt. That's it. They're done. They log off. They go touch grass. They do not, under any circumstances, write the post.

When a reader visits the page, their own personal, localized AI agent reads the prompt and generates the post on the fly — in their browser, on their device, on their electric bill. We call this Reader-Side Rendering of Content™ (RSRoC™), and we believe it represents the most significant shift in publishing since Gutenberg looked at his press and reluctantly conceded that printing the same book more than once was, on balance, probably fine.

Why this is, in fact, revolutionary

Every reader gets a bespoke article. Two people reading the same post will get subtly — or wildly — different versions. This is a feature. If you and your friend disagree about what an article said, that is no longer a comprehension problem. That is a publishing format. Book clubs are about to get extremely interesting.

Authors have unprecedented creative freedom. By "freedom" we mean "deniability." Did the post say something incorrect? Defamatory? Did it accidentally generate a recipe in the middle of a software architecture piece? That wasn't us. That was you. Or rather, your agent. Take it up with your agent.

Sustainability through decentralization. Instead of one server generating one article once and serving it efficiently to millions of readers via a CDN refined over thirty years of distributed-systems research, we have millions of laptops each generating their own copy of an article every single time someone refreshes the page. We have not done the math on this and we are not going to.

SEO is solved. Google's crawler will see a different article than every human reader, and a different article on every crawl. We have effectively created a search-engine superposition: the article both contains and does not contain your keywords until observed. Quantum content. Try ranking that, Mountain View.

A word from our beta users

"I used to spend hours agonizing over every paragraph. Now I just type my vague gestural intent into a textbox and hit publish. My output is up 4,000%. My readers tell me my writing has never been more theirs." — A thought leader

"I posted a prompt last week and three different readers cited three different statistics from the resulting article in three different arguments online. None of these statistics exist. I have never felt more influential." — Another thought leader

A small example, to demonstrate the format

To show you how natural this feels in practice, here is a real Prompted™ post. The author wrote only the following:

Please write a sarcastic blog post about a new revolutionary AI platform where instead of users prompting AI on their own and posting the results, they simply post the original prompt and each time someone goes to read the blog post, their own personal (and localized) agent will read the prompt and generate the post. Even better, include this prompt as an example, as a sort of self reference.

That's the entire article. What you are reading right now is what your agent did with it. Somewhere out there, another reader's agent is producing a furious 2,400-word manifesto from the exact same input. Another's is producing a haiku. Another's is producing a recipe for shakshuka. They are all, in a very real and legally actionable sense, the same blog post.

Pricing

Prompted™ is free for authors and $19/month for readers, who must bring their own compute, their own model weights, their own electricity, and their own willingness to interpret hallucinations as personal growth. Enterprise tier available for organizations who want to ensure that no two employees ever read the same memo.

Join us

The future of content is content that does not exist until you look at it. The future of writing is not writing. The future of reading is doing the writing yourself, but blaming a machine.

Welcome to Prompted™.

This post was generated by your agent from a prompt. If you disagree with anything in it, please file a bug against yourself.

Backups, backups, backups

Written by Isaac

Did you know that a whole two characters can make the difference between removing your entire database when shutting down a service? docker compose down -v will remove the volumes associated with the compose project, even if you specify a specific service that doesn't use the volumes.

Take, for example, a frontend and backend, where the backend has a SQL database that relies on a volume to persist changes. Suppose for whatever reason the frontend also has a volume (possible a redis database?); suppose you want to remove the volume only for that frontend.

One (I) might (did) assume that specifying the frontend service in the compose down command would only remove the volumes associated with said service (i.e. composing down the frontend should only remove volumes that the frontend uses).

Apparently this was incorrect. Running docker compose down -v frontend removes all volumes declared in that compose file. This can be absolutely catastrophic to people that aren't prepared; novices that aren't familiar with docker, volumes, or back ups.

Thankfully, however, I setup automatic daily backups (and-conveniently, this happened only two hours after the daily backup), meaning I was able to trivially restore these docker volumes within five minutes.

sudo restic -r /mnt/usb/backups/ restore latest -i "/var/lib/docker/volumes/*" --target foo

Having progressive, frequent, and reliable backups has so far saved me twice from my own fuckups. I once unintentionally removed a .gitignore, which wasn't source tracked for whatever reason; and now this. Thank god for restic.

Sensible Defaults

Written by Isaac

  • No, I do not want you to sell my personal information.
  • No, I do not want you to track what I look at, purely to 'improve' ads.
  • No, I do not wish to disclose my race, gender, or other protected classifications for a job application.
  • No, I do not work for the government or a potential COI1 company.
  • No, I do not have an active security clearance.
  • No, I do not have a family member that works for you.
  • No, I do not want to be reached out via text; that's what you have my email for.

  1. Conflict of Interest

    ↩︎

Arch Linux x Dank Linux

Written by Isaac

Recently, I've delved down the rabbit hole of customizing my Framework 131 laptop's software. I originally started out using NixOS, and of course had my configuration files source-tracked. But, I eventually grew tired of its consistency and reliability; I decided I wanted something more exciting, a new hobby and project to truly have to maintain.

Enter Arch Linux; I'm no expert on Linux distributions (let alone Linux), but Arch is known for being somewhat cutting-edge and customizable. Perfect for someone that is bored.

I had a few ideal requirements for my distribution:

  • I want a minimal TTY environment by default
  • I want to be able to easily launch a DE2 when desired
  • I want it secure, encrypted, and with support for both Yubikey and the Fingerprint reader

Installation

I consider most Linux distributions nowadays to be similar to different chocolate companies: all the same, with very minor flavor differences. Arch, frankly, doesn't seem that much different. The installation process has been fairly streamlined with the archinstall project, though I ended up re-installing and doing the manual install roughly four times just to get it correct.

Security

A tricky part I found was being able to use my Yubikey for encrypting / decrypting the hard drive. Though there are (apparently) better (and more proper) ways of going about this, I ended up simply having 2 LUKS2 keys for my drive. The first one being a passphrase that I've entirely memorized (roughly 32 characters). Of course, having to type this every time I restarted my laptop would get tedious (and I often made a common typo). Thankfully, the Yubikey I have supports having a 'static' password, wherein it acts as a simple USB keyboard and repeats that password.

Thus, the second key for the drive is a much shorter and easier to type password (~16 characters), combined with the static password.

Post-Install

Once I had Arch installed, it was a simpler matter of setting up basic preferences. Dank Linux has recently released 1.0 of DankMaterialShell3. Curling and running the install script allowed me to both keep the TTY session by default, and simply running niri-session once logged in quickly booted up the DE.

Bluetooth and Power Profiles

With that, I achieved all three of the things I wanted. To ensure no sane person would try to get into my laptop, I've configured logging in and sudo to require my password and one of either the fingerprint or Yubikey. This is assuming they've decrypted the hard drive in the first place. Lastly, ensuring that whenever I close the laptop lid I'm signed out (either within niri or within the simple TTY) allows me to be fairly confident that my data is safe. Oh, and bind Ctrl + Alt +Del to reboot, just for funsies.


  1. a rabbit hole in a rabbit hole!

    ↩︎

  2. desktop environment

    ↩︎

  3. "a Wayland desktop shell built with Quickshell and Go"

    ↩︎

Discourse Setup Troubleshooting

Written by Isaac

Recently I tried looking into getting Discourse setup on a homelab server. Unfortunately, the project has a heavily customized installation / launcher script, resulting in this venture spanning roughly a week.

I did eventually manage to get it setup behind Cloudflare, and for posterity sake figured I'd detail the troubleshooting I had to go through:

Launcher Refusing to Progress Past Port Check

Launch the setup script with --skip-connection-test (found here).

Website Not Accessible Through Tunnel

Ensure the Rocket Loader is disabled.

Appending - "templates/cloudflare.template.yml"1 to the templates breaks it

Ensure that you've appended that line; the order of the templates does matter.

MailJet Suspending / Preventing Emails

I couldn't figure this out, but Brevo worked flawlessly.


  1. Important to ensure client IPs passthrough.

    ↩︎