AI Cold Email Drafting for JLL Brokers
I like AI projects most when they solve a painfully normal problem.
In June, a friend of mine who was working at a JLL brokerage office in Irvine, California reached out and asked if I could help streamline their cold outreach process. Their flow was still very manual: research a person, research the company, draft from scratch, then prep and send in email. It worked, but it was slow, repetitive, and hard to scale.
I said yes. After a few video calls and a lot of back-and-forth consulting over the phone, I flew out and we turned it into a fast, focused build. The core system came together in about a week, followed by another stretch of fine-tuning so drafts matched each broker's tone and email style closely enough to feel natural.
That context matters, because this was never about building a flashy AI demo. It was about saving real time for people doing real work every day.
Where the project really started
At first glance, this looked like a prompt-engineering exercise. It was not. The interesting part was the environment.
The team worked inside enterprise systems with strict security boundaries, and email lived in Outlook desktop. That meant the real challenge was not just generating better text. It was delivering useful drafts into the exact place people were already allowed to work, without adding more friction.
Once we framed the problem that way, the architecture got much clearer: meet users where they are, and make the AI disappear into their existing flow.
What we built (without changing how brokers work)
The system generates personalized outreach drafts using contact and company context, then makes those drafts appear directly in Outlook as normal draft emails.
That one decision changed everything. Instead of asking brokers to live in another UI, the tool fit into the exact rhythm they already used in office:
- trigger the workflow
- see drafts appear in Outlook
- make quick edits
- send from their normal account
No copy-paste loops. No context switching tax. No fighting internal controls.
The firewall constraint shaped the "cool part"
One of my favorite parts of this build was accepting a simple truth: in enterprise settings, the best technical solution is often the one that respects constraints instead of trying to outsmart them.
Rather than trying to push cloud output directly into locked-down mail systems with fragile workarounds, we used a bridge that stayed inside approved boundaries and still gave users an AI-assisted experience. It is not flashy, but it is reliable. In this context, reliability is the innovation.
That is the lesson I keep coming back to: if your users are constrained by policy and tooling, the winning move is to design with those constraints, not around them.
A few technical choices that mattered
Even though this post is intentionally light on implementation details, a few design decisions were important:
- Structured AI outputs: We treated generated subject/body as predictable data, not loose text blobs.
- Two-step writing flow: Draft first, then refine for tone and brevity to match each broker's style.
- Grounded inputs: Contact and company context were normalized before generation so outputs stayed relevant.
- Operational safety: Delivery behavior avoided duplicate draft creation and worked cleanly in everyday use.
Why this one stands out to me
This project ended up being a good example of applied AI in the real world. The model mattered, but the system mattered more: data quality, delivery path, trust boundaries, and user habits all had to line up.
It is easy to demo AI. It is harder to make it feel native in a constrained environment where people already have a proven way of working.
That is the part of this build I am proudest of.
If you are building something similar, my advice is simple: start with the user's actual environment and constraints, then design the AI around that reality.