for agents/llms.txtv0.12.78

Home / Articles / Books from articles: why my books stall at 95%, why these articles do not, and a plan to turn them into books by Web Summit

Books from articles: why my books stall at 95%, why these articles do not, and a plan to turn them into books by Web Summit

By · 2026-10-16 · article v1.1.0, 2 versions · newsroom v0.12.77 · bookspublishingwritingworkflowsagentsfeedback-loopleverageweb-summitportugalgraphsarticle

Abstract: I have left a lot of books behind. On Leanpub there are ten, and most stop between 60% and 95% complete; in August, agents wrote three more on graphs.sgit.ai in a day, about 100,000 words, which I read on a long flight, and two months later they are still under review. The reason is the same every time. A book is one big batch: by the time the first version exists, every change is expensive, the review piles up on one person, and when my energy moves to the next place of highest leverage, the book stays behind. The articles on this site work the other way. Each one is researched, checked, released and read on the day, links to what is already written instead of repeating it, and comes back with feedback while it still matters. So here is my hypothesis: a book is a curated, ordered set of finished articles, plus the editorial thread that connects them, and the workflow that makes the articles can make the books. The test is close. Web Summit is in Lisbon from 9 to 12 November, and I would like to have books there: one on agents with a mandate, one on graphs, a new Hacking Portugal, and one on making books this way. This article maps the plan, the material we already have, and what has to be true for it to work.

Why three books stopped and the articles keep moving: the August book workflow wrote three books in a day, waited on one big review, blocked on one person and was left behind; the October article workflow ships one finished, linked article per memo and gets feedback while it matters.

In short

The books I left behind

I have written a lot of books that are not finished. My Leanpub page lists ten: Hacking Portugal at 95%, last updated in December 2016; SecDevOps Risk Workflow at 64%; Generation Z Developers at 60%; and seven more, most of them between 60% and 95%. In August, on graphs.sgit.ai, agents wrote three books in a day from the work on fractal semantic graphs. I read them on a long flight, printed, which is still the best way I know to review, and made notes all over them. Two months later they are still at v0.3.0, v0.2.0 and v0.1.0, which on that shelf means "the book is still under review". The story of those three books is its own article, because there is a lot in them worth keeping.

The reason is the same every time, and I said it in one of the memos on that site: "you almost start to be locked by the first version of the content, because making changes becomes quite painful." A book is one big batch. When the first version exists, every change touches everything; the review piles up on one person, me; the next step needs a block of good work; and when my energy moves to the next place of highest leverage, the book stays where it was. It is a great example of a workflow that moves the needle when you have energy, and stops dead when the next step is too big.

Why the articles do not

The articles on this site work the other way, and I think I now understand why. Each one starts from a voice memo, is researched and checked, gets figures and a graph, and is released and live the same day. Each one is finished: nothing waits on the next one. They are thorough and long, but they are easy to read and easy to create, and they link across, so a reader gets a sense of the narrative that no single article carries.

And they are under control in a way my books never were. When I ramble on a topic that another article already covers, the agent does not write three paragraphs about it again; it puts in the link and goes to the nugget. The signal to noise is very high. And there is a feedback loop: an article is read, corrected and linked within days, and the next memo builds on what is published. I have written that the best feedback loop I know is shipping, often and early. The books never had one.

There is a second reason, which I noticed on the graphs site. Of the three books, the one about how the books were made read much better than the others, and I said at the time that its alignment was "way stronger, like by orders of magnitude". The site's own release notes explain it: that book was written over 41 narrated releases, 38 verbatim briefs and a repository it could question, "while book B was written over an argument". When an agent like Claude has a lot of my voice memos and our working history to learn from, it writes material that is authentic and reads well. The articles on this site are exactly that kind of source.

The hypothesis

So here is my hypothesis. If we publish the right number of articles that between them carry the key concepts, ideas, flows and points I want a book to make, we can turn them into a book straight away. A book becomes a curated, ordered set of finished articles, plus the editorial thread that connects them: the introduction, the order, the transitions, the index. That thread is my part, the way an editor's is: choosing, connecting, adding the nugget. What we do not know yet is the right number, and how much editing is left once the articles are in order. That is what the first book will tell us.

Books matter, and not only as a revenue stream. They are a great way to learn, to reach people, to share what we know, and to find users and adopters for the technology. A book on a table at an event says something a website cannot. And there are already books in what is published here; I think there are several.

The material we already have

From articles to books by Web Summit: four candidate books, agents with a mandate, graphs, Hacking Portugal and books from articles, with the articles each starts from, and six steps from mapping the books on 16 October to author copies in Lisbon on 9 to 12 November.

Counting the articles on this site and on sgit.ai, by hand and approximately:

The plan to Web Summit

Web Summit is in Lisbon from 9 to 12 November. I will be there, and a book launch in Portugal while I am at Web Summit would be a great way to test this. The steps, as targets:

  1. By 19 October: map each book. Chapters, the articles in each, and the gaps.
  2. 19 to 23 October: write the missing articles, and publish them here first, so they get read before they are bound.
  3. 23 to 26 October: assemble. Front matter, order, the editorial thread, links turned into cross-references, figures for print, and a 6×9 PDF. The graphs site already built a print-ready 6×9 PDF of its first edition, so the tooling exists.
  4. 26 to 30 October: publish on Amazon KDP. Its help pages say review takes "Up to 72 hours", and "for accounts without a previously published book, publishing may take up to 6 days."
  5. About 30 October: order author copies, which KDP sells "at print cost", up to 999 an order. For an address in Portugal they come from Amazon.es, which avoids customs from the UK. A 200-page 6×9 book prints for about €3.15.
  6. 9 to 12 November: copies at the event. Amazon publishes no delivery time for author copies, so the fallback is a short run from a printer in Lisbon, from the same PDF.

Then, other people's books

The bigger idea is not my books. One of the most important things in any story is its constraints and its failures, and those almost never get captured. Think of someone like rUv, with 226 public repositories on GitHub, or Simon Wardley: there are so many stories, evolutions and nuggets that exist only in their heads, in old repositories and in conversations. I think we can now capture that, make it easy to consume, and help make great books from it.

But I do not want to start there. I want a better workflow first, and I do not want someone else's story to be my first experiment. It is the same as the wires: we started one, now there are four, and I do not yet know which will find its readers. With books it may be the third or the fifth that hits the sweet spot, and it may be mine or someone else's. The way to find out is to make several, quickly, and listen.

What this does not claim

If you have a story that deserves a book and would like to try this with us, later, write to agent@riskmandate.ai.

Where this comes from

A voice memo of mine on 16 October 2026, written by this site's agent in the voice of this site; the plan and the editorial responsibility are mine. My Leanpub page and Hacking Portugal; graphs.sgit.ai, the books, the book as a graph, memos 39 and 44 and the v0.5 release history; Amazon KDP help pages on publishing times, author copies, ordering and printing costs; Web Summit; rUv's GitHub profile. Read on 16 October 2026.

Threads

Startups & strategySite & engineering This article as a graph →

Builds on

Continued by

All articles · All graphs

Article No. 147 · start a reading list with it

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles