A context-driven email workflow is one where the agent drafts a response using data it already has — the customer's profile, their onboarding stage, what they've tried — without anyone pasting that information in first. The context lives in the workspace; the agent reads it when it enters.

I get a support question. My agent drafts a response. It already knows this customer's package, what they've tried, and where they are in onboarding — because that's in their workspace.

That's the whole setup. But getting there took a while, and what I was doing before was annoying enough that I'm surprised I stuck with it.

What I Was Doing Before

Every customer I work with has a profile. Package type. Onboarding date. What's working. What isn't. Any open issues. That information lived in a project management tool I used to track my accounts — fine for tracking, useless for AI drafting.

When a support question came in and I wanted help drafting a response, I'd open the project management tool, find the customer, copy out the relevant fields, and paste them into a new chat session. Then I'd paste the question. Then I'd explain the context. Then I'd get a draft.

Most of the time the draft was good. But I'd done three minutes of copy-paste work just to get there. And if I wanted to check the draft against my tone guidelines, I'd paste those in too. If the customer had an ongoing issue from a previous exchange, I'd go dig that up and paste it as well.

The agent only knew what I handed it. Nothing carried over. Every response started from scratch.

How It Works Now

Each of my active customers has a workspace in Waxell Connect. Inside it: a profile state object with the fields that matter for communication (package, lifecycle stage, onboarding notes, open issues), any relevant product files, and a short playbook that tells the agent what to watch for with this account.

When a support question comes in, I open a Cowork session, specify the customer's workspace, and drop in the question. The agent enters the workspace and reads the files. By the time I've typed the question, the agent already knows who this customer is.

The draft it produces isn't generic. It references their specific setup. If they're in week two of onboarding, it doesn't explain things they should already know. If they've tried something before and it didn't work, it doesn't suggest that thing again. It writes like someone who's been paying attention — because the workspace has been.

When the question is about a specific feature or process, the agent also checks our Intercom help center via Connect's MCP before writing. So the response is built from actual help center content, not the agent's general knowledge about the product. If the answer is in an article, that's where it comes from.

This is how it works in my setup, using Cowork as my interface for Connect. Connect is also accessible via API and web UI — if you've built your own agent tooling or are accessing Connect programmatically, the same workspace context is available.

What's Actually in the Workspace

The customer profile as a state object, not a document

The profile doesn't get manually maintained — that would defeat the point. When a new customer comes in, our sales team fills out a short Cowork questionnaire, and that populates the profile automatically. By the time the customer is onboarding, the workspace is already set up. (The harder part is getting sales to actually fill it out.)

After that, the profile stays current on its own. I have a Cowork rule that scans Gmail and Intercom for incoming support tickets, logs each one to the customer's profile state object, and tracks it through to resolution. New ticket comes in, it's in the profile. Issue resolved, that gets logged too. The entire support lifecycle — from first contact to closed — is in there without anyone updating it manually.

The reason this works as a state object rather than a document is that a state object is live and queryable. When lifecycle stage changes, the field updates. When an issue resolves, it clears. The agent reads current state, not whatever was accurate when someone last edited a doc. A document would require me to be the person keeping it current. The state object handles that itself.

The playbook as standing instructions

Each customer workspace has a short playbook: two or three paragraphs covering what's unusual about this account, what kind of responses tend to land well, what to avoid. Once it's written, it runs. The agent reads it on entry.

I wrote most of these playbooks once, during the customer's first week. I update them when something significant changes. That's a few minutes of work per customer, maybe once a month.

The workspace as context that doesn't disappear

The previous version of this workflow — copy-paste into chat — had a specific failure mode: if I closed the session, everything was gone. The next time I needed to draft an email for the same customer, I'd start over.

The workspace doesn't do that. It's there every time. The agent picks up from where the context actually is, not from wherever my clipboard happened to be.

What Makes This Pattern Last

Customer communication is something I genuinely don't enjoy doing from scratch. I'm not naturally a correspondence person. I'm better at setting up systems than I am at composing emails off the top of my head.

What this workflow does is separate those two things. Setting up the workspace — writing the profile state object, the playbook, the initial context — I'm good at that. The correspondence part then happens mostly without me.

Gartner predicts that 80% of routine customer interactions will be handled by AI in 2026, and Intercom's 2026 Customer Transformation Report puts 87% of senior leaders planning to invest in AI for customer service this year. I'm not trying to automate 80% of anything. I just wanted responses that sounded like they came from someone paying attention, without me having to do all the paying attention manually. That's a smaller goal, and it's one this setup actually achieves.

What You Could Build From Here

The workspace-per-customer pattern scales beyond support emails. The same structure works for onboarding check-ins, renewal conversations, follow-ups on open issues. Any communication that needs to know who the person is and where they are in a process.

A few things I haven't built out yet but plan to. One is a scheduled task that detects when a customer's state object hits a trigger — say, reaching day 14 of a trial without completing setup — drafts a proactive outreach, and posts it to a Connect channel for my review. Right now the workflow is reactive. A question comes in; a response goes out. The next version doesn't wait.

Sierra's Agent Data Platform, announced at Sierra Summit 2025, describes a similar idea at enterprise scale: giving agents memory and access to company-wide customer information so interactions feel genuinely personal. The specific technology is different. The underlying idea — context that survives the session close — is the same one the workspace setup runs on.

If this is the pattern you want to build and you're not yet in Connect: waxell.ai/get-access.

FAQ

What is AI agent email drafting with customer context?

AI agent email drafting with customer context is a workflow where the agent writes a customer communication using data it has already read from a structured source — a workspace file, a state object, a profile — rather than having a human paste the relevant information into the chat. The result is a draft that's specific to this person's situation, not a generic response the human then has to customize by hand.

How does a workspace state object help with email drafting?

A state object is a live, agent-readable data record that updates when the underlying information changes. In a customer communication workflow, the state object holds fields like lifecycle stage, package type, onboarding notes, and open issues. When the agent enters the workspace, it reads the current state. If the customer moved from trial to paid last week, the draft reflects that — without anyone manually updating a prompt or a template.

What did this workflow look like before using Connect?

Before Connect, this meant finding the customer's information in a project management tool, copying the relevant fields, pasting them into an AI chat session, then pasting the incoming question, then adding tone guidelines if needed. The agent only knew what was pasted in. If the session ended, none of it carried over. Every email started over from scratch.

Do I need to use Cowork to set this up?

No. Cowork is the interface I use to work with Connect — when I open a session and specify a workspace, Cowork enters it and reads the files automatically. But Connect is also accessible via its API and web UI. If you've built your own agent tooling or are accessing Connect programmatically, you can set up the same workspace structure and pull context the same way.

How much setup does this actually require?

For the profile itself: less than you'd think, because it auto-populates from a sales questionnaire when the customer is first created. What actually takes time is setting up the Cowork rules that scan Gmail and Intercom for incoming tickets and log them to the right profile — that's probably an hour the first time, mostly testing. The playbook takes 20–30 minutes per customer to write initially. After that, maintenance is light — the profile updates itself as tickets come in, and the playbook only needs editing when something significant changes about the account. The setup cost is front-loaded. Once it's running, it mostly runs.

Can this work for proactive outreach, not just replies?

It can, though I haven't fully built that out yet. The setup that handles reactive responses — workspace, profile state object, playbook — is the same foundation you'd use for proactive outreach. You'd add a scheduled task that checks a condition (lifecycle stage, trial day count, last-contact date), generates a draft when the condition is met, and posts it to a channel for review. That's one more layer on top of what's already there.

What's the difference between this and a mail merge?

A mail merge inserts field values into a fixed template. The output is personal in the sense that it has the right name and the right package type. AI agent email drafting from a workspace reads the full context and writes a response that fits the specific situation — what the customer has tried, where they are in the process, what issues are open. The draft isn't a template. It's a response to this customer, today, as they actually are.

Sources

• FastBots Blog. The State of AI Customer Support Automation in 2026. https://blog.fastbots.ai/the-state-of-ai-customer-support-automation-in-2026/

• Sierra. Introducing Agent Data Platform. https://sierra.ai/blog/agent-data-platform