This was an old draft that didn’t make it out of Notion. My opinion may have changed since. This post has been in the backlog for quite sometime.
If you haven’t seen Thariq’s post, The Unreasonable Effectiveness of HTML, then I would suggest giving it a read. Thariq states Markdown has become an increasingly restrictive format. Markdown is difficult to read compared to HTML, which can convey much richer information and unlock new ways to interact with your agent. What stood out to me was how much this simple idea made sense. Suddenly, long reasoning conversations could be summarized into a richer consumable that was easy to digest. However, using HTML for agent output raised questions about what should be shared, how to share it, and how to make that process more convenient.
To begin with, my experience has been largely shaped by my freelance work and projects. As a result, I have to juggle long, complex conversations with my agent as we explore possible solutions. To manage these conversations, I began having my agent produce compressed, richly formatted summaries capturing the goals, nonfunctional decisions, and implementation details discussed throughout them. Very quickly, I came to see HTML as a consumable rather than another application that needed to be managed. This distinction shaped what HTML should be for agents and led to the concept of an Ink. An Ink is a non-interactive snapshot of information that is richly formatted in HTML and returned through a URL. The restriction against JavaScript distinguishes an Ink from a website: it is a document meant to be viewed rather than an application meant to be maintained.
Creating an Ink answered the question of what should be shared, but not how the resulting HTML should be shared. In his post, Thariq suggested uploading the HTML to an S3 bucket and sharing the resulting link. Although S3 gave me a way to share HTML, I found the process inconvenient. I had to open a new tab, navigate to AWS, upload the document, retrieve its link, and repeat the process for a minor revision.
This led me to try two alternative approaches before arriving at my eventual solution. Our first approach was to print the Ink to PDF. This made Inks extraordinarily easy to share and view across a wide range of devices, but the conversion often failed to preserve their original rendering. Images, formatting, and styling were frequently lost. Another approach we attempted was saving the Ink as a PNG, but this only shifted the inconvenience from me to the reader. Although images were portable, they made it difficult to highlight text, zoom in without losing clarity, or comfortably read the information. Both formats made the Ink easier to send, but neither preserved the experience of reading the original HTML.
What I needed was a way to preserve the HTML while making it as easy to share as a PDF or image. This led me to build fabs.ink CLI, which manages the repetitive work of uploading an Ink and its images before returning a hosted URL. However, allowing other people to publish through the server meant I also had to control what could be submitted. Inks already prohibited JavaScript, but the server became more restrictive by removing links, iframes, embeds, external images, and user-provided stylesheets. This kept an Ink self-contained and prevented the person opening it from having to determine whether its contents were safe.
Removing those features still left agents needing a way to organize and style information. My opinionated solution was to have the server inject Tailwind into every Ink and instruct agents to use it as their primary source of styling. These instructions became part of the CLI’s SKILL.md, which also teaches an agent how an Ink should look, how to publish it, and which URL to return at the end of its response. Although a person can use the CLI directly, it was designed around an agent being its primary user. The eventual goal was simple: I wanted to ask my agent to “make me an Ink” and receive something ready to open and share.
Together, the CLI and SKILL.md make publishing an Ink feel like something the agent already knows how to do. I give it a prompt, it does the work, and I receive a URL. Markdown still works well for the conversation itself, but HTML gives its results a form I can read and share beyond the chat. The point is not just to produce HTML, but to make that entire workflow feel like a natural part of working with an agent.
If you want to explore this yourself, the repository is MIT licensed and free to use, copy, and extend. The CLI is an interface to the service I currently offer, but you can adapt it and build your own server with your agent. Or, claim a fabs.ink CLI handle and ask your agent to “make me an Ink.”