u/Magayone

I’m currently finalizing the commercial pipeline for a new book (The Imagined Life), and we are releasing it using a completely different distribution model.

Instead of just selling a PDF or an EPUB, we are selling it as a secure, local CLI tool. You buy it, you get a token, and you run npx maha-cli book mount the-imagined-life. This spins up a local MCP (Model Context Protocol) server.

When you go into Cursor or Claude Code, your AI agent can now natively query the book's Abstract Syntax Tree (AST). Instead of you reading Chapter 2, you tell your agent: "Read the framework in Chapter 2 and apply it to the database schema I'm currently building." The agent queries the book, gets the exact philosophical concept, and contextualizes it to your local code.

The Dilemma:

The tech is built and the Stripe webhook is live. We are building a frictionless checkout where someone can read the free HTML version on our site, and click a button to buy this interactive AI version.

But we are stuck on what to actually call this thing on the buy button.

Here are the current contenders. Which of these clearly communicates what you're buying, without sounding too gimmicky?

• Book-as-an-Endpoint: Extremely literal. It tells backend engineers exactly how the architecture works, but it feels a little passive.
• The MCP Edition: Highly tactical. Devs using Cursor and Claude know exactly what MCP is right now, but it ties the book to a specific protocol name that might evolve.
• The Agentic Edition: Fits the broader "Agentic Publishing" philosophy well, but might be a bit too abstract for a checkout button today.
• Context Payload: A bit cyberpunk, but accurate. You are literally buying structured knowledge to inject into an LLM's context window.
• Executable Book: Implies action and utility. It’s not a file that sits on your desktop; it’s code that runs alongside yours.

If you were reading an essay online and saw a $10 upsell for this, which name would make it instantly click for you? Should we use one of these, or is there a better term we are missing?
Would love to hear your thoughts.

Like a lot of you, I've been using new AI agents like Cursor and Claude Code to speed up my development. I wanted to give my local agent direct access to my development databases so it could query context, schema, and rows natively using the new Model Context Protocol (MCP).

The problem: I quickly realized how incredibly risky this is, even in a local dev environment.

1. Prompt injection / hallucinated mutations: I tried using regex to block keywords like INSERT or DROP, but an LLM can easily bypass string filters by wrapping a mutation inside a Common Table Expression (e.g., WITH x AS (INSERT...) SELECT). The regex failed completely.
2. PII leakage: If a query pulls a row from a comments or support_tickets table, and a real user typed their name or email in there, that data gets shipped right out to a third-party LLM cloud.

I didn't want to wait for enterprise cloud gateways to solve this for solo developers, so I spent the last few weeks building a lightweight local proxy CLI tool called maha-mcp-bridge.
How it works under the hood:

• Dual-Layer Transaction Rollbacks: Instead of relying on fragile regex string parsing, the proxy intercepts the AI's generated SQL and forces the database engine to execute it inside a strict READ ONLY transaction block that is automatically rolled back after the data is fetched. Even if the LLM tries a sneaky CTE mutation, the database engine itself immediately kills it.
• Local ML Sanitization: It uses a tiny, quantized token-classification model running locally in Node.js via u /xenova/transformers (ONNX Runtime). It scans unstructured text fields and redacts contextual PII (like a person's name or location) completely offline in under 40ms before the data ever leaves the local network card.

Why I'm posting here:

I originally built this just to protect my own local environment, but I'm considering polishing the CLI, wrapping it in a clean npm install -g package, and open-sourcing the repository this week.

Before I spend a few late nights cleaning up the codebase, documentation, and edge-case handling: is this a tool you would actually drop into your AI coding workflow, or am I over-engineering a problem nobody else cares about?

If you're currently letting AI agents touch your local or staging databases, how are you handling data safety right now?

We are silently transitioning out of the traditional "Prompt Engineering" era and entering the era of truly autonomous AI agents (Cursor, Claude Code, and localized enterprise swarms).

This transition exposes a fundamental flaw in how humanity currently structures and distributes knowledge. We are still treating information as static payloads—PDFs, ePubs, standard documentation sites, and raw database dumps.

When you force an autonomous agent to read a massive static file, the context window degrades, token costs skyrocket, and the agent begins to hallucinate. Even worse, if you grant an agent direct, uninhibited access to a production database to pull its own context, you create a massive zero-day vector for malicious SQL execution and systemic data leaks.

To scale globally, the architecture of information has to change. We have to move from static content consumption to authenticated context injection.

I am currently building out an architecture over at publish.mahastrategies.com to map out this shift. Here is the blueprint for how we secure and deliver knowledge in an agent-native world, split into two layers:

1. The Distribution Layer: Agentic Publishing
The era of buying a static technical book or manual is ending. Instead, knowledge assets will be distributed as live, authenticated Model Context Protocol (MCP) servers.
Instead of a reader downloading a 500-page PDF and copy-pasting text into an LLM window, they mount the text as a secure, local endpoint. The user's IDE or local agent natively queries the structured document tree via standard JSON-RPC protocols. The book becomes an active tool in the agent’s toolkit—completely personalized, dynamically compiled to match the reader’s environment, and fully grounded via Retrieval-Augmented Generation (RAG) to eliminate hallucinations. r/AgenticPublishing

2. The Security Layer: The Zero-Trust Bridge
Moving knowledge to live agent endpoints introduces a massive data integrity paradox. If an agent can query your local systems or internal databases for context, how do you keep it from leaking sensitive PII or executing corrupted tool calls?

To make global agent adoption viable for enterprises, the proxy layer must enforce absolute zero-trust guardrails locally before any data leaves the host network:

• Dual-Layer Transaction Restraints: You cannot rely on basic regex string filtering to block data mutations (malicious agents can easily bypass string gates using Common Table Expressions like WITH x AS (INSERT...) SELECT). The proxy must force every single AI-generated query into a strict, server-side READ ONLY transaction that is automatically rolled back.
• Edge-Level Machine Learning Sanitization: Standard regex catches emails, but it completely misses contextual PII (like a human name inside a random comments field). The bridge must run local, quantized token-classification models (via ONNX runtimes) entirely offline to scrub sensitive identifiers before the network packet ever hits a third-party LLM cloud.

The Macro Trajectory

We are building the rails for a world where agents securely talk to data silos without human middleware. If data doesn't adapt to speak MCP natively, it will become invisible to the next generation of software.

For those tracking the macro trajectory of AI tools and systemic automation: how do you see the tension between data privacy and agent utility playing out over the next few years? Will enterprises completely block external agent communication, or will the industry standardize on localized, zero-trust protocol firewalls?

(Full disclosure: I used Gemini/Claude to help me structure and draft this post based on my technical notes, which is fitting given the topic).

If you've spent any time trying to write a cohesive, full-length book with an LLM, you already know the wall you eventually hit: the context window collapses, the model hallucinates facts, and the tone becomes generic.

Asking a single LLM prompt to write a chapter is like asking a single person to simultaneously be the researcher, the author, the fact-checker, and the editor. It fails.

I’m currently building an open-source infrastructure for true Agentic Publishing and we abandoned the single-prompt approach entirely. Here is the technical architecture required to actually generate long-form, factual content without hallucinations:

1. The Multi-Agent Swarm

Instead of one chat window, you need an asynchronous background queue running distinct micro-agents. You need a Researcher agent that only scrapes data, a Writer agent that only drafts, and an Editor agent that only aligns tone.

2. Vector Memory (RAG) over Context Windows

You can't just paste notes into the prompt. The Researcher agent needs to embed its findings into a vector database (like Supabase pgvector). When the Writer agent drafts a chapter, it uses Retrieval-Augmented Generation (RAG) to pull only the strictly verified facts from that database. This mathematically eliminates hallucinations because the writer is constrained by the vector embeddings, not its training data.

3. Just-In-Time Compilation

Ultimately, a book shouldn't just be a static PDF or ePub. The backend should dynamically compile the examples and tone based on who is reading it.

We are standardizing this over at r/AgenticPublishing if you want to see the deeper technical specs. For those of you building custom writing workflows, are you still trying to force everything through a single API call, or have you started experimenting with chained agents?

As the founder of this subreddit, I want to clarify what we are actually building here. Right now, when most people hear "agentic publishing," they picture someone using a prompt to spit out a generic, hallucination-filled ePub for Kindle.

That is not agentic publishing. That is just automated typing.

True Agentic Publishing means the book is no longer a static document. It is a dynamic, natively queryable endpoint customized just-in-time for the reader's exact technical profile.

We are currently building this exact infrastructure over at publish.mahastrategies.com. Instead of keeping the roadmap private, I am open-sourcing the architecture here as a manifesto for where this industry is heading.

Here is the three-phase technical stack required to build a true Agentic Publishing platform.

Phase 1: The Asynchronous Agent Swarm (The Factory)
You cannot generate high-value, factual, long-form content in a single LLM prompt. Standard serverless functions (like Vercel) will time out, and the model will drift into hallucinations.
Instead, you need a multi-agent orchestration layer.

• Stateful Workflows: Use an event-driven queue (like Inngest or Upstash Kafka) to manage asynchronous, long-running agent loops.
• Agent Roles: Spin up micro-agents with strict system prompts: a Researcher (with database/web scraping tools), a Writer (content generation), a Fact-Checker, and an Editor.
• Vector Memory (RAG): Integrate a vector database like Supabase pgvector. The Researcher embeds gathered facts. The Writer utilizes Retrieval-Augmented Generation (RAG) against this trusted knowledge base. This strictly eliminates hallucinations because the writer is only allowed to synthesize verified embeddings.

Phase 2: Just-In-Time (JIT) Compilation (The Press)
Generic technical manuals are dead. When a reader buys a technical book, they should supply their specific profile (e.g., "I use React and Go, and deploy on AWS"). The backend should compile a unique version of the text tailored to that exact context.

• Dynamic Markdown: An asynchronous worker filters the master document repository, dynamically substituting examples, code snippets, and analogies to match the buyer's environment.
• Sandboxed Execution: Code blocks aren't just written; they are verified for syntax accuracy against the user's specific tech stack using a sandboxed executor before the book is compiled.
• Automated Typesetting: The personalized markdown is piped through a headless typesetting engine (like React-pdf or a LaTeX microservice) to generate a customized PDF/ePub, delivered instantly via transactional email.

Phase 3: The Book as an Endpoint (Interactive Delivery)
This is the holy grail. Reading a technical manual on a second monitor and copy-pasting code into your IDE is an archaic workflow. The book itself must become a server.

• The Model Context Protocol (MCP): Deliver the book alongside a lightweight, open-source CLI utility.
• Zero-Trust Context Isolation: The reader runs a command like cli book mount --id [book-id]. The CLI checks their authorization token against your cloud backend to verify the purchase, and then spins up a local MCP tool (e.g., query_book_chapters).
• IDE Integration: The reader's local AI agent (Cursor, Claude Code, Windsurf) natively queries the interactive book directly within their IDE. If the reader asks, "How do I implement the architecture from Chapter 4 in this file?", their IDE agent reads the authenticated book context directly through the local bridge.

The Standard
We are moving from "content consumption" to "context injection." If you are building in the publishing space, this is the new baseline.

I’m currently porting the MCP server behind our CLI authentication gate to make Phase 3 a reality. What architectures are the rest of you exploring to break out of the static PDF/ePub trap?

For years I kept a list of books I searched for and never found. So I've drafted about five of them with AI. To be upfront: the ideas, arguments, and structure are mine, but the AI does most of the actual writing from my outlines.

Two examples. The Imagined Life — an honest account of how imagination and dreaming actually works on a life: not the fantasy that wishing delivers, but the chain by which picturing the not-yet-real reshapes the person who imagines, who then acts. And The Unfinished Species — what it means for humanity to move from undirected evolution to deliberately shaping its own biology and trajectory, treated as open inquiry rather than prophecy.

The one that gets most meta is The Synthetic Self, a book about AI written with AI. It treats machine intelligence as a compression of the human record, and argues the alignment problem is really a human problem reflected back at us — the question being how to make AI a genuine partner rather than a dependency.

I'm not rushing these to Amazon. I'm reading them first, as the reader they were written for. If they satisfy me — if they're actually the books I went looking for — then I'll get them out into the world.

Would you knowingly read a book like this? And what gaps have you noticed — books that should exist but don't?

Solo-built over the past ~7 months (Maha Strategies, Capacitor/React + a Node/socket.io gateway). The pitch: most health apps show you data, Maha OS gives an AI agent the ability to act on it. Connect Claude or any MCP client, it reads your live heart rate/readiness, and if you're genuinely fried it can trigger a full-screen breathing-reset intervention on your phone. There's also a rules-based on-device version with zero network dependency, for anyone who doesn't want to link an external agent.

Decisions and tradeoffs that shaped it:

• Open protocol over a closed vendor agent. A couple of competitors (miora, WHOOP Coach) do agentic health coaching, but the agent is locked to their backend. I went MCP-first specifically so the user brings their own model instead of being stuck with mine — closer to "your agent, your rules" than "our AI, our roadmap."
• On-device fallback was not optional. Cloud-only intervention means the one moment it's needed most (bad connectivity, background app suspended) is exactly when it can fail silently. Built a threshold-based local steward as the reliability floor; the cloud/MCP path is the richer optional layer on top.
• The most humbling bug so far: the native deep-link handshake for pairing an agent had apparently never actually succeeded in production — a root-route mismatch between the app and the gateway meant every real handshake attempt 404'd, silently, since launch. Found it this week while doing exactly what this sub is for: actually trying to use my own shipped feature end-to-end instead of trusting that it worked.
• Session persistence was another one. Gateway ran on free-tier hosting with in-memory session state — meaning every server restart silently unlinked every connected user. Fixed this week with a Supabase-backed session store and boot-time rehydration; tested by literally restarting the server mid-session and confirming the link survived.

Where it stands right now, honestly, by platform:

• iOS: latest build just cleared App Review — includes an onboarding screen with a 20-second interactive demo of the intervention (no account or permissions needed to try it).
• Android: still on an earlier build without that onboarding demo, pending its own review. The core agent-link feature works fine on this version too — you just won't get the guided walkthrough, and there's one rough edge (the pairing link needs pasting into Firefox's address bar rather than tapping directly; Chrome/Brave silently refuse the custom URL scheme). Universal Links to fix that properly are next on the list.

What I'd actually value from this sub: if any of you have shipped an MCP-exposed consumer product, I'm curious how you're handling multi-tenant session scoping — right now the gateway serves "whichever node linked most recently" to any connecting agent, which is fine at N=1 and clearly needs real scoping before more than one person is testing concurrently. Also happy to go deeper on the Capacitor/native-bridge side if useful to anyone building something similar.

Not asking for downloads here specifically — just sharing the build. If you want to poke at the MCP server itself, it's public on Smithery: mayone/cognitive-gateway.

The Reality Up Front

Maha Strategies is a sovereign intellectual property ecosystem. We design advanced frameworks, original research, intelligence products, and operational doctrine to help organizations navigate structural, technological, and systemic change.

The technical engines, methodology, and core IP are established. However, the founder is a researcher and engineer, not an extroverted, transactional cold-pitcher. We are entering a strict 90-day market-validation and outreach phase. We are looking for a complementary Founding Commercial Partner who understands the value of scarce, high-integrity knowledge assets and wants to co-build a high-ticket enterprise revenue engine from scratch.

This is a pre-revenue, commission-and-equity-based role. If you are looking for an established corporate account manager role with a warm inbound pipeline and a cushy base salary, this is not for you. If you are a builder who wants to turn a deep, rigorous ecosystem into an elite B2B enterprise revenue engine, read on.

The Ecosystem Architecture

We do not sell conventional, low-margin consulting hours. Maha Strategies scales through an interconnected stack of reusable intellectual property:

1. Foundational IP & Inbound Engine: The Maha Principle (our core book/framework) and our public Protocol Library (covering Metabolic Sovereignty, Digital Firewalls, Hardware Sovereignty). These serve as authoritative assets that pull high-value decision-makers into our orbit.
2. Strategic Intelligence (The Commercial Wedge): High-conviction, deeply audited technical research briefs (covering topics like Angstrom-era semiconductor architecture, U.S. chip sovereignty, and AI software cost trajectories through 2040) governed by our proprietary OS-01 provenance standard.
3. Strategic Doctrine (The Scale Engine): Reusable operational frameworks (Saturnian Vision, Harmonic Command, Protocol of Precision) designed for high-ticket enterprise integration and licensing.

Your Mandate

Your immediate focus will be weaponizing the Strategic Intelligence layer. You will be converting high-level attention from our public frameworks and active research studies into closed commitments for our $2,500 Verified Research Briefs.

During the initial 90-day validation phase, your role isn't just "closing"—it is epistemic market discovery. You will partner directly with the founder to map out exactly where the enterprise pain points intersect with our intelligence products, refining the pitch based on raw market signals.

Who You Are

• An Intellectual Consultant, Not a Script Reader: You don't rely on generic high-pressure sales tactics. You sell by educating, demonstrating competence, and helping sovereign leaders solve existential operational risks.
• Systems Thinker: You understand the difference between selling a one-off commodity and scaling an IP licensing ecosystem.
• High Technical Literacy: You have a deep curiosity about advanced technology (LLM infrastructure, hardware, macro-trends) and can speak fluently with executives, investors, and policymakers.
• The Builder Mindset: You accept that pre-revenue environments require grit, strategic patience, and the ability to turn chaos into a repeatable playbook.

How to Apply (The Diagnostic Filter)

Do not send a generic resume or boilerplate cover letter. They will be immediately archived.
To ensure we are aligned on the core value proposition of Maha Strategies, please send a short response (maximum 300 words) addressing the following real-world scenario:

A mid-market enterprise executive looks at our $2,500 Verified Research Brief offer and says: "This looks impressive, but why would I pay you $2,500 when my internal strategy team can just feed this same research topic into Claude or ChatGPT for $20?"

How do you respond to this objection to pivot the conversation toward our unique value?

I shipped this: a health app exposing an MCP server, so your own agent reads your live HRV/RHR and can trigger a full-screen circuit breaker when it detects doomscrolling fatigue. Tested it end-to-end today — said "go" in a Claude chat, my phone locked into a breathing protocol.

Curious what builders here think: useful guardrail or dystopian? MCP server is public on Smithery (mayone/cognitive-gateway) if you want to poke at it. Stack: Capacitor/React, Node/socket.io gateway, works with any MCP client.

The failure mode that worries me in AI-assisted writing isn't bad prose — it's fluent, confident fabrication. A statistic that doesn't exist. A citation to a paper nobody wrote. When I audited AI-suggested citations in my own nonfiction drafts, the majority of unchecked ones contained fabricated references. The prose around them was fine, which is precisely the problem: nothing reads wrong.

So I stopped treating verification as a vibe and started treating it as a bookkeeping problem. Every substantive claim in a draft — anything a reader might rely on: facts, numbers, attributions, causation — gets one of five tags:

VERIFIED — I personally checked the primary source or reproduced the result.
SOURCED — attributed to a real, identifiable source I've read, but not independently verified.
BOUNDARY — the claim is honestly about the limits of knowledge (open questions, untested conjecture). Uncertainty stated as uncertainty.
ILLUSTRATIVE — analogy, metaphor, thought experiment. Explains something; asserts nothing.
UNVERIFIED — asserted without confirmation. This one is a workflow state, not a shipping state: the draft isn't done while any of these remain.

Two rules do most of the work:

1. Statistics and quotes are never "illustrative." If a number or quotation appears, it's VERIFIED, SOURCED, or it comes out. No real-seeming figure gets to hide as flavor.
2. Every AI-suggested citation is UNVERIFIED until a human opens the source. Existence, authorship, and content all have to check out. This single rule catches most fabrications, because models are much better at inventing plausible citations than real ones.

What surprised me in practice: the tags change how I write with the model, not just how I check it. Knowing every claim will need a tag, I stopped letting the AI produce claim-dense filler ("studies show...") in the first place — it's cheaper to draft without unverifiable assertions than to launder them out later. The second surprise is how many of my own from-memory claims ended up UNVERIFIED. The discipline doesn't just catch the model; it catches me.

I keep the tags inline while drafting and strip or keep them at publication depending on the project (in my books I keep them — readers seem to trust the text more when it admits what wasn't independently checked).

Curious how others here handle this. Do you verify claim-by-claim, spot-check, or trust-but-disclose? And has anyone found a good workflow for the citation problem specifically?

My book goes live on KDP this Friday, and I spent this week doing a final pass on the machine-readability layer — llms.txt, JSON-LD, Bing/IndexNow. Three findings worth sharing, one of them at my own expense.

1. My Book schema was invalid the entire time, and nothing told me. One missing comma after an isPartOf line meant the whole JSON-LD block failed to parse. Browsers don't care, the page renders fine, Search Console doesn't flag it as an error — the block just silently doesn't exist to crawlers. If you have structured data on your book site, paste the page into Google's Rich Results Test today. Don't assume it's valid because it looks right.

2. llms.txt is probably not doing what you hope. I maintain llms.txt files across six domains. When Google's AI Overview finally described my book accurately, the cited source wasn't any of them — it was a Reddit ARC thread. Ahrefs' crawl of 137K sites found ~97% of llms.txt files never get read by AI bots. Keep the file (it's free to maintain), but the actual machine-readability stack, in order of what's working: valid schema markup on real pages > third-party mentions (Reddit, Goodreads, reviews) > FAQ-style crawlable content > llms.txt.

3. The five-minute wins most authors skip: verify your site in Bing Webmaster Tools (one-click import from Search Console — ChatGPT's browsing largely runs on Bing), and use IndexNow or manual URL submission on launch day so the "available now" version gets recrawled the same day instead of next week.

The uncomfortable takeaway from all this: the self-descriptive layer (your own site, your own manifest files) matters less than I wanted it to. AI systems weight independent corroboration the way search engines weight backlinks. The building was the easy part; getting third parties to mention the thing is the actual game.

The book, for context: The Maha Principle (Kindle, July 10). Happy to answer questions on any of the setup — schema, IndexNow, KDP timing.

I wrote a nonfiction book with heavy AI assistance, and the thing I want to share isn't "look what I made" — it's the guardrail system, because the hardest problem wasn't getting AI to write, it was stopping it from confidently making things up.

If you write nonfiction with these tools you already know the failure mode: ask for support and it hands you plausible-sounding citations, some of which don't exist, and claims stated with a confidence the evidence doesn't earn. Left unchecked, that's how you end up with a book that reads well and falls apart the moment an expert opens it.

The discipline I landed on, which actually worked:

• Provenance tags on every claim. Everything got marked as one of: [SOURCED] (real citation I verified), [VERIFIED] (checked against a primary source), [ILLUSTRATIVE] (a useful example, not evidence), or [UNVERIFIED] (flagged, not allowed to ship). Nothing reached the manuscript still tagged unverified. The tags forced me to know which category every sentence was in.
• AI drafts, a separate pass verifies, and they're never the same step. I used one tool for drafting/synthesis and a different process for checking — deliberately, so the thing that generated a claim wasn't the thing that blessed it. Fabrication slips through when generation and verification collapse into one step.
• Falsification-first. For any claim I wanted to be true, I went looking for the study that would disprove it before I went looking for support. This caught the worst errors.

Here's the part that proves it matters. An early reader — exactly the rigorous kind you want — pushed back that some of my health claims read as pseudoscience: numbers stated more precisely than the evidence supports, correlation dressed as causation. He was largely right. When I went back and actually verified the contested claims, I found a couple that were pointing in the wrong direction — targets that, taken literally, would've been actively bad advice. AI had generated them fluently and I'd under-checked them. Fixing them (with real, verifiable sources) did more for the book than any amount of polish.

The lesson I keep coming back to: AI is a genuinely great drafting partner and a dangerous authority. The entire skill of writing nonfiction with it is building the discipline that treats its output as a draft to verify, never a source to trust.

Curious how others here handle this — what's your actual system for catching fabricated citations and overclaims before they ship? Do you tag provenance, verify in a separate pass, something better?

(For context, this came out of writing a specific book that's releasing soon, plus a companion app — happy to share specifics if useful, but I'm more interested in comparing methodologies. If anyone wants to see the tagging system applied to a real manuscript or is up for kicking the tires, say the word.)

I've spent the last stretch building something I haven't seen done much: a nonfiction book (The Maha Principle, out July 10) paired with a companion app (Maha OS) where the two are actually meant to work together, not just exist as a book and a separate "brand app."

The integration idea, concretely:

The book makes an argument about metabolic health, attention, and habits. The app is the practical side — a local (on-device) ingredient scanner, habit tracking, and short plain-language explainers that mirror the book's reasoning. The concept I'm still figuring out is the bridge between them: chapter-end QR codes that deep-link into the relevant part of the app, so a reader finishing a chapter can immediately do the thing it describes. Book gives you the why; app gives you the how; the link between them is the product.

A few honest things I learned building it, since this sub is more about the how than the pitch:

• The register almost sank it. My first drafts (book and app both) were written in this intense, militarized voice — "reclaim your sovereignty," "defense grid," that kind of thing. A sharp early reader flagged it as overclaiming, and re-reading the app store listing next to the actual calm app, the mismatch was embarrassing. Rewrote the whole surface to a plainer, evidence-first register. Lesson: your marketing voice and your product voice have to be the same voice, or careful people notice and bounce.
• The book-to-app funnel is backwards at launch. I built a whole QR-insert system to send book readers into the app — then realized I have almost no book readers yet, so that funnel points from nothing to nothing. The funnel that actually matters early is the reverse: pointing an existing audience at the book.
• "Verify everything" is harder than it sounds. An early reviewer pushed back on some health claims; checking them properly, I found a couple that were pointing the wrong direction entirely. Fixing those (with real citations) did more for the thing's credibility than any feature.

Where I'm stuck / what I'd love input on: the deep-link bridge is the piece I'm least sure about. Is a QR-at-chapter-end too clunky? Has anyone here done book↔app integration and found something that actually gets used?

And — no pressure at all — if anyone's curious enough to want to try the book+app together and tell me where the seams show, I'd be genuinely grateful for a few testers. Reply or DM and I'll sort out access. Honest criticism especially welcome; it's already made this a lot better.

This sub has mostly been me thinking out loud. Time to change that — I'd rather it be a workshop than a build log.

So: what are you working on? Not the polished pitch — the actual messy state of it. I'll do my best to help troubleshoot anything I can, and I'm hoping others here will pile in too, because most of these problems are ones someone else has already hit.

To make it easy to jump in, a few prompts — answer any, ignore the rest:

• What stage are you at? Idea, drafting, mid-revision, formatting, launched, stalled.
• What's the one thing blocking you right now? The specific wall, not the general overwhelm.
• Where does AI sit in your process — and where has it burned you? Fabricated citation, confident-wrong fact, flattened voice, lost the thread across a long doc?
• What would actually help — a second pair of eyes, a workflow someone's already solved, or just knowing you're not the only one?

I'll go first, with a real one I'm chewing on:

I'm building a verification pass that catches AI-introduced fabrication before it reaches a reader — the falsification-first discipline behind my book. The open problem: catching the confident errors. Obvious hallucinations are easy; the dangerous ones are plausible, well-formed claims that are subtly wrong — a real citation pointing at the wrong finding, a statistic that's directionally right but off. My current pass relies too much on me manually re-checking sources, which doesn't scale. If anyone's solved the "trust but verify at volume" problem, I want to hear it.

No gatekeeping on what counts as "agentic publishing" here — if AI touches your process anywhere and you're trying to do it honestly, you're in the right place. Drop what you've got.

I want to share the process behind a nonfiction ebook I just published, because the interesting part isn't that I used AI — lots of people do now — it's the discipline I had to build around AI's biggest failure mode: it fabricates, confidently and constantly.

Here's the approach I landed on, four principles:

1. The human owns every claim. I designed the framework, argument, and structure. The AI is an instrument, not an author — responsibility is non-transferable.

2. Provenance tagging on every factual claim. Each is marked: verified against source, sourced-but-unchecked, derived, or interpretive. Nothing floats ambiguously between "established fact" and "my assertion."

3. Adversarial verification by a second tool. The tool that drafts isn't the tool that checks. A separate AI runs a pass whose only job is to catch the drafter's fabrications — wrong citations, overclaims. This is the load-bearing step.

4. Failure modes documented, not hidden. When the process catches itself, that gets written down in the work itself.

The failure that proves why this matters: my drafting tool, more than once, produced citations labeled "verified" when verification hadn't happened. They looked flawless — correct journal, plausible volumes, real-sounding authors. They were invented. If I'd trusted the output, I'd have shipped fabricated sources under my name. The verification pass caught them.

A few open questions I'd genuinely like this community's take on:

• Where's the line where "AI-assisted" becomes "AI-authored," if provenance and ownership are clear?
• Is cross-tool adversarial verification actually robust, or just better theater than single-tool checking?
• How do you prove this kind of discipline to a reader who can't see your process?

(The book is The Maha Principle, on Kindle, if anyone wants to see the method applied — and there's a companion whitepaper on Zenodo with the falsifiability conditions. Happy to link in a comment, but the discussion is what I'm actually here for.)

If you'd like to talk about newer methods of publishing content, come add to the discussion at r/AgenticPublishing

I just published my first non-fiction book on Amazon KDP (it's up for pre-order now), and it genuinely wouldn't exist without AI — what used to take ghostwriters or a team of assistants, I was able to do solo. But I keep hitting the same question: how do you actually market a book written this way?

Here's my situation. I'm confident in the book's quality — using AI, I worked hard to make sure it meets or beats the other titles in its categories. But I know quality alone doesn't sell a book; marketing does. And AI-written books still aren't fully accepted in the industry, which makes the marketing question trickier than usual.

So I'm trying to figure out:

• Do you disclose the AI involvement in your marketing, or let the book stand on its own?
• Does the usual self-pub playbook (email list, reviews, launch-week push) work the same for AI-assisted books, or are there extra hurdles?
• Has anyone here marketed a non-fiction AI-assisted book specifically? Fiction advice seems more common, but non-fiction feels like a different game.

I'd genuinely value hearing from anyone who's navigated this — what worked, what backfired, and how you handled the disclosure question. Thanks.

Hi all — looking for ARC readers for my nonfiction book, The Maha Principle: The Architecture of Human Flourishing, releasing July 10.

What it's about: The argument that the modern epidemics we treat as separate — metabolic disease, collapsing attention spans, social disconnection — aren't separate at all. They're coupled outputs of the same extractive system, and the book maps the connections and lays out a framework (Mindfulness, Authenticity, Health, Action) for pushing back. It draws on cognitive science, metabolic research, and systems thinking.

Details:

• Genre: Nonfiction (health / cognitive science / society)
• Length: ~85,000 words
• Format available: EPUB (and PDF if preferred)
• Content: no graphic content; some discussion of health, attention, and modern social conditions
• What I'm asking: an honest review on Amazon and/or Goodreads around launch (July 10). Honest is the only requirement — positive isn't expected or wanted if it's not earned.

Timeline note: I'm being upfront that release is ~3 weeks out, so it's a shorter ARC window than ideal. If you read nonfiction at a steady clip and the topic interests you, I'd be grateful — but no pressure if the timing's tight.

If you're interested, comment or DM and I'll get you a copy in your preferred format. Thank you for what you all do — honest early readers are genuinely how books like this find their footing.