Systems

The homepage gives you the one-line version: I built an AI system that runs my own sales pipeline, it drafts and chases and documents, and it never sends or decides on its own. That sentence is true. It's also the kind of sentence anyone can write.

This page is the level below it — what the discipline costs on an ordinary Tuesday, what the system does when it isn't sure, and why the least interesting architectural decisions turned out to be the ones that made it trustworthy.

What you won't find here is an inventory of the moving parts. Partly because they change most weeks. Mostly because a parts list tells you nothing about whether a thing can be relied on — you can describe every component of a payment stack and still not know if it reconciles. The discipline is the part that transfers.

The guardrails

Three rules, and they have never been relaxed once.

That third one deserves the detail, because "unverified" sounds like a checkbox and in practice it's the whole design.

Say a deal looks like it should move to a later stage. The system doesn't get to believe that. It has to answer a narrower question: what specific artifact says so? A line in a call transcript, an email in the thread, a calendar record, a signed document. If one exists, the stage moves and the evidence gets attached to it. If none exists, the field is not written. What gets written instead is a note saying the change was claimed and nothing supports it yet — and that lands in my queue rather than in the record.

The same applies to money. A deal amount that traces back to a sentence someone said or wrote is a number. A deal amount that came from a plausible inference is a guess wearing a number's clothes, and once it's in the field, nobody can tell the two apart six months later.

When the system isn't sure, it stops and says so. This is harder than it sounds, because a language model asked to fill a blank will fill the blank — that is the thing it is built to do. Left alone, it produces the most plausible available answer, delivered in exactly the same confident tone as a verified one. So uncertainty has to be a first-class output with somewhere to go, not an exception that gets smoothed over. An empty field is a small inconvenience. A confidently wrong field is a liability that outlives the person who created it.

And the human review step isn't a courtesy to nervous stakeholders. It's load-bearing, for two reasons.

The first is asymmetry. A bad draft costs me thirty seconds to delete. A bad sent email costs a relationship I spent a year building. When failure is that lopsided, you don't optimize for throughput — you put a person at the point where the cost changes.

The second is that reading everything is how I know what's happening. Review is my only instrument. It's the thing that tells me the tone has drifted, or a rule has started firing too often, or a summary is quietly leaving out the one detail that mattered. The day I stop reading the drafts is the day I stop knowing whether any of this is true. A fallback route you never test isn't a fallback. It's a hope.

Engineering, at a level that matters

Two clocks, not one. Some work is triggered by events: a call ends and a transcript exists, so a record gets drafted while the conversation is still warm. Other work can't be, because the thing worth noticing is an absence. "This deal has been quiet for five weeks" is not an event — nothing happens, which is precisely the problem. Absence can only be caught by something that goes looking on a schedule. So anything attached to a real-world moment fires on that moment, and anything that decays quietly gets swept on a cadence.

Cheap checks before expensive ones. This is triage, and the order matters more than the savings. The first pass over the pipeline is deterministic and nearly free: does this deal have a next step, when was it last touched, does this amount trace to anything. Only what survives that filter goes to the expensive work — reconstructing a relationship, drafting outreach, reasoning about what to do next. Cost is the obvious reason. The better reason is precision. Every expensive call is another opportunity to be creatively wrong, so you want as few of them as the job allows, aimed at as narrow a question as you can define.

Context reduction, which is why the history rebuild works. The instinct is to dump everything into the prompt and let the model sort it out. It doesn't. Give it two and a half years of a relationship as raw material and the most recent message shouts over the rest, while the thing that stalled the deal sits somewhere in the middle, unread. What works is a structured pass first: what happened, in what order, what was promised, what blocked it, what has changed since. The draft is then written from that reconstruction, not from the pile.

It's the difference between handing someone a shoebox of receipts and handing them a reconciled statement. Same facts. Only one is usable.

"Found nothing" and "stopped partway" are not the same result. This is the distinction I'd defend hardest, because both produce an empty screen and they mean opposite things. One says the pipeline is clean. The other says you have no idea whether the pipeline is clean.

A run that checked forty records and found forty in good order is a verified-empty result — an answer. A run that checked twelve and then hit a rate limit, or an ambiguous record it couldn't resolve, or an interface that returned an error, is not an answer. It's an unfinished question that happens to look identical from the outside.

So every run has to declare which one it was: what it covered, what it skipped, and why. Verified-empty gets to close. Incomplete gets escalated. Building that in was the single change that did the most for trust, because it's what lets a quiet morning mean something specific instead of meaning nothing at all.

The case study: my own pipeline

The problem. My CRM was accurate about the deals I'd touched that week and fiction about everything else. Deals didn't die from bad decisions — they went quiet, and nobody decided anything at all. Documentation happened at 6pm, last, badly, when it happened. Every salesperson knows this and almost nobody fixes it, because nothing here is broken enough to escalate. It just leaks.

What I built. Not one assistant trying to run sales. A set of narrow, unglamorous jobs, each closing one specific gap: reconstruct the full history of a relationship before anything gets written to it, notice silence before it becomes abandonment, refuse a stage change that no evidence supports, turn a conversation into a record the same day it happened. Each job is small enough that the shape of a correct answer is known before the work starts.

Why it's built that way. The principle came straight from payments: a number without a source is a liability. The system's job was never to be clever. It's to make the record true, and never to be the reason something untrue got into it.

The result. I'm not going to give a percentage — numbers on a page like this are worth exactly as much as your willingness to trust the person who chose them. What actually changed: the second pile — remembering, reconstructing, checking — stopped depending on me remembering it. Problems surface while they're still just a task instead of after they've already cost something, follow-ups go out same-day instead of two days later, and deal context exists outside my head, in a form a colleague can pick up cold.

What surprised me. That the writing was the least of it. Almost everyone I talk to is using these tools to produce text — that's the obvious application and the least valuable one. The real use is work: give it tasks, let it fan out and come back with finished output. I have an unusually good memory and have relied on it my whole career; this beats it not by being smarter, but by being complete and tireless where I'm selective and finite. Full writeup →

What it changed my mind about. The tooling itself — the models, the orchestration around them — is a commodity. Anyone competing with me can buy the identical stack this afternoon, and it gets cheaper every few months. What none of them have is two years of my own customers explaining, in their own words, what they actually needed. That record already existed before any of this was built; it just wasn't readable at a price that made reading it worth doing. The archive turned out to be the asset. The system is just what finally made it legible.

What I'd do differently. I'd build the documentation half first and leave drafting for later. I did it in the opposite order because drafting was the exciting part, and drafting on top of a poor record just produces confident nonsense faster. And I'd build the verified-empty distinction on day one instead of retrofitting it, because I spent several weeks unable to tell a clean pipeline from a broken run, and that uncertainty cost more attention than the automation was saving.

If you want something like this

This was built for my own work, on my own data, and it's genuinely specific to both — which is why what I offer isn't this system. It's the same discipline, rebuilt for your own systems and data, starting with an honest look at whether your process is ready for it. If it isn't documented anywhere yet, there's nothing to automate, and I'll tell you that early rather than late.

If that's the conversation you want to have, the advisory page has the shape of it and what it costs.