Emily: What We Learned From Our First Users

When we first introduced Emily just over a month ago, we deliberately described her as a beta. Read more about the launch of Emily here.

That wasn’t because we lacked confidence in the technology. Quite the opposite. After months of design, development, testing, and countless internal conversations, we believed Emily was already capable of solving genuine problems. She could manage emails, organise meetings, remember information, schedule reminders, and coordinate tasks across multiple systems. But we also knew something that every product team eventually learns.

The most important phase of building software doesn’t happen before launch. It begins afterwards. No amount of internal testing can replicate the creativity, unpredictability, and diversity of real people using a product in their everyday lives. Developers can imagine workflows. Designers can predict behaviours. Product teams can create detailed personas. But once software reaches users, it immediately begins teaching you things you never expected.

That has certainly been, and continues to be true for Emily. Over the past month, we’ve worked closely with our early users, not simply collecting bug reports or feature requests, but understanding how people genuinely organise their work. We’ve watched Emily become part of daily routines, observed where she saves time, identified where friction still exists, and, perhaps most importantly, discovered entirely new ways people expect an AI assistant to help them.

Looking back, we’ve realised something quite reassuring. We weren’t really building an AI assistant. We were building a better way of getting work done.

Software launches often create the impression that development has finished. In reality, launching a beta is less like crossing a finish line and more like opening the first chapter of a much longer story.

Before Emily became publicly available, we had already built an extensive testing programme. Thousands of deterministic tests verified individual capabilities, while hundreds of real-world scenarios simulated the kinds of requests an executive assistant might receive during a normal working week. We tested scheduling meetings, replying to emails, researching travel options, managing reminders, organising follow-ups, drafting proposals, and handling long conversations involving multiple participants. We even created near-live testing environments where Emily would send real emails to monitored inboxes, allowing us to verify every stage of the experience from beginning to end.

That gave us confidence that Emily could perform reliably. What it couldn’t tell us was whether we were solving the right problems. Only real users could answer that. Within days of launching the beta, those answers started arriving. Some people used Emily exactly as we had imagined. Others approached her in ways we had never considered. Each conversation became another opportunity to understand not just how Emily worked, but how people work. That distinction has shaped almost every decision we’ve made since launch.

One of the biggest surprises has been discovering just how personal productivity really is. When people talk about AI assistants, it’s tempting to imagine that everyone wants the same thing: someone to answer emails, schedule meetings, or organise calendars. In reality, no two users have approached Emily in quite the same way.

Some founders immediately began asking Emily to coordinate conversations with suppliers, draft partnership proposals, and ensure follow-ups never slipped through the cracks. Consultants started forwarding long client email chains and asking Emily to keep track of decisions, summarise discussions, and remind them when conversations had gone quiet. Small business owners began experimenting with recurring reminders, weekly briefings, and automatically prepared meeting agendas. Others simply wanted help improving the tone of difficult emails before sending them.

Perhaps most interestingly, many users rarely asked Emily to create new content at all. Instead, they wanted her to reduce cognitive load. They wanted fewer things to remember, fewer conversations to manually revisit, fewer administrative tasks interrupting deeper work, and fewer moments spent wondering whether they’d forgotten to reply to someone important.

That observation fundamentally changed how we thought about Emily. The value wasn’t in writing another email. The value was ensuring the email didn’t become another task to manage.

One of the advantages of running a genuine beta programme is that users become collaborators rather than customers. Over the past month we’ve spent a significant amount of time speaking directly with early adopters about how they organise their day. Rather than asking what features they wanted, we asked different questions.

• How do you currently manage this?

• What feels unnecessarily difficult?

• What takes longer than it should?

• If you had an assistant sitting beside you, what would you actually ask them to do?

Those conversations proved far more valuable than traditional feature requests.

A seemingly simple discussion about remembering contacts evolved into Emily automatically building an intelligent address book from the people users regularly communicate with. Conversations about juggling different writing styles led to the development of personal and professional voice profiles, allowing Emily to naturally adapt her tone depending on context. Requests to manage longer email chains led to conversation tracking, where Emily can quietly observe a thread before summarising it, identifying actions, or chasing responses when discussions stall.

None of these ideas appeared on our original roadmap. They emerged naturally because we focused on understanding workflows rather than collecting requirements. That’s become one of the defining characteristics of Emily’s development. Rather than designing around technology, we’re designing around the way people already work.

When people think about software updates, they often imagine major new capabilities. The reality is usually much less glamorous. Since launch, Emily has evolved through well over a hundred improvements, ranging from significant new functionality to tiny refinements that most users will never consciously notice. Collectively, however, those changes have transformed the overall experience. In fact, Emily currently consists of approximately 44,000 lines of code, and since the launch of beta, over 100 iterations have been published, with nearly 5,000 automated tests run before each update.

Meeting invitations became clearer. Reminder emails became more useful. Email formatting became more natural. Memory became more consistent. Contact information became richer. Calendar handling became more reliable. Threading across long conversations became significantly more robust. Billing became more transparent. Security protections became stronger. Administrative controls became simpler.

Individually, none of these changes would justify an announcement. Together, they fundamentally improve how Emily feels to use. This is something we’ve come to appreciate throughout the beta programme. Great assistants are rarely defined by one extraordinary capability. They’re defined by hundreds of thoughtful details working together so consistently that the technology gradually disappears into the background.

When software becomes invisible, people stop thinking about the tool itself and start focusing entirely on the work they’re trying to achieve. That’s exactly where we want Emily to be.

Although Emily is fundamentally an email-based assistant, we’ve increasingly realised that email is simply the entry point. The real product isn’t email management. It’s workflow management.

Today, Emily can negotiate meetings between multiple people, automatically create virtual meeting invitations, manage recurring reminders across different time zones, prepare daily or weekly briefings, conduct web research, draft proposals for approval, organise calendar focus time, remember important files and notes, improve existing emails, and quietly monitor conversations that users simply want to keep an eye on.

One feature we’ve particularly enjoyed seeing people adopt is conversation tracking. Sometimes you don’t want to respond immediately. You simply want someone to keep watching. By copying Emily into an email thread with a simple “FYI”, users can ask her to monitor the discussion, summarise developments, identify outstanding actions, or remind participants if nobody responds after several days.

It’s a remarkably small interaction. But it reflects something much larger. People don’t necessarily need AI to replace communication. They need AI to reduce the effort required to stay on top of it.

Originally, Emily was designed primarily for individuals. Very quickly, users within organisations started asking different questions.

• Can our whole team use Emily?

• Can we control what she’s allowed to do?

• Can company knowledge be shared safely?

• Can Emily stay entirely inside our organisation?

• Can different departments work together while maintaining appropriate governance?

Those conversations accelerated our enterprise roadmap considerably. Today, organisations can invite users individually or in bulk, manage company-wide settings, define shared memory, control permitted actions, reserve organisation-specific email addresses, create structured signatures, administer billing centrally, and even restrict Emily to communicating exclusively within verified company domains where appropriate.

Perhaps more importantly, organisations can begin to think of Emily as shared infrastructure rather than an individual productivity tool. That shift has been fascinating to observe. People don’t simply want a better assistant. Increasingly, they want an organisation that works more coherently.

Whenever people discuss artificial intelligence, conversations tend to focus on capability.

• How intelligent is the model?

• How accurate are the responses?

• How advanced is the reasoning?

Those questions matter. But over the past month, we’ve learned that users ask a different question first.

• Can I trust it?

That question influences every product decision we make. Emily is hosted on Google Cloud infrastructure in London. Information is encrypted both in transit and at rest. Sensitive records remain server write-only. Suspicious requests are treated cautiously. External emails are checked for signs of fraud, impersonation, and prompt injection attempts. Emily won’t accidentally send information to another one of your own email addresses or expose details belonging to someone else.

These aren’t the features people notice during demonstrations. They’re the features that quietly earn trust over time. The best assistant isn’t simply the one that can do the most. It’s the one people feel comfortable relying upon.

Artificial intelligence moves extraordinarily quickly. Every week seems to bring another announcement about larger models, faster inference, or increasingly impressive benchmarks. While those developments are exciting, they’ve reinforced something we’ve believed since the beginning.

Most users don’t judge software by benchmark scores. They judge it by whether it works consistently on a Tuesday afternoon when they need to prepare for an important meeting. That philosophy has influenced how we build Emily.

We’ve invested heavily in testing, repeatability, monitoring, and quality assurance because reliability compounds over time. Thousands of automated checks run continuously behind the scenes. Real-world scenarios are replayed regularly to ensure that existing capabilities continue to behave as expected. Improvements are measured not simply by whether something new has been added, but by whether the overall experience has become calmer, simpler, and more dependable.

Innovation is important, consistency is what earns long-term confidence.

Perhaps the biggest lesson from the past month has very little to do with technology. It’s about expectations. When people first hear “AI assistant”, many imagine another chatbot capable of answering questions or generating text. That’s certainly part of what Emily can do. But it isn’t where users find the greatest value. The moments that consistently delight people are surprisingly ordinary.

• A meeting gets organised without several rounds of back-and-forth emails.

• A forgotten follow-up is sent automatically.

• A long email thread is condensed into three concise paragraphs.

• A proposal arrives already drafted before the user sits down to write it.

• A reminder appears exactly when it’s needed.

These aren’t headline-grabbing demonstrations of artificial intelligence. They’re small moments where friction quietly disappears. And perhaps that’s what the future of AI should look like. Not software demanding attention because it’s intelligent. Software is becoming so helpful that you barely notice it’s there.

The beta programme has reinforced our confidence that Emily is solving genuine problems, but it has also reminded us how much there is still to learn. Every conversation uncovers another opportunity to simplify work. Every new user brings a different perspective on productivity. Every unexpected workflow challenges assumptions we didn’t even realise we were making.

That’s precisely why Emily remains in beta. Not because the product isn’t ready, but because we believe the best products are built alongside the people who use them. Over the coming months, we’ll continue to expand Emily’s capabilities, refine existing workflows, strengthen enterprise functionality, and improve the experience in hundreds of small ways that collectively make a significant difference. Join the beta programme here.

If there’s one lesson we’ll carry forward from this first month, it’s this. People aren’t looking for another AI tool. They’re looking for something that quietly removes friction from their day, helps them stay organised, follows through on what matters, and gives them back a little more time to focus on meaningful work. That has always been Emily’s ambition. After listening to our first users, we’re more convinced than ever that it’s the right one.