Rolling Cypher LM Out to a Team

This path is for whoever owns getting a team onto Cypher LM — an admin, an operations lead, or a manager bringing on new hires. It covers onboarding, shared knowledge, roles, and keeping agents consistent as the team grows, so a rollout feels deliberate instead of accidental.

A single person setting up Cypher V for themselves can hold the whole setup in their head: what the agent knows, what it is allowed to do, how bookings and payments are configured. Once a second or third teammate joins, that stops being true. Someone edits the knowledge base without telling anyone. Someone else assumes a toggle is on when it is off. A new hire hears a different explanation of how the agent works depending on who trained them. None of this is anyone's fault — it is simply what happens once more than one person is responsible for something that used to live in a single person's head.

The fix is not more memory, and it is not a long onboarding document either, since documents go stale the moment a feature or a price changes. The fix is a few repeatable habits built around what the dashboard already gives you: a shared knowledge library that stays current, a written playbook that captures how your team actually talks to customers, and clear roles in Settings that match what each person's job actually requires. Put those three in place and a rollout stops depending on any one person being available to explain things.

The goal of a good rollout is simple to describe even though it takes real work to build: a new hire should be able to get access, read or listen to a handful of things, and understand how the business's agents work — without sitting through a long verbal handoff from someone who happens to remember how it all fits together. Cypher LM already gives you the pieces for this in the dashboard itself, in Cypher M's playbooks and library, and in team roles under Settings. This path shows you how to put those pieces together into something a growing team can actually rely on.

What a good rollout produces

• A single place new hires look first (the dashboard Home and Agents sections)
• A shared knowledge library that does not depend on one person's memory
• A playbook that captures how your team actually talks to customers
• Roles that match who should see calls, payments, and settings

The rest of this path walks through each of those in order, starting with what a brand-new teammate should see and do on their very first day.

When a new teammate joins, the first decision is what they need to see, and that decision should happen before you hand over a login rather than after. Not everyone needs access to Payments or Settings; a support rep might only need Calls, Contacts, and Notes, while a manager needs Agents, Analytics, and Automations as well. Go to Settings > team & roles and set their role first, so the very first thing a new hire sees in the dashboard already matches what their job needs — nothing more, nothing less.

Once access is set, walk them through the dashboard in a fixed order rather than letting them click around on their own, which tends to produce a shallow, scattered sense of how everything connects. Start at Home, which gives an at-a-glance view of what is running day to day. Move to Agents next, where they can open any existing agent and see its identity — name, tone, greeting — alongside its knowledge files and the toggles for what it can do, such as booking and payments. From there, Calls shows the call log with transcripts, recordings, and a Recaps tab, which is usually the fastest way for someone new to understand what the agent actually sounds like on a real call, rather than reading a description of it secondhand.

Encourage new hires to listen to two or three recent calls and read the matching Cypher N recap in Notes before they touch anything themselves. This does more to build real understanding than any written explanation could, because they hear the agent's actual tone, the questions customers genuinely ask, and how the agent handles an edge case or a fallback moment. A new hire named Tom Reilly, for example, joining a support team, will learn more from hearing how the agent handled a confused caller than from being told the agent 'handles routine questions.'

If Cypher M is in use, point them to the Copilot section next — Sessions, Playbooks, and Library — since that is where they will spend time once they start taking live calls themselves. Show them a past session so they understand what a live suggestion looks like in practice, rather than describing the feature abstractly. If the business uses Cypher S or Cypher P, show the new hire the Bookings and Payments sections specifically, since these are the areas where a misunderstanding costs real time: a booking made on the wrong calendar, or a payment link sent without Stripe properly connected. A five-minute walkthrough of real bookings and real payment links, rather than a description of how they work on paper, prevents most of the early mistakes a new hire would otherwise make.

Finish onboarding by having the new hire open the Contacts section and search for a contact they recognize or one you point them to, so they see with their own eyes how call history accumulates per caller over time — every past call, its recap, and what was promised. That one habit, checking a contact's history before a callback, is arguably the single most useful thing a new teammate can take away from their first day, and it is worth confirming they have actually done it before moving on to anything else.

A playbook is where your team writes down how it wants calls to go — the questions to ask, the objections to expect, the order to cover things in, and how your best people actually handle a difficult moment. Cypher M uses playbooks during a live call to surface suggestions in real time, pulled from the contact's brief, the playbook itself, and the agent's knowledge files. Without a playbook, Cypher M can still help using knowledge and call history alone, but a playbook makes its suggestions sharper and far more specific to how your team actually operates, rather than generic.

Build the playbook from real calls, not from a whiteboard session or a list of assumptions about how calls should go. Pull up two or three strong recent calls in the Calls log, read the recaps, and note specifically what the rep did well — how they opened the conversation, how they handled a price objection, when exactly they moved to booking a follow-up rather than continuing to talk. Write that pattern down in Copilot > Playbooks as plain, short guidance, the way you would coach a new hire in person rather than the way you would write a formal script. A playbook entry like 'when the caller asks about pricing before describing their need, ask what problem they are solving first' is far more useful in the moment than a generic line a rep is supposed to recite.

Keep playbooks owned by one person, even if the whole team is encouraged to contribute ideas and flag what is or is not working. Without a clear owner, playbooks drift over time — someone adds guidance that quietly contradicts an older entry, two entries start suggesting different things for the same situation, and reps begin ignoring Cypher M's suggestions altogether because they no longer feel consistent or trustworthy. The owner's job is to review every addition, keep the language consistent across entries, and retire guidance that no longer applies — for example after a pricing change, a new product launch, or a shift in who the business typically sells to.

Revisit the playbook on a fixed schedule rather than only when something goes visibly wrong — monthly is a reasonable cadence for a small team, and quarterly for a larger one with a dedicated owner. Pull a handful of recent calls, check whether Cypher M's live suggestions during those calls actually matched what a strong rep would have said in the moment, and adjust the playbook accordingly. A playbook that is six months old and has never been touched since is often worse than having no playbook at all, because it quietly stops matching how the business actually operates while still feeling authoritative to anyone reading it.

As the playbook matures, treat it as a living record of your team's own expertise rather than a one-time setup task. New situations will come up that the playbook does not yet cover — a new competitor, a new kind of objection, a new product line — and each one is worth adding once your team has actually handled it well a few times, rather than guessing in advance at what might eventually happen.

Every agent in Cypher LM answers from knowledge files you upload — PDFs, DOCX, CSV, or TXT files containing product catalogues, price lists, FAQs, and policies, up to ten files per agent at four megabytes each. As a team grows, those files stop being one person's personal documents and become a shared library that several agents, and several teammates across departments, rely on at the same time. Treating that library deliberately avoids the common failure mode of a growing team: three slightly different versions of a price list sitting across three different agents, each one a little out of date compared to the others.

Start by auditing what is currently uploaded under each agent's knowledge files in the Agents section. Look specifically for duplicates, outdated versions, and gaps — questions customers actually ask on calls, visible in transcripts and in Cypher N's recaps, that none of the currently uploaded files actually answer. Replace outdated files outright rather than leaving an old version sitting alongside a new one, since an agent drawing from two contradictory price lists, even unintentionally, will give inconsistent answers to very similar questions asked just hours apart.

Cypher M's Library, found under Copilot, works alongside the knowledge files as a second kind of shared knowledge: a record of accepted suggestions from past live calls. Where knowledge files capture what the business formally publishes, the library captures what has actually worked in real conversation and been kept by the team. Over time this becomes a second reference teammates can lean on, particularly for situations that are hard to capture in a static document — how to handle a specific kind of objection, or exactly how a strong past rep, say someone like Maria Lopez on a sales team, phrased a tricky explanation that worked.

Assign one person as the owner of the knowledge library, the same way you assigned an owner to the playbook. Their job is to review what gets uploaded, retire stale files promptly when the business changes a policy or a price, and make sure new agents being built are pointed at the same shared, current files rather than a fresh and incomplete set assembled from scratch. If Google Drive integration is connected under Settings > Integrations, importing from a shared drive folder is a reliable way to keep the two in sync, since an update to the source document in Drive flows back into the knowledge base rather than requiring someone to remember a manual re-upload every time something changes.

A good test of whether your knowledge library is actually working, rather than just existing: pick five real questions pulled from recent call transcripts and check whether the agent's current knowledge files would answer each one correctly today, right now. Gaps found this way — a question the agent clearly struggled with on a real call — are far more useful to act on than guessing in the abstract at what might be missing from the library.

Settings > team & roles is where you decide who can see and change what across the account. As a team grows past two or three people, this stops being optional — without defined roles, anyone with access can edit an agent's behavior, change a payment setting, or remove a knowledge file, often without the rest of the team noticing anything was different until a call goes wrong in a way nobody can explain.

Set roles around what someone's job actually requires rather than granting broad access by default because it feels simpler in the moment. A support rep generally needs Calls, Contacts, and Notes; a sales rep benefits from Copilot access for live coaching during calls; a manager or admin needs Agents, Analytics, Automations, and Settings to actually run the account day to day. Review roles whenever someone's job changes, not just when they first join the team — permission drift, where someone quietly accumulates access they no longer need, is just as common as knowledge drift and just as easy to miss.

Keeping agents consistent as the team scales

The biggest risk in a growing rollout is quiet inconsistency: a second or third agent gets built by a different teammate, with a slightly different tone, a different fallback behavior, or knowledge files that do not quite match the first agent's. Before building a new agent, have whoever is building it review an existing one in the Agents section first — its identity, its tone, its behaviour and restrictions, and its knowledge files — so the new agent starts from the same baseline instead of being assembled from scratch by someone making their own judgment calls.

Where the business runs more than one agent doing similar work, periodically compare their generated system prompts side by side under Agents and check that tone, escalation rules, and fallback behavior still line up with each other. Small drift compounds quietly over time — an agent that was tweaked once, months ago, to handle a specific edge case can end up noticeably different in voice and behavior from its siblings a year later if nobody ever sits down and checks.

With roles, a shared playbook, and a shared knowledge library all in place, a growing team can onboard new hires quickly and keep every agent sounding like the same business, even as more people are involved in building and running them. From here, the sales-marketing and customer-success-teams paths in the Learning Hub go deeper into how specific teams put these agents to work day to day, and the administrators path covers plans, security, and integrations in more depth for whoever holds the account owner role.