Notes from building Maddox.

What gets written here, and what does not.

Everything below is written by somebody who worked on the thing it describes. There is no editorial calendar, no outsourced draft and no post whose purpose is to rank for a phrase somebody found in a keyword tool. That is a constraint rather than a boast: it means this index fills up slowly, and it means a post here is worth reading against the software rather than against the category.

The subject is usually a boundary. Where a feature stops, why it stops there, and what we decided not to build — because those are the questions a buyer cannot answer from a demo and the ones a competitor’s marketing site will never volunteer. When we get one of those wrong on this site, the correction gets written up here too, with what was claimed and what the code actually did.

The one we would start with

What we mean when we say autonomous is the post that decides what you can safely leave switched on. Every CRM says the word AI now and several of them say autonomous, and that second word usually carries more weight than the software underneath it can take. The post says exactly what an agent in MADDOX is — a definition you write, scope, test in a sandbox and switch off — and states plainly that no agent sends an email, creates a record, updates a field or assigns an owner. It is the most useful thing on this site for deciding whether to trust the rest of it.

Why the corrections get published too

This site has been wrong in public. A pass over every page against the code found that four surfaces — the homepage headline, a site-wide FAQ answer rendered on three pages, the security page and one article — described agents that act on their own: watching the pipeline, sending the follow-up, escalating to a person when they reached a limit. None of that was implemented. The article was rewritten rather than deleted, at the same address, because the right thing to find at a URL about autonomy is a straight answer about where the line sits.

The same pass found the opposite failure, which is the one nobody expects: five places where the site denied a capability that had since shipped. A denial goes stale exactly the way a claim does, and it is more expensive when it does, because the reader who catches it was reading carefully. We would rather write both kinds of correction down here than quietly edit a page and hope the diff is never read.

What tends to get written about

The recurring subjects are the ones where an implementation decision is visible to a customer and usually invisible in a demo: how recording-consent law is resolved from a phone number and what the rep is actually told before the call connects; why an assistant that can propose a change reads what it executes from the database rather than from the browser that asked; what a deny list is for when it also applies to administrators; what happens to call audio once it has produced a transcript; how a campaign package is proved safe before it is allowed to materialise into somebody’s workspace. None of those are announcements. They are the parts of the product that take a paragraph to justify and one sentence to get wrong.

If you came here looking for the product

The pages that describe what MADDOX does are under the product index, organized as pillars, each with its own hub and pages underneath. How your customer data is held is the one to send to whoever has to sign off, and how buying works explains what a subscription level changes without quoting a figure at you, because there is not one to quote.