Draft, Never Send: How to Deploy AI in High-Stakes Work

Picture an account manager at an engineering services firm that builds roads, bridges, and parking structures. It runs a few hundred projects at once, and each one has an account manager who is not a clerk. She’s a trained engineer. Her job is to price the work, drive out to the site, confirm the pour is hitting its milestones, and keep the client confident that everything is on time.

That’s the job. Here’s the day. Thirty or forty emails before lunch. A subcontractor moved their schedule. A client wants to know when the next invoice is due. Another wants photos of current progress. Take one change order: she has to email the subs for revised hours, update a pricing calculator in Excel, drop the numbers into a proposal template, send it for approval, and log the whole thing in the project management system. Then the client trims the scope, and the cycle runs again.

None of that is hard. It’s just endless. And it’s the reason she tops out at five projects instead of seven. This is the most expensive data entry in the building.

The two instincts that kill it

When a team feels this pain, the first reflex is headcount. Hire an admin, maybe one per account manager. But look at what you’re buying: a second salary to shuffle the same emails, plus a new hop, because the engineer still has to brief the assistant, review what went out, and own the relationship. You scaled the cost, not the expertise. That’s a systems problem, not a hiring problem.

Once a team accepts that, the pendulum swings the other way: “I want the whole thing automated. End to end. Do all of it for me.” I understand the pull. It’s still wrong. End-to-end-on-day-one is the fastest way to build something nobody trusts, and an agent nobody trusts is worse than no agent, because now your team is doing their old job and double-checking a system they don’t believe. Automate everything at once and you remove your own judgment from the loop, and the judgment was the valuable part.

Why high-stakes work changes the rules

An engineering firm is not a SaaS help desk. A mistake here isn’t a typo you apologize for. Firms carry professional liability insurance for a reason: commit to something you can’t deliver, or greenlight the wrong spec, and the fix might be tearing up concrete and re-pouring it. The cost of a bad answer is measured in weeks and six figures, not embarrassment.

You do not hand that kind of authority to an agent. Not on day one, and maybe not ever for the steps that touch a client.

Start with one skill

So you don’t start with the whole workflow. You start with the most repetitive, lowest-risk slice of it. Most of that inbox is rule-based; it sorts into a handful of buckets: scheduling, billing, status, general questions. So you build for that shape, one skill at a time:

1. Triage. Every incoming email gets read and routed into a queue by what it’s actually about.
2. Draft. The system proposes the reply, or the schedule update when a subcontractor slips, and puts it in front of the account manager.
3. Approve. Nothing goes out on its own at first. The human reviews, edits, or rejects.

It is better to do a few things really well than a lot of things poorly. If the first thing an agent touches is reliable, the team leans in and tells you what to automate next. If it’s sprawling and half-right, they quietly go back to email and never come back.

Draft, never send

We build it inside out. The AI does the boring part: it reads each message, understands what the client is actually asking, pulls the relevant project context, and writes a draft reply. Then it stops. A human approves it, edits it, or kills it. The AI never has permission to hit send.

That single choice does more for trust than any accuracy benchmark. Even if the model hallucinates, even if someone slips a prompt injection into an inbound email, the worst thing that can happen is a bad draft that a person reads and deletes. Instead of writing thirty emails, the engineer approves thirty drafts, and the ones that need her expertise are flagged and waiting instead of buried.

But approve-or-reject alone is a trap. Reject doesn’t mean “this is wrong.” It means “now go write it yourself, later,” and later is where good intentions go to die. A binary choice punishes an 80%-right draft the same way it punishes a useless one. So add a third button: edit. Fix the one line that’s wrong and send it from the same screen. No new window, no blank page. An 80%-right draft with an edit box is a 30-second task, not a 15-minute one. When you ask Claude to write an email and it’s close but not quite, you don’t throw it out. You say “change this part.” The people we build for deserve that same move.

Autonomy is earned, not toggled

You don’t treat automation like a light switch: on or off, per user, forever. The default is human. Autonomy is earned by track record.

Start with the low-risk slice and a few willing users. Log every denial and every manual override, because that log is the map of where the system is weak, and you measure success the boring way: edge cases down, overrides down, client feedback up. Then autonomy graduates category by category. If a category keeps coming in with high confidence and the human keeps approving it untouched, it earns a promotion to auto-pilot.

With a hard rule: the moment a single factor changes, a new sender, a new request type, a confidence score that dips below the line, it comes straight back to a human. Eighty percent confident isn’t a number you pull from the air; it’s a threshold you tune from the override log. That gives an operator what a toggle never can: a system that gets more autonomous the more it proves itself, and instantly more cautious the moment the ground shifts. And there’s always an off switch for any workflow the team would rather keep manual.

Prove it, and keep the data put

Here’s the question that separates a demo from a real deployment. Six months in, compliance asks: “Can you prove that no response went out without a licensed person approving it?” If you can’t answer that, you don’t have a product. You have a liability.

Because the AI never holds send permission, the answer is built into the architecture, not bolted on. Every outbound message passed through a human approval step, and every one of those approvals is logged. You’re not trusting a policy; you’re pointing at a record. We also start in shadow mode before anything touches production, running the AI alongside the manual process until the results line up. And the clients’ data never leaves their systems: read and write access is scoped on their side, actions bounded on ours. We use what we need in the moment and don’t hoard it.

Requirements are the whole game

Here’s the part engineers hate to hear. The model is not the hard part anymore. The requirements are. We aren’t from our clients’ domain, and when a team lives in change orders and subcontractor schedules, half of what matters is unwritten. Build a system to pull the wrong fields out of an email and you haven’t saved anyone time; you’ve built the wrong thing quickly.

So you show the work at every stage: here’s what the system extracted, here’s how it categorized it, does this match how you actually think about it? A thumbs-up on the extraction is worth more than any clever architecture. And when the system hits something it wasn’t built for, it drops into a manual review bucket instead of guessing. A confident wrong answer is far more expensive than an honest “I don’t know.” The reusable architecture carries from client to client; the skills are custom every time. So you pick one champion, build one skill really well, and let them sell it internally before you expand.

The model is the easy part

A year ago, the hard problem was getting the AI to produce something useful at all. That’s mostly solved. The hard problem now is the design of trust between a person and an agent. An edit button instead of a reject button. Autonomy earned category by category instead of flipped on all at once. Requirements nailed before a line of automation gets built. A manual bucket for everything the system isn’t sure about. None of that is a model capability. All of it is a design decision.

Which is the whole reframe. AI doesn’t replace your experts. They’re the most valuable thing you have, and the fastest way to waste them is to let rule-based admin eat their calendar. The best implementations do the plumbing, the reading, the drafting, the remembering, and hand the decision back to the human every single time.

Don’t hire the admin. Build the system that gives the expert back to the work only she can do. Start small. One skill. One champion. Human in the loop. Draft, never send. Every action gets a yes, a no, or a quick edit.

Go figure.