Paul Louis · operations and revenue systems
I run a working AI operation, not a collection of prompts.
One system runs my job search end to end, and it has been in daily use for weeks rather than in a demo for an afternoon.
Every morning it tells me what needs me: which applications need a follow-up, which interviews are today, what the queues hold. Every night it runs its checks, repairs what it can, and stays quiet about the rest. When I send it a message, it answers on the same channel and the request lands in a ledger I can read back, with an estimate of when it will be done.
I built it because I was doing the work badly: chasing leads in six places, forgetting follow-ups, retyping the same letter. The fix was not more effort. It was decisions written down once, in code, so they happen without me.
What that shows for a role that has to own a pipeline:
- I diagnose before I build. Every tool exists because a failure was measured first: a dropped message, a filter that filed nothing, a report that silently re-used yesterday's folder.
- I close loops. A report is not done when it is written. It is done when it is delivered, read, and answered, and the answer changes something.
- I can hold a system, not just a task. 267 tools, 1,631 automated checks, 327 documents linted, one person reading the exceptions.
1. A job search that behaves like a pipeline
The problem was not effort. It was that nothing remembered anything.
| The problem | Applications across job boards, agencies and company sites, each with its own questions, follow-up window and deadline. Tracked in six places, chased in none, and the same form answered from scratch every time. |
|---|---|
| What runs | One tracker rebuilt from the application configuration and the ticked reminders. A daily brief. A nightly battery of scheduled checks. A pack per posting: a tailored resume, a letter and the exact form answers, linted before anything can be sent. |
| What it replaced | Six spreadsheets, my memory, and retyping a letter at midnight. |
| The number | 98 applications tracked, 41 packs built, 4 interview briefs generated. Every send passes one gate, so a duplicate send is refused by construction rather than by care. |
- 98 applications tracked
- 41 packs built
- 327 documents linted
- 1,631 automated checks
| Applied | Company | Role | Stage | Next action | Silent |
|---|---|---|---|---|---|
| 2026-10-02 | Acme Industrial | Account Manager | Interview | Brief by 08:00 | 2d |
| 2026-10-05 | Northwind Supply | Sales Rep | Applied | Chase at 5 days | 4d |
| 2026-10-09 | Harbour Logistics | Ops Lead | Closed | None | - |
| 2026-10-14 | Meridian Works | CS Manager | Applied | Pack due | 1d |
2. A loop that actually ends
Most reporting systems are very good at producing documents and very bad at finishing them.
| The problem | Research got written and never read. Requests made by text, mail or chat fell between three inboxes with no record that they existed. |
|---|---|
| What runs | A report is written, rendered to PDF, delivered, and stays marked unread until it is answered. A single-digit reply closes it or turns it into work. Every request is written to a ledger with its status. The queue refuses to hold an alert about an alert, because a promise to do work is not work. |
| What it replaced | A folder of unread PDFs and a memory of what I had asked for. |
| The number | 214 reports written, 18 of them deep research, 55 delivered as PDFs. One of those deliveries found and fixed a queue that had been feeding itself for hours; the fix is now covered by its own checks. |
- 214 reports written
- 18 deep research
- 55 PDFs delivered
- 267 tools
What is deliberately not here
No company names, no employer or client records, no addresses, no screenshots of real mail, no figures tied to a person. The tracker image above is a mocked layout with invented rows. Every number on this page can be reproduced from the project's own files by counting rows and files, which is the point: the claim is checkable, so it does not need adjectives.