Designing the AI-native workspace our brokers want to use.

arqu’s team receives dozens of emails from retail and carrier brokers. When I joined, the brokers were using a generic email inbox to field and respond to all of these emails. Separately, we were asking them to enter and track all deals within arqu’s core web app - kicking off new deals from retailers, updating data, entering quotes as they came in from carriers, etc. This meant heavy manual entry and constant tab-switching.

Deal kickoff was the biggest bottleneck. Moving a single deal from intake to market took about 40 minutes and was the biggest drag on the team’s throughput. There were deals falling through the cracks because the team didn’t have the bandwidth to process them before it was too late. There were even cases where the submission email got lost in their inbox, never being processed at all.

That wasn’t the only problem. As a startup with only engineers — no product or design — development was slow, expensive, and untested. When a needed feature finally shipped, it created more friction in the brokers’ process, often causing them to go right back to the manual process they were used to rather than asking for improvements. Features were being built, but they weren’t lightening the load. Sometimes, they were doing the opposite. They hired a Head of Product to “fix” this problem, who hired me to help shortly after.

After a few months of eating the elephant one bite at a time, we realized we had to start over. We couldn’t possibly “fix” the existing product quickly while staying relevant with the advancements and adoption of AI tooling. Rather than shove AI features into the existing app, we decided to start from scratch and build an AI-native one.

Because every deal starts and ends in email, the inbox is where brokers spend nearly all their time. That had to be the foundation.

The concept: an AI assistant living in a workspace where email and deal, company, and historical context all live together.

As a team brainstorm, we documented everything brokers had to do across a deal’s lifecycle — almost all of it manual at the time. Then we marked every point where AI could or should step in and take the load off the broker.

By our estimate, we could cut the broker’s touchpoints in a deal from 18 to 5. That map became the basis for our roadmap.

We were working with a greenfield - so where to start? I had plenty of ideas for what the platform could be if I were the user. But I didn’t yet know my actual users well enough to know what they’d actually use. A company culture-index survey had already made one thing clear: the brokers and I were very different types of people.

Before I could do anything, I needed answers to three questions:

• What would it take for them to feel confident handing work to an AI assistant?
• What do they care about, what’s unnecessary, and what will make them turn tail?
• How do we work with their process rather than fighting it?

A few findings, some baffling to me, shaped almost every decision after this point. The first two became the spine of how the whole product treats AI:

1. 01

   Let AI put in the sweat; leave relationships to the broker.

   Brokers are people people. They read body language, they win deals by building personal connections and trust. They would never allow AI to interfere there. AI should absorb the manual effort, not stand between a broker and their connections.

2. 02

   Earn trust step by step.

   As a starting point, the agent can take a first pass at a task, but the broker needs a chance to catch errors before moving on. As accuracy and trust grow, the intervention can be dialed back, with one major caveat: the broker always gets final say before any email goes out.

3. 03

   One orchestrator, not a fleet of bots.

   Brokers don’t want the overhead of managing distinct agents. They want to tell a single, all-knowing assistant to “get it done.”

4. 04

   The “digital desk” has to be theirs.

   The inbox/dashboard is where they spend their day; customization in this space is critical. The team was all over the map with how they’d want information organized, so they need optionality.

5. 05

   For these users, more is more.

   Now the one that baffled me... Density reads as powerful, not cluttered. Brokers are master multitaskers and need to keep a pulse on everything that’s happening, so they want it all at once.

I built early concept mockups to pressure-test what I’d heard during our interviews and to, ideally, get some early emotional investment in the project. So, I committed a sin - I came out of the gate at high-fidelity. I wasn’t working with product people. I had a hunch that if I threw a wireframe in front of the brokers, it would spook them and we’d be dead in the water.

I knew an honest read would be hard to get. Our brokers are people-pleasers, so they would be nice and accepting. I didn’t need much, just an inkling or slight lean either way. Hoping to glean something from their live reactions, I showed each person the mockups one-on-one. To my disappointment, every reaction was dead neutral. “Looks nice.” The body language was indifferent. Nothing to say about the concept or the look and feel.

Accepting that perhaps my hunch was incorrect and starting with high fidelity mockups was too distracting, I pulled the visuals back toward wireframes. I also mocked out a handful of complete workflows rather than just having a sampling of static screens. My hope here was that the brokers could get a sense of how the product might work in motion without the visual design in the way.

To my dismay, lower fidelity brought more confusion, not less.

In retrospect, it does make sense. It’s a big ask for someone who doesn’t do this for a living to imagine how a product will feel from images and arrows.

Figma prototypes are great, but they don’t use real data. They still require a leap in imagination to conceptualize. They’re also labor-intensive to build and iterate on, which we didn’t have time for as a startup.

So I vibe-coded one.

The engineers had already built the foundation of the email client - authentication into our live inboxes, and an API into the existing platform - so we had access to live email and deal data. Working in Cursor, I built a complete prototype as a non-technical designer in under a week.

The moment brokers could log into their own inbox and actually use it, everything changed.

They could finally see the vision, and they loved it. I worked with them over the following weeks to iterate and we ended up with stubbed out version of a product we were all genuinely excited about — because for the first time, people were reacting to something real instead of something imagined.

The prototype wasn’t shippable; the goal had been to build fast, not well. So we broke it into smaller, shippable chunks. Over the following months I became a quasi-engineer, shipping my own PRs alongside the rest of the team. In the beginning, I was making tweaks and edits to the work my engineers were shipping. But I quickly began to ship my own features, further increasing our throughput.

There were hiccups along the way as I learned - a couple of massive PRs that took days to review, one that somehow duplicated a chunk of existing code, a couple of days where I was unknowingly working the same issue as an engineer. But we learned and pivoted quickly, and I picked up far better, more efficient ways of working from my teammates. I shifted from using Cursor and sticking to a single branch at a time to using worktrees in Claude Code so I could have multiple PRs in flight and easily review the engineers’ PRs without halting my own work.

My earlier research had handed me a guiding principle: earn trust incrementally. Give the broker constant chances to course-correct, and put hard guardrails on the high-stakes moments - no email goes to a carrier without a human “yes.” The question was how to honor that without burying the broker in confirmation steps.

Take deal kickoff, the bottleneck I referenced earlier. The agent could extract and cleanse the retailer’s data, run the risk analysis, and package it for the carrier. But agents aren’t right 100% of the time; they only improve as you correct them. In the meantime, the broker had to be able to catch a wrong field - fast, and without it feeling like a second job.

The obvious patterns both failed that test. Human-in-the-loop components in chat make sources easy to compare, but they march the broker through every field one-by-one — slow, and needless, since a broker can spot most wrong values at a glance. Dropping the data straight into the UI fixes the speed, but the moment a value isn’t one they already know, they’re back hunting through a pile of documents. Neither actually beat their existing process.

So I kept the data in the UI but pulled the source in with it. Every extracted document and email lands in the workspace as a quick-access tab, and each field carries a small highlighter button - click it and the workspace flips to the right document, scrolls to the exact line, and highlights it. The agent fills the form; the broker verifies at a glance, and only when they need to. The agent proposes. The broker decides.

Our first focus was the bottleneck I mentioned earlier: deal kickoff. A submission email arrives from a retailer; we normalize the data in our system, produce the artifacts to market the deal, and send submission emails out to carriers. That used to take a broker about 40 minutes on average. We got that number down to 2 — a 95% reduction.

More telling than the metrics: brokers chose it.

The adoption was real and consistent. They loved having everything in one place, a more friendly experience, and having the time back that they used to spend on manual work; the exact behavior the old tools never earned.

The biggest lesson wasn’t about AI — it was about evidence. With these users, no amount of fidelity in a static artifact could substitute for putting the real, working thing in their hands. Prototyping on the production path collapsed the distance between “imagine this” and “try this,” and that’s what finally earned honest feedback and real adoption.

It also reset what I think a designer’s toolkit can be. Being able to open Cursor or Claude and ship my own PRs meant design decisions got tested in a real environment in days, not weeks or months. It made me a sharper partner to engineering, not just a hand-off upstream.

There’s no shortage of things I’d still improve, and plenty I’d do differently with more time. But that’s product development — and getting to build something people genuinely chose to use is the part I’d sign up for again.