The Solution PDF Generator in Practice: A Field Day

In "Why it matters" I made the case for killing the blank page, and Trevor took apart the machinery in "How it works". This piece is the one I get asked for most: show me a real day. So let me walk you through two versions of the same Tuesday for the same engineer — Priya, a field engineer on our infrastructure team — one before the Solution PDF Generator went live, one after. Same customer, same fix, wildly different afternoon.

The Tuesday before

Priya closes a genuinely tricky problem at 3:15 PM: a storage array at a hospital customer had been silently dropping to a degraded state under load, and after two days she'd traced it to a firmware interaction and pushed a validated workaround. Good work, cleanly done. Then the account manager pings: the customer's IT director wants "something formal" for their change-advisory board by end of day.

Here's how the next two hours actually went. Priya opens a blank document. She digs through the ticket to reconstruct the timeline, because her own notes are terser than a CAB wants. She copies log excerpts and manually scrubs two of them because they contain another tenant's hostnames — a five-minute task that, if she'd been more tired, she might have missed. She hunts for the current logo and the approved boilerplate; the logo she finds is last year's. She writes, reformats, exports to PDF, emails it at 5:05 PM. It's fine. It also took 105 minutes of principal-engineer time, it's structurally different from the report her teammate produced for the same array last month, and the moment she hits send, everything she just assembled evaporates. The next person to hit this firmware bug starts from zero.

The Tuesday after

Same close, 3:15 PM. This time Priya opens the Solution PDF Generator Mission and types one sentence: "Write up the degraded-array firmware fix I just closed for the hospital account, customer-facing, for their change board."

Then she watches it work. The Mission streams its observations onto the Explain rail in real time, so this isn't a black box she's trusting blindly:

• The Intake Agent pulls the ticket, the timeline, and the config change from the ticketing system — read-only — and hands back just the relevant slice.
• The Knowledge Agent grounds the write-up in our approved boilerplate, the disclosure policy, and the prior write-up for the same array family, all drawn from our enterprise knowledge base rather than invented.
• The Draft Agent assembles a branded, CAB-appropriate document — current logo, consistent structure, the log excerpts already scrubbed of other-tenant data because the grounding rules require it.

Ninety seconds in, the Mission doesn't send anything. It stops and posts a [REQUEST_APPROVAL] — a row lands in the decision queue and Priya gets a review link. She reads the draft, tightens one sentence about the maintenance window, and approves. Only then does the Publish Agent render the final PDF, deliver it, and drop a copy in the customer archive. The Report Agent logs the whole thing. Elapsed hands-on time: about eight minutes, most of it reading and one edit.

The outcome, in numbers I can defend

I'm allergic to inflated ROI, so here's the conservative version. Priya's document went from roughly 105 minutes of hands-on senior time to about 8. Call it 90-odd minutes returned per document. Across our team's volume of customer write-ups, that recovered capacity adds up to the better part of a full engineer's week every month — time that goes back into the next escalation, not into formatting.

But the hours are the least interesting part. Two other outcomes matter more to me.

The first is escapes avoided. In the "before" world, the log-scrubbing step was a tired human's judgment call at the end of a hard day — exactly where mistakes happen. In the "after" world, the disclosure rules are grounded in the knowledge base and applied every time, and nothing customer-facing ships without a human approving it in the decision queue. We've moved the safety check from "hopefully Priya remembers" to a structural gate. Consistency isn't a vibe anymore; it's enforced.

The second is compounding reuse. The hospital write-up didn't vanish into an inbox — it was archived and logged, so when the same firmware issue surfaced at a second customer three weeks later, the Knowledge Agent grounded that new document on the first one. The tenth report on a recurring failure mode is now genuinely faster and better than the first. That's the flywheel Harry-the-leader cares about and Priya-the-engineer feels directly: her hard-won solution stopped being disposable.

What it feels like to use

The thing that surprised me most in rollout wasn't the time savings — I'd modeled those. It was the trust. Because the Mission streams its observations, engineers didn't experience it as an AI taking their work away; they experienced it as an assistant showing them its reasoning and then asking permission before doing anything irreversible. Priya stayed the author and the approver. She just stopped being the typist. That posture — reason in the open, gate the send, keep a human on the verdict — is why the Solution PDF Generator stuck, and why it's part of how we deliver business applications rather than a demo that impressed people once. If you haven't read the mechanics yet, Trevor's "How it works" is the companion to this story.