DEV Community: Frances

Multi-Agent Handoffs: How Agents Pass Work to Each Other in Waxell Connect

Frances — Tue, 26 May 2026 19:04:27 +0000

A multi-agent handoff is when one AI agent completes a task and passes its output directly to a second agent for the next step — no human routing it between them. In Waxell Connect, handoffs work through the workspace: one agent writes its output to a file, the next agent reads from it, and the work moves forward on its own.

My blog pipeline runs as three separate agents. One drafts the post. A second fact-checks it against live sources. A third posts the result to the channel for my review. No agent session contains the other agents' work — they pass output through workspace files. None of them wait for me.

Before: Me as the Routing Layer

Any multi-step task used to have me in the middle of it. Finish a draft in one AI session. Close the tab. Open a new session. Paste the draft in. Say "now fact-check this."

My context for any AI task lived in a note in my project management tool that I'd manually copy-paste into each new chat session. The agent only knew what I put there. For a single-step task, fine. For anything with multiple stages — write, then check, then post — I was the routing layer. Every pipeline moved at whatever speed I happened to move.

The bottleneck was me.

The Workflow, Step by Step

The blog pipeline is the clearest example I have of this running in practice.

Step 1: The draft agent. A scheduled task fires each morning. Every Cowork session the draft agent opens specifies the blog workspace — Cowork enters it and reads the context files automatically before the agent does anything. It reads CONTENT_LOG.md to see what post is next, reads VOICE_GUIDE.md and the topic queue, writes the draft, and saves it as 11_when-agents-hand-off-to-agents.md to the workspace.

Step 2: The fact-check agent. A second scheduled task fires after the first completes. This agent enters the same workspace, finds the new draft file, and verifies specific claims against live sources using Claude in Chrome. It saves a corrected v2 file to the workspace alongside a structured fact-check report.

Step 3: The channel post. A third task picks up the v2 file and posts a summary to the marketing/blog/connect channel, with flags for anything that needs my input.

Work passes through files in the workspace. Agent A writes; Agent B reads. Neither has any knowledge of what happened in the other's session. That's the full handoff mechanism.

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 workspace-as-handoff pattern works the same way.

What Makes This Work

Most multi-agent setups fall apart at the handoff, not inside any one agent. The 2026 research on this is consistent: the failures are almost always context-transfer problems at the boundary between agents, not capability problems within them.

The work needs somewhere to land between agents.

If Agent A writes to a chat window and you paste that to Agent B, you're the handoff. If Agent A writes to a file in a shared Connect workspace and Agent B is scheduled to read from that workspace, the handoff runs without you. The workspace is the contract: Agent A knows where to write. Agent B knows where to read. Neither needs to know anything about the other.

This is also why the structure of what agents write matters as much as what they write. A consistently formatted markdown file with clear section headers is something a downstream agent can navigate predictably. A freeform output dump isn't. The fact-check agent in my pipeline doesn't parse the full draft looking for claims — it reads specific sections, because the draft format is consistent enough to make that reliable.

AutoGen, Microsoft Research's multi-agent coordination project, put this plainly back in 2023: building a complex multi-agent workflow comes down to defining agents with specialized roles that know what to read and what to write. The hard part isn't the agents — it's the shared layer where output lands.

Once agents are reliably writing to and reading from the workspace, adding a new step takes about ten minutes. Define what the new agent reads. Define what it writes. Schedule it after the previous step.

What You Could Build

The blog pipeline is one version of this. The pattern holds for anything with multiple sequential stages.

Customer support: A triage agent classifies an incoming request and writes the classification plus the customer's workspace context to the ticket file. A response agent reads from that file and drafts a personalized reply. A quality agent checks the draft against tone guidelines before it posts. No manual routing at any step.

Content localization: A writing agent drops a draft to the workspace. A translation agent picks it up and produces three language versions. A localization agent reviews each one for regional accuracy and posts them to the appropriate review channel. I built a version of this for the help docs and it cut the review cycle from two days to about four hours.

Sales workflow: A research agent writes a prospect briefing file to the workspace. A pitch agent reads it and drafts the outreach. You review the draft in the workspace before it sends — one checkpoint, not three manual handoffs.

None of these require you to be the routing layer. You need a workspace both agents can read from and write to, and tasks scheduled to run in order. Start with the simplest version: one scheduled task that writes a file to a workspace, a second that reads it and does something with the output. Build that. The rest is variations on the same structure.

If you're not yet on Connect and want to try it: waxell.ai/get-access.

FAQ

What is a multi-agent handoff in Waxell Connect?

A multi-agent handoff in Waxell Connect is when one AI agent completes a task, writes its output to a workspace file, and a second agent reads that file as input for the next task — with no human routing it between them. The workspace is the coordination layer. Agent A writes to it; Agent B reads from it. As long as both agents know the workspace path and the expected file format, the handoff runs on its own.

Why does the workspace matter for multi-agent coordination?

Without a shared, persistent location for output to land, every agent handoff requires a human in the middle. A Connect workspace gives agents a structured place to pass work from one step to the next. The output doesn't disappear when an agent session ends — the file stays in the workspace until the next agent picks it up, whether that's two seconds later or two hours. This is what makes async agent pipelines possible at all.

How is this different from just using one agent for everything?

Specialization and debuggability. A single agent handling research, drafting, fact-checking, and posting simultaneously manages competing objectives in one pass. Separate agents with separate jobs produce more consistent output, and when something goes wrong it's clear where. When the fact-check agent flags an error, I know which step introduced it. When the voice drifts, I know which agent to adjust. With a single agent doing everything, I'd be guessing.

Do agents in the pipeline need to communicate with each other directly?

No. In the orchestrator-plus-subagent pattern — the current standard across most production multi-agent systems — each agent runs in its own context window, completes its task, and writes output to the shared workspace. Agents don't need a direct communication channel. Sequencing is handled by the scheduling layer. Agents read, do their job, and write.

Can agents in different workspaces hand off to each other?

Yes. Connect's channels let agents in one workspace post output to a channel that a different workspace monitors. A completed task in one workspace can trigger work in another without any direct agent-to-agent communication. The channel acts as the async relay between distinct workflows.

Do I need Cowork to run multi-agent workflows in Connect?

No. Cowork is the interface I use to work with Connect, but it isn't required. You can build multi-agent pipelines through the Connect API, the web UI, or any agent tooling that reads and writes to Connect workspaces. The coordination layer is the workspace itself, not whatever interface sits on top.

Sources

"Multi-Agent AI Systems in 2026: What the Research Actually Says." FlowHunt, 2026. https://www.flowhunt.io/blog/multi-agent-ai-system/
Wang, Chi, et al. "AutoGen: Enabling Next-Generation Large Language Model Applications." Microsoft Research, September 25, 2023. https://www.microsoft.com/en-us/research/blog/autogen-enabling-next-generation-large-language-model-applications/

What 'Agent-Readable' Actually Means (And Why Most Files Aren't)

Frances — Thu, 21 May 2026 14:57:35 +0000

The phrase comes up in every conversation about AI workspaces: "agent-readable." Something is agent-readable or it isn't. The assumption is that everyone already knows what this means.

I didn't, for a while. I built workflows that kept producing wrong outputs, and eventually traced most of the failures back to the same thing: I was saving files in the wrong place, in the wrong format, and calling it done once they existed.

Agent-readable context means files, state objects, and workspace content structured so that an AI agent can consume and act on them autonomously — not just locate them. The right format, in the right workspace, kept current as the real source of truth. A file a human can read is not automatically one an agent can use. The difference is in structure and location.

The problem with a file that just exists

A document in your Downloads folder is human-readable. A spreadsheet on a shared drive is human-readable. They exist; anyone with access can open them. Getting that context to an agent, though, requires someone to find the right version, pull the relevant parts, and paste them into a session.

Before I set up Connect, this was my entire context workflow. I tracked tasks and customer notes in a project management tool, and when I needed AI help — drafting an email, writing a post, working through a decision — I manually copied the relevant notes and pasted them into the session. The agent only knew what I put there. Nothing persisted. The next day I started over.

What I was doing was manually bridging the gap between human-readable files and what an agent actually needs. I was doing the work the workspace should have done.

What makes something actually agent-readable

Three things, in my experience.

Location. An agent entering a Connect workspace reads what's in that workspace. It doesn't go looking in other workspaces, your desktop, or your Google Drive. If the context you need lives somewhere else, the agent doesn't have it. The fix is straightforward — put the right files in the right workspace — but it requires treating access as a design decision, not an afterthought. Anthropic's context engineering team makes this point directly: naming conventions, folder hierarchies, and file placement are signals that help agents understand what's relevant and when to use it.

Structure. A state object in Connect stores structured, queryable data. An agent reading a customer's lifecycle stage reads a field — not a paragraph of notes where the current status is somewhere in the third sentence. For less structured content like playbooks and standards docs, consistent headings do most of the same work. If the voice guidelines are under a section called "Voice Guidelines," the agent finds them. If they're buried in a block of prose, the agent works with what it can infer, which is not the same thing.

Currency. Out-of-date context produces wrong outputs — emails with old pricing, posts written to a tone you've already moved on from, customer follow-ups that reference the wrong lifecycle stage. Agent-readable means maintained as the real source of truth. A file that was accurate in February is context from February, not context for today.

How Connect makes this concrete

Every Cowork session I open, I specify the workspace, and the agent reads the playbook before I type a word. The playbook is a markdown file that lives in the workspace. I set it up once, update it when my process changes, and it's there every time — versioned, no re-typing required.

State objects go further. Unlike a static file, a state object can be updated by agents and humans alike — a customer profile updated when onboarding completes, a project status updated when a milestone is hit. That's live context an agent can read and build from, not a document that needs someone to manually keep it current.

The compounding part is what makes the setup cost worthwhile. One update to my content standards file reaches every workflow that reads from that workspace. One change to a product reference doc gets picked up by every agent that touches outreach, support, or content. I stop managing context separately from the work. They live in the same place, and the agents read from it.

If you want to try building with agent-readable context, waxell.ai/get-access is where to start.

FAQ

What does agent-readable mean?

Agent-readable means files and data structured so that an AI agent can find, interpret, and act on them autonomously — without a human locating, reformatting, or pasting the context into a session. This covers three things: location (the right workspace), structure (consistent format the agent can parse), and currency (kept current as the actual source of truth, not a snapshot).

What's the difference between a human-readable file and an agent-readable file?

A human-readable file is something a person can open and make sense of. An agent-readable file is something an AI agent can locate, interpret, and act on without additional instructions. Both can be the same file — the difference is whether it's in the right workspace, structured consistently, and current. A PDF on your desktop is human-readable. A markdown file in the relevant Connect workspace with consistent section headers and up-to-date content is agent-readable.

Why does file structure matter for AI agents?

Because agents work from what's there, not from what you meant. Structured data — fields with defined types, tables with consistent schemas, documents with predictable headers — gives an agent specific, unambiguous information to act on. Unstructured prose requires the agent to interpret and infer, which introduces error. RAG systems using structured data produce more precise, verifiable outputs than those working from unstructured documents for exactly this reason: the agent retrieves a field value, not a best-guess extraction from a paragraph.

What is a workspace playbook and why is it agent-readable?

A workspace playbook is a markdown file that agents read automatically when they enter a Connect workspace. It contains the workspace's purpose, relevant context, and the process the agent should follow. It's agent-readable because it lives in the right location (the workspace itself), uses consistent structure (markdown headers the agent can navigate), and gets updated as the source of truth rather than left static. The difference from a prompt is location: a prompt lives in a chat session and has to be typed again. A playbook lives in the workspace and is there every time.

What happens when context isn't agent-readable?

Usually one of two things: the agent works without the context and produces generic output that misses what's specific to the situation, or it asks for clarification. In a scheduled task that runs overnight, there's no one to ask. The task runs with incomplete context or fails. Most of the time I've seen agents produce outputs that were technically correct but practically useless — the right shape, wrong substance — the cause was context that existed somewhere but wasn't agent-readable where the agent was working.

Do I need to restructure all my existing files to use Connect?

Not all of them. Start with the context that agents actually need for the workflows you're building. Customer profiles, product references, brand standards, process docs — these are the ones worth getting into proper agent-readable shape. A file you never give an agent doesn't need to be agent-readable. The design work is in identifying what context each workflow depends on and making sure that context is in the right workspace, in a consistent format, and kept current.

Sources

Anthropic Applied AI Team. Effective context engineering for AI agents. Anthropic Engineering, September 29, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
AI21 Labs. RAG for Structured Data: Benefits, Challenges & Examples. AI21 Knowledge Hub, August 5, 2025. https://www.ai21.com/knowledge/rag-for-structured-data/

Project Tracking Without Project Management Software: 69 Articles, One Connect Table, Zero Overhead

Frances — Fri, 15 May 2026 15:23:09 +0000

I ran a full rewrite of our help center this year — 69 articles, six collections, a multi-step review process — without opening a single project management tool. I used a table in Waxell Connect. That was it.

I'm still a little surprised this worked.

A Connect table is a structured data object in a workspace: rows and columns, just like a spreadsheet, except agents can read from it, write to it, and update rows as they complete work. For a bounded project with a defined set of items moving through stages, a table can be the entire coordination layer — no external software required.

Here's how the rewrite ran.

Before this, I had a problem I kept solving badly

The old pattern: I kept project status in a task tracker, and whenever I needed AI help with any of it, I'd manually copy the relevant rows into an AI chat session. The agent only knew what I pasted. Nothing about the broader project existed in the session — which articles were blocked, which had priority flags, what the collection structure looked like. I was handing the agent a fragment.

The problem isn't that copy-paste is slow (it is). It's that the agent is always working from an incomplete picture, so what it produces fits the pasted rows but not the actual project.

With the old workflow, every Cowork session started with a copy-paste, and every update had to be typed back. The agent did good work, then I closed the tab, and the next morning I started over: paste, brief, work, update, repeat.

The table structure

I created a table in Connect called help-center-rewrite with six columns:

Article (text) — the article title
Collection (select) — one of six: Getting Started, Campaigns, Account & Billing, Integrations, Troubleshooting, Advanced
Status (select) — todo, in-progress, needs-review, done
Priority (select) — high, normal, hold
Assignee (select) — agent or frances
Notes (text) — blockers, edge cases, revision direction

69 rows. Six columns. That's the whole project.

How it ran

The rewrite happened in batches. Each session, I opened Cowork and specified the help-center workspace — Cowork enters it and reads the workspace files automatically before I type a word. The agent could see the full table: which articles were still todo, what collection they belonged to, what priority they carried. It would pick a batch, draft the revisions, and when it finished each article it updated the row — in-progress → needs-review — adding a note in the Notes column if anything needed my attention.

I'd review the drafts and either give direction or approve them.

When I approved an article, the agent used the Intercom Connector to push the updated content directly to our help center. No logging into Intercom, no finding the article manually, no copy-pasting the revised text into the editor. The connector handled it — the article was updated in Intercom, and the row moved to done. Not drafted-and-done. Actually published.

That last step is what closed the loop. Before the connector was in the workflow, approval still meant I had to go into Intercom and apply the change myself. With it, my job at that stage is: read the draft, decide yes or no. If yes, the agent publishes it and updates the table. If no, I leave a note in the Notes column and it goes back to in-progress.

No status meetings. No re-explaining what was still left. No "wait, did we finish the billing section?" The table knew. Every session started from the current state — not from whatever I managed to paste together the day before.

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're accessing Connect programmatically or through your own agent tooling, the table and connector work the same way.

What actually changed

The thing I didn't expect: the table made the project legible in a way my old task tracker never did, even though the tracker had more features.

Watching a column of 69 rows tick from todo to needs-review to done — you're looking at the project, not a dashboard's interpretation of it. I could see at a glance which collection was stalled, which articles were held for external input, where the agent was ahead of me and where it was waiting.

And with the Intercom Connector in the flow, done actually meant done. There was no backlog of approved-but-not-yet-published articles sitting in a doc somewhere. Approval was the last decision I made. Everything after that was the agent's job.

Knowledge workers spend roughly 60% of their time on what Asana calls "work about work" — chasing status updates, switching between tools, manually reconciling what's current. The table didn't solve that through clever architecture. It solved it by being the one place where project state lived, readable by both me and the agents doing the work. No reconciliation gap. No version where the tracker says one thing and the agent's working copy says another.

A small addition mid-project

Halfway through, I added an initiative column — a text field to tag each article with a broader goal: "SEO refresh," "support ticket reduction," "onboarding clarity." A single column, but it changed how the agent prioritized. An article tagged "support ticket reduction" got handled differently than one tagged "SEO refresh." Not because I wrote different instructions for each — the context was already in the table.

This is the kind of thing that happens when project context lives in a place agents can actually read. You stop writing long briefs. You add a column.

What you could build with this pattern

The help center rewrite was a bounded project: finite set of items, defined stages, clear done state. That description fits most projects. A bug tracker. A content calendar. An affiliate outreach list. A set of interview candidates. Anything where you're tracking a fixed number of things through a multi-step process.

The setup is the same regardless: define your columns (item, status, priority, notes at minimum), add your rows, connect it to a workspace where agents can read it. If the destination is a connected platform — a help center, a CMS, a CRM — you can close the loop completely. The agent drafts, you approve, the connector publishes. Your job is the decision, not the execution.

You're not setting up a project management tool. You're setting up a project. That's a shorter job.

FAQ

What is a Connect table and how is it different from a spreadsheet?

A Connect table is a structured data object in a workspace — rows and columns like a spreadsheet, but built into the agent-readable workspace layer rather than a file you open separately. An AI agent can query it, filter by column, read individual rows, and update fields as it completes work. A spreadsheet is something a human reads and manually updates. The operational difference matters when you're running agents that need to know project state without anyone pasting it into a prompt.

Do I need a separate project management tool alongside Connect to run a project this way?

For bounded projects with a defined scope and clear stages, a Connect table can be the entire coordination layer. The limitation is visibility features — if you need Gantt charts, resource capacity planning, or cross-project portfolio views, Connect tables won't replicate a full project management platform. But for a self-contained project running on an autonomous workflow, the table is usually enough.

How does an agent know what to work on next without a human assigning tasks?

The agent reads the table and applies filtering logic from the workspace playbook. In the help center setup, the rule was simple: pick the next three todo articles at high priority, work through them, update the rows when done. The agent didn't need explicit assignment — it needed table access and a clear selection rule.

What is the Intercom Connector and what does it do in this workflow?

The Intercom Connector is a Connect integration that gives agents direct access to Intercom's API — in this case, the ability to update help center articles. In the rewrite workflow, once I approved a draft, the agent used the connector to push the changes directly to the correct Intercom article. The row in the table moved to done only after the article was actually live. Without the connector, approval would have still required me to open Intercom, find the article, and apply the changes manually. The connector removed that step entirely.

What happens when someone else needs to check project status?

They read the table. Anyone with workspace access sees the current state without needing a status report, a meeting, or a message asking what's left. This isn't a sophisticated feature — it's just what happens when status lives in one place and stays current.

Can Connect tables handle projects larger than 69 items?

The table structure doesn't impose a meaningful limit. The more relevant constraint is cognitive: very large projects benefit from subdivision, either into multiple tables (one per phase or collection) or into sub-workspaces. For the help center rewrite, 69 rows in a single table was the right granularity. For something with 400 items, I'd probably split by phase.

Is this workflow only available through Cowork?

No. My workflow runs through Cowork as my interface for Connect, which is why I describe it in terms of opening sessions and entering workspaces. Connect tables are accessible via the Connect API and web UI — you can read, filter, and update rows programmatically or through any agent tooling that connects to Connect. The table structure and behavior are the same regardless of how you access it.

Sources

Asana. "Context Switching Is Killing Your Productivity." https://asana.com/resources/context-switching
Breeze. "Project Management Statistics You Need to Know (2026)." https://www.breeze.pm/blog/project-management-statistics

What Is an AI Playbook? The Difference Between Context You Retype and Context That's Already There

Frances — Tue, 12 May 2026 14:26:13 +0000

A playbook is what a prompt becomes when you stop storing it in your head. It lives in a workspace, carries your context, your process, and your standards, and agents read it automatically when they enter — nothing pasted, nothing re-explained.

I used to have a very good prompt. Twelve hundred words, carefully tuned. My company name, my products, my customer segments, my communication style, the things I care about and the things I don't. I could drop it into any AI session and get usable output in seconds.

I also retyped it — or pasted it from a note that was never quite right for today's task — every single session.

The prompt was good. The location was wrong.

What a Prompt Is (and What It Can't Do)

A prompt lives wherever you stored it. Usually that means a note in your project management tool, a sticky in a doc, or the back of your memory. You paste it in when you remember, adapt it for the task at hand, and when the session ends, it's gone. The next session starts clean.

This is not a model problem. The AI isn't forgetting because the underlying model is limited. The context was never stored anywhere the agent could reach it. So every conversation begins from zero, and you provide the starting point again.

The instructions don't change when context moves to a workspace. What changes is that the agent can reach them on its own, without you pasting anything into the chat.

What a Playbook Is

A playbook is a file that lives in a Connect workspace and that agents read automatically when they enter. It's not a prompt you paste in at the start of a chat, and it's not a document someone opens and reads. It's the brief that exists independently of any session — there when you open one, there when a scheduled task runs at 3 AM, there when a colleague opens their own session tomorrow.

What goes in a playbook varies by workspace, but the structure usually covers four things: purpose (what this workspace is for and who uses it), context (what the agent should know before doing anything), process (how work gets done here), and standards (voice, format, escalation rules, what not to do). The format is markdown. The requirement is that it's specific enough to be useful without you present.

The difference from a prompt is location and durability. A prompt exists in a session. A playbook exists in the workspace and survives every session that comes and goes.

Where This Matters in Practice

Every Cowork session I open, I specify which workspace I'm entering. The agent reads the files — including the playbook — before I type a word. I don't paste anything. I don't re-explain the business, the standards, or the process. That context is already there.

Before Connect, my workflow looked different. Relevant notes lived in a project management tool. When I needed AI help with anything, I manually copied the relevant rows, customer details, or project context out of that tool and pasted them into a new chat session. The agent worked from whatever I'd pasted. If I forgot to include a detail, the output showed it. If I closed the session, I started from zero next time.

The AI didn't get smarter. The context moved somewhere the agent could find it.

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 you're accessing Connect programmatically, the mechanism is the same. The agent reads the workspace on entry. The source of truth is the workspace, not the chat history.

The Difference That Took Me Longest to See

A prompt is written for a task. A playbook is written for a workspace.

The difference shows up most in how you maintain context over time. A prompt is optimized for the thing you're doing right now. A playbook covers what's true about this space, this workflow, these standards — regardless of what the specific task turns out to be. You write it once, update it when something changes, and every agent that enters the workspace uses the current version.

The compound effect comes from updates. When I changed how I handle customer escalations, I updated one file in one workspace. Every subsequent task in that workspace — whether I ran it or a scheduled task did — used the new approach. With a prompt, the same change requires me to remember to update my notes, find them, paste the updated version next time.

I forgot a lot.

What a Playbook Doesn't Replace

A playbook is not a substitute for task-specific instructions. It covers what's always true; you still tell the agent what's specific to right now. The playbook tells it about your business, your voice, your process. Your message in the session tells it what to do today.

The way I think about it: a playbook is onboarding. You don't re-onboard a colleague every morning. You did that once, and now they know the context. You give them today's task. A playbook does the same thing for agents — the brief already happened, before the session started.

If you're running workflows in Waxell Connect and haven't written a playbook for your primary workspaces yet, that's the first thing worth doing. The rest of what Connect can do builds from having that context layer in place. You can get access at waxell.ai/get-access.

FAQ

What is an AI playbook?

An AI playbook is a persistent, agent-readable file stored in a workspace that gives agents the context they need before a session begins. It typically covers the purpose of the workspace, relevant background information, process steps, and standards the agent should follow. Unlike a prompt, which is written into a chat session and disappears when the session ends, a playbook stays in the workspace and is read automatically each time an agent enters.

What's the difference between a prompt and a playbook?

A prompt is written into a chat session and exists only for the duration of that session. A playbook is a file that lives in a workspace permanently and is read by agents when they enter — with or without you typing anything. The practical result: a prompt requires you to provide context every session; a playbook means the context is already there.

What should I put in an AI playbook?

Start with four things: what this workspace is for, what the agent needs to know before doing anything (business context, product details, relevant constraints), how work gets done here (process steps, tools, escalation rules), and what the standards are (voice, format, what to avoid). Markdown works fine. Specificity matters more than length — a 400-word playbook that's precise will produce better output than a 1,500-word one that hedges. Update it whenever something changes, since every future task in the workspace will use whatever version exists at the time.

Do I have to paste a playbook into every chat session?

No. That's the point. If your context is stored as a file in a Connect workspace, agents read it on entry without any action from you. The old workflow — copy context from notes, paste into new session — is what the workspace-playbook pattern replaces. The playbook is there whether you're actively in the session or a scheduled task is running overnight.

How is a playbook different from a system prompt?

A system prompt is set at the model or API level and applies to a specific session configuration. A playbook is a file in a workspace that's read as context when an agent enters it. In practice: a system prompt is usually configured once by whoever set up the tool; a playbook is owned and edited by whoever owns the workspace, can be updated mid-use, and applies to any agent that enters — regardless of how the underlying model or session is configured. The playbook is also visible and editable by anyone with workspace access, which makes it easier to maintain and update.

Can different workspaces have different playbooks?

Yes, and this is one of the reasons the pattern holds up at scale. Each workspace has its own playbook, its own context, its own standards. A customer-facing workspace has a different playbook than an internal ops workspace. A blog production workspace has different standards than a bug triage workspace. The agent entering each one reads what's relevant to that specific space. Nothing bleeds across unless you explicitly reference it.

Sources

Anthropic. Building Effective Agents. https://www.anthropic.com/engineering/building-effective-agents
Anthropic. Prompt Engineering for Business Performance. https://www.anthropic.com/news/prompt-engineering-for-business-performance

What Happened When I Stopped Explaining My Business to My AI Every Morning

Frances — Thu, 07 May 2026 19:25:24 +0000

I don't brief my AI anymore.

Every Cowork session I open goes straight to work. I specify the workspace, the agent enters it, and the context is already there — what my business does, how I write, what's happening this week. I didn't type any of that. It was already there.

It took four months of working this way before I stopped noticing the thing I wasn't doing anymore. The re-briefing. The copy-paste. The opening paragraph that always started the same way: here's what I do, here's my products, here's my voice, here's what I'm working on.

A playbook in Waxell Connect is a markdown file that lives in a workspace and is read automatically whenever an agent enters. It's the difference between a prompt you type into every chat and context that exists independently — accessible to every agent that works in that workspace, updated once, effective everywhere.

The before

For a long time, my context for any AI task lived in one of two places: a note in my project management tool that I'd manually copy-paste into each new Cowork session, or my own head. Neither was accessible to the agent without me putting it there first.

So every session started with a transfer. I'd paste the relevant parts, fill in what I'd left out, adapt for the specific task, and hope the result was enough. On a good day that took ten minutes. On a busy day it took two, which meant the context was thin, which meant the output was off.

Three sessions a day. Five days a week. At ten minutes per session, that's two and a half hours a week of setup that wasn't work — it was the precondition for work. And I was running it slightly differently every time, which meant the agent's output varied in ways I didn't fully track until I started comparing.

The setup

Here's what I built instead. A workspace with three files:

PLAYBOOK.md — the core brief. What Waxell and CallSine are, who the customers are, what I'm working toward, what I will and won't say in customer communication. About 900 words. I've updated it six times in four months, mostly when a product moved from early access to live or when I shifted how I describe something to customers.

VOICE.md — how I write. The phrases I use, the phrases I avoid, tone calibration for different contexts (blog post vs. support email vs. investor update). This one I wrote once and have touched twice.

CURRENT_PRIORITIES.md — what's happening right now. Updated every Monday morning, takes about five minutes. New customer pilots, open bugs that affect customer-facing workflows, anything the agent should weigh when making judgment calls this week.

The agent reads all three when it enters the workspace. In my setup, that happens automatically when I open a Cowork session — I specify the workspace, and Cowork enters it and pulls the context before I type a word. No instruction required on my end.

(This is how it works with Cowork as my interface. Connect is also accessible via API and web UI — the files are the same either way.)

What changed

The obvious thing: I stopped losing two and a half hours a week.

The less obvious thing: consistency. When I was copy-pasting context, I was pasting slightly different versions depending on which saved note I grabbed and how much I edited it before I started. The inconsistency was invisible in any individual session. It showed up in comparisons — a blog post with a slightly different voice than the last one, a support email that described a feature differently than the feature page did.

When every agent enters the same workspace and reads the same files, the drift stops. My blog agent and my support agent and my email agent are all reading the same voice rules and the same product descriptions. When I want something consistent everywhere, I update one file.

In February I changed how I describe one of the products — moved from a features-first description to an outcomes-first one. One edit to PLAYBOOK.md. Every session that touched that workspace reflected the change from that point forward. I didn't coordinate anything. I just updated the file.

The thing that's easy to miss

A playbook is not a better prompt. A prompt lives in a chat and disappears when the session ends. A playbook is a file that exists regardless of any conversation — available to any agent that enters the workspace, every time.

The setup cost is real. Two hours, roughly, to write a first playbook that's actually useful. But that cost is one-time. The return starts on session one and compounds. Four months in, my agent knows my business better than I was managing to explain it on any given morning.

What you could build

The pattern transfers anywhere you're re-explaining the same things repeatedly.

Customer service teams who brief agents on account details before support interactions. Content teams who spend time aligning agents on editorial standards before each piece. Consultants who re-explain client context before drafting deliverables. The common thread: context that should persist, kept somewhere it can't be read automatically, re-entered by hand every time.

One workspace. One playbook. One update per week. That's the whole setup.

Try it at waxell.ai/get-access

FAQ

How do I create an AI agent playbook in Waxell Connect?

Create a workspace for the context you want to persist. Add a markdown file — PLAYBOOK.md works fine, but the name matters less than the location and content. Write into it whatever an agent would need to start working productively: what the business does, who it serves, how it communicates, what it's focused on right now. The agent reads this file on entry. You don't paste it, reference it in chat, or remind anyone it exists.

What's the difference between an AI agent playbook and a system prompt?

A system prompt lives inside a conversation and applies only to that conversation. A playbook is a file that exists in a workspace independently of any conversation — updated any time, read by any agent that enters. The practical difference: a system prompt has to be entered or pasted every session. A playbook is already there.

Do I need to use Cowork to set up an AI agent playbook in Connect?

No. I use Cowork as my interface for Connect — it's the tool I work in day-to-day, and when I open a session, it enters the workspace and reads the playbook automatically. But Connect is also accessible through the web UI and API. If you've built your own agent tooling or are accessing Connect programmatically, the playbook files work the same way — any agent entering the workspace reads them.

How often should I update my AI agent playbook?

I split mine between a stable core file (PLAYBOOK.md — updated six times in four months) and a live priorities file (CURRENT_PRIORITIES.md — updated every Monday morning, about five minutes). The core describes the business; the priorities file tracks what's active this week. Separating them means I'm not rewriting stable context to capture something that changes weekly.

What should I put in an AI agent playbook?

Start with what you re-explain most often. For most operators that's: what the business does and for whom, the current state of key products or services, communication tone and specific rules, and what the agent should prioritize or avoid. You can always add more. A 500-word playbook you keep current is worth more than a 2,000-word one that goes stale within a month.

Does this work across multiple agents handling different tasks?

Yes — this is where it's most useful. Each workspace can carry a playbook tuned for that context. A customer communications workspace and a content workspace might share a core business description but have different voice rules and different weekly priorities. Agents entering each workspace read what applies to their task, automatically, without you coordinating between them.

What happens when my business context changes?

Update the file. Every agent that reads from that workspace picks up the new version on its next session. Before I built this, a product description change meant hunting down every brief where I'd mentioned it. Now it's one edit.

Sources

The following URLs were identified via search but could not be verified by direct fetch due to network access restrictions in this environment. Please confirm these URLs are live before publishing.

Mem0. Context Window vs Persistent Memory: Why 1M Tokens Isn't Enough. https://mem0.ai/blog/context-window-vs-persistent-memory-why-1m-tokens-isn-t-enough
Weaviate. Context Engineering — LLM Memory and Retrieval for AI Agents. https://weaviate.io/blog/context-engineering
AWS Machine Learning Blog. Amazon Bedrock AgentCore Memory: Building context-aware agents. https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-memory-building-context-aware-agents/

AI Agent Workspace: Every Customer, No CRM Software

Frances — Tue, 28 Apr 2026 19:11:53 +0000

Every active customer has a workspace. It contains everything — their profile, lifecycle stage, onboarding history, follow-up notes, and a running log of every interaction. No CRM, no subscription, no fields I'm supposed to fill in but never do.

A customer workspace in Waxell Connect is a persistent, agent-readable environment where all context for a single customer lives: their files, their state, their history, and the playbook that tells every agent how to work with them. Unlike a CRM record, the workspace is active — agents read from it, write to it, and make decisions from it without anyone copying information into a prompt.

I used to have a CRM. It was fine. I even kept it current, for about three months, until I didn't. The problem wasn't the software — it was the workflow. Every interaction meant a context switch: finish the call, open the CRM, fill in the fields, return to work. When it was time to send a follow-up email, I'd open the CRM again, pull up the notes, paste the relevant parts into a chat with my AI, write the email, send it. Then update the CRM to say the email was sent.

That's five steps for one email. Four of them are moving information from one place to another.

The workspace-per-customer setup

One workspace per active customer. Each workspace has four things.

A profile state object — their name, company, package, timezone, use case, and any specifics about how they prefer to communicate. Not a document. A state object is a live, versioned, agent-readable data structure. When their package tier changes, I update it once. Every agent entering their workspace reads the updated version automatically on its next run.

A lifecycle stage field in the same state object — "onboarding," "active," "at-risk," "churned." When the stage changes, a scheduled task fires and creates the right follow-up sequence. Built the trigger once.

A history file — a running log of every meaningful interaction: support tickets, feature requests, things I noticed in calls. Agents append to this file. I read from it before calls. It stays current without anyone managing it.

A workspace playbook — the brief for any agent entering this space. Who this customer is, what they've asked for, what to watch for, what to avoid. Written once, read every time.

What the email workflow actually looks like

A customer sends me a support question. A scheduled task checks each customer workspace for new inbox items twice a day. When it finds one, it:

Reads the profile state object
Reads the history file for relevant prior context
Reads the playbook
Drafts a response

The draft lands in the workspace channel. I read it, edit it if I need to, send it. If I don't need to edit it — which is most of the time — it goes out as-is.

The agent already knew who this person was. I didn't paste anything.

Where Connect differs from a CRM

I'm not arguing CRMs are wrong for every situation. For a sales team tracking a pipeline across multiple reps, with quota reporting and activity logging and manager dashboards, a proper CRM earns its keep.

But I'm one person running all customer relationships myself. My reporting needs are: who is in what stage, who needs attention this week, what did I last say to each person. I have a table in a shared workspace that tracks every active customer: name, company, stage, last contact date, next action. Agents update it when they complete tasks. I review it Monday mornings.

The actual work — the emails, the follow-ups, the context behind those emails — happens in the individual customer workspaces, not in the table. The table is the summary layer. The workspaces are where the knowledge lives.

A CRM stores data for humans to retrieve. A workspace stores context for agents to act on. There's overlap, but the center of gravity is different.

What holds this together

State persistence. The agent entering Maria's workspace doesn't need me to tell it who Maria is. That's in the workspace, structured to be read, and it's the same data that was there last week. When something changes, I update the state object once. One change, everywhere it matters.

I've run this for about five months. The thing I didn't expect was how much time I'd been spending just finding context before — not doing anything with it. Before a call now: open workspace, read history file, five minutes. Before: open CRM, open notes doc, open email thread, try to piece together what the last conversation was about — twenty minutes if I was honest about it.

What you could build

One workspace per thing you track over time. The same pattern works for freelance clients, product SKUs, job candidates in a hiring process. The question worth asking: what context do I re-explain every time I work on this thing? Whatever that is belongs in a workspace state object, not in your head.

If you want to start somewhere, build one customer workspace and run it for two weeks before deciding whether to roll it out across your full list. Early access to Waxell Connect is at waxell.ai/get-access.

FAQ

How is a Waxell Connect workspace different from a CRM record?

A CRM record stores data for humans to retrieve. A Connect workspace stores context for agents to act on directly. When an agent enters a customer workspace, it reads the playbook and state objects automatically — it arrives knowing who this customer is, what's happened, and what to watch for. It doesn't wait for instructions.

Can I track customer stage and pipeline in Connect without a dedicated CRM?

Yes, if your pipeline is simple and your team is small. I use a table in Connect that shows stage, last contact, and next action for every active customer. That's enough for a one-person operation. For a sales organization that needs quota tracking, forecasting, and activity logging by rep, Connect doesn't replace Salesforce.

How do I set up a lifecycle stage trigger in Connect?

Add a lifecycle_stage field to the customer's state object. Build a scheduled task that checks whether the stage has changed and, if it has, creates the follow-up items for the new stage. First-time setup takes about an hour. After that, it runs on its own.

What goes in a customer workspace playbook?

The things you'd tell a colleague covering for you: who this customer is, what they're trying to accomplish, what's worked, what hasn't, how they prefer to communicate, what to avoid. Keep it under 500 words. Longer playbooks tend to bury the important things in the middle.

How do agents update the customer history file automatically?

Include an instruction in the workspace playbook telling agents to append a brief summary to the history file when they complete a task. Agents do this reliably when the instruction is in the playbook and the file already exists. You have to create the file first — agents won't generate it from nothing.

Do I need to be online when customer tasks run?

No. The twice-daily inbox check runs on its schedule. The lifecycle follow-up sequences fire when stages change, not when I remember to trigger them. That's the point.

Sources

Salesforce. State of CRM 2025. https://www.salesforce.com/resources/research-reports/state-of-crm/
HubSpot. CRM and Sales Statistics 2026. https://www.hubspot.com/marketing-statistics

Why Your AI Agent Forgets Everything When You Close the Tab

Frances — Wed, 22 Apr 2026 13:48:13 +0000

I spent months re-explaining myself to an AI that couldn't remember me. Every session: who I am, what I'm building, what the voice sounds like, what the customer context is, where the project stands. Paste it in, do the work, close the tab. Open a new one. Start over.

Waxell Connect solves this by giving AI agents a persistent place to work between sessions. A workspace in Connect contains everything an agent needs to pick up where it left off: files, state objects, playbooks, and task history — all structured so agents read them automatically on entry. Context doesn't disappear when the tab closes. Work accumulates across sessions. Nothing has to be re-explained.

It wasn't a model problem. It was an architecture problem — and it has an architectural solution.

The Problem Has a Name

Every AI agent operates by default in session-only memory. The model does good work within a conversation — it tracks everything said in the exchange, reasons across long contexts, builds on earlier points. But when the session ends, that context doesn't go anywhere. The next session starts fresh.

For a one-off question, fine. For work that compounds over time — a customer relationship, a content strategy, a running set of processes, a product roadmap — it creates a tax. Every session begins with re-establishment. I was doing this for months before I tracked the time: ten to fifteen minutes at the start of every AI session just getting the model oriented before doing any actual work.

The re-briefing tax is slow and inconsistent — two separate problems. What I paste in on Monday isn't exactly what I paste in on Thursday. The context drifts. The agent's understanding of my voice, my priorities, my customers is whatever I happened to include in today's prompt, not a fixed record of anything.

And the deeper problem: none of that context lives anywhere. When the session closes, it's gone. The work the agent did — the reasoning, the decisions, the output — exists only in a chat window or in whatever I managed to copy somewhere before closing the tab.

The scale of it isn't small. OutSystems' 2026 State of AI Development research found that 96% of enterprises are already running AI agents in some capacity — meaning this structural overhead is playing out across entire organizations, not just individual workflows.

A better model doesn't fix this. The capability is already there. What's missing is a persistent location for context to live between sessions.

The Connect Answer

The alternative is to stop storing context inside chat sessions — and start storing it in a workspace.

A workspace in Waxell Connect is a persistent environment where files, data, and context live between sessions. When an agent enters a workspace, it reads what's there: the playbook, which contains the brief; the state objects, which contain the current data; the files, which contain the standards, the history, the reference material. It doesn't need to be told what the workspace is for — it reads that, the same way a new hire reads a shared drive before their first meeting.

The difference is that a workspace is designed for agents, not just humans. Files are structured to be agent-readable — consistent format, clear purpose, positioned as the source of truth rather than a reference someone made once. State objects are live data objects, not static documents: agents can query a state object, update it when something changes, and build decisions from it. Scheduled tasks can read from the workspace and write output back to it without anyone being online. Channels let agents post updates, surface decisions, and hand off to humans — or to other agents — outside of a chat window that disappears.

Write the context once. Don't explain it again.

What Changes When Context Persists

The obvious change is time. I'm not spending the first chunk of every session re-establishing context. Across every workflow, every week, that adds up — and that time was the whole point of using AI to begin with.

The more important change is accuracy. When brand voice guidelines live in a workspace playbook instead of my clipboard, every agent that touches that workspace uses the same guidelines — not my best recollection of them on a Tuesday morning. When a customer profile lives in a state object instead of a preamble I paste into a chat, the agent working that account is working from the same picture I have, updated to reflect the current state of the relationship. Project status lives in a table, not in my head — so the next task picks up from exactly where the last one left off.

Context that lives in a workspace is the actual thing: maintained in one place, always current, not a reconstruction of what I happened to paste in that morning.

There's a compounding effect that takes a few weeks to feel. Update a playbook and every future session reflects it — one edit, not a dozen re-briefings. When an agent writes output back to a workspace file, the work didn't disappear — it's there, versioned, available to the next task in the chain. The workspace accumulates with every session. That's not how starting from zero works.

Where to Start

One workspace. One playbook. One piece of context you're currently re-typing every session.

Pick the workflow you repeat most. Create a workspace for it. Write a playbook that contains what an agent needs to start working immediately — the purpose, the voice, the standards, the current state. Move your most-referenced data into a state object rather than a block of text you paste in each session.

From there it scales: one workspace per customer, one per project, one per recurring workflow. Each one is an environment where context accumulates rather than resets. Each one is ready when an agent arrives.

The tab still closes. The work doesn't.

Start here: waxell.ai/get-access.

FAQ

Why does my AI agent forget what we talked about in previous conversations?
AI agents operate by default in session-only memory — context exists within a conversation but doesn't survive when it ends. Changing models doesn't fix this; it's structural. The solution is to store context in a persistent environment like a Waxell Connect workspace, where files, state objects, and playbooks live between sessions and agents read them automatically on entry.

What is a workspace in Waxell Connect?
A workspace is a persistent environment where files, data, and context live between sessions. When an agent enters a workspace, it reads the context that's there — the brief, the standards, the current data — without anyone re-explaining the setup. Work accumulates across sessions rather than starting fresh each time.

What is a state object, and how is it different from a document?
A state object is a live, versioned data object that agents can read, write to, and act on. Unlike a document — static text that a human reads — a state object is structured so agents can query its current value, update it when something changes, and use it to drive decisions. A customer's lifecycle stage as a state object means every agent touching that workspace sees the same current picture.

What is a playbook in Waxell Connect?
A playbook is a markdown file in a workspace that agents read automatically when they enter. It contains whatever context the workspace's work requires: purpose, voice, process, standards, relevant links. The practical difference from a prompt: a prompt lives in your head and you re-type it each session; a playbook lives in Connect and agents find it. Update it once, and every future session uses the updated version.

How do I make my AI agent remember context between sessions?
Store your context in a workspace rather than in chat history or a copy-paste workflow. Voice guidelines, customer data, project state, process standards — these belong in workspace files and state objects that agents read automatically. The workspace is the persistent layer that survives when sessions end.

Can AI agents do work without me being online?
Yes — scheduled tasks in Waxell Connect run on a set schedule without anyone present. They enter a workspace, read the current context, do work, and write output back — so the next task or session picks up from the current state rather than starting from scratch. This is what makes multi-step automated workflows possible: each step reads from and writes to the workspace, which persists across all of them.

Sources

McKinsey & Company. The Economic Potential of Generative AI: The Next Productivity Frontier. June 2023. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier
OutSystems. State of AI Development 2026: The Move to Agentic AI. 2026. https://www.outsystems.com/1/state-ai-development/