Why Your Data Model Matters for AI
Both AI Copilot and the Vitally MCP server work by handing an LLM your Vitally data model, not just your data. Custom Object descriptions get compiled directly into the tool definitions the LLM sees when it creates or updates records. Trait descriptions are passed alongside every trait in update tool calls. Memories get injected into the system prompt on every Copilot session.
If those fields are blank, generic, or stale, you're not just missing internal documentation. You're making the AI guess. The reverse is also true: a well-described data model measurably improves accuracy and cuts token usage, because the LLM spends less time guessing what a field means before it acts on it.
This guide is ranked by impact. Start at the top.
1. Write Descriptions for Every Trait the AI Might Touch
Trait descriptions are the single most load-bearing field in the whole system. They're exposed directly in MCP tool schemas, and Vitally's AI Actions bundle all of an object's traits and their descriptions into each tool call so the LLM can pick the right field to retrieve or act on (capped at roughly 100 traits per call). A trait with no description is a coin flip for the model.
What to include in a trait description:
What it tracks and why it exists.
If it's an enum/dropdown, what each value means in your business's terms. The model can't infer that "Yellow" means "at risk of missing renewal" unless you say so.
Who or what sets it and when (a human during a review, an integration, a formula). This tells the AI whether it's safe to suggest an update.
How often it should change, if there's a cadence (e.g., "Pulse" traits meant to be updated after every meaningful touchpoint).
This applies most to Account/Org Traits, User Traits, and Custom Object traits, since those are the ones AI Actions read and write most often.
2. Write Real Descriptions for Every Custom Object
When you have a Custom Object (Product Requests, Risks, Opportunities, etc.), Vitally generates an AI tool for it automatically (e.g., a "create product request" tool) and the object's description becomes part of that tool's definition. These aren't just used for creating records. They're also used for finding or retrieving records for a relevant prompt. A missing description means the LLM is guessing at intent every time.
What to include:
What real-world thing this object represents, in one sentence ("A specific feature or capability a customer has asked for").
How the AI should fill out the body when a new instance is created (e.g., ignore the status field, that gets set manually).
How it differs from adjacent objects if the distinction is easy to miss (e.g., Risk vs. Escalation vs. Churn Reason).
Who typically owns or reviews these records, if that affects how the AI should draft or route them.
Avoid restating the object's name as the description ("Product Requests: requests from products"). That adds zero information for the model.
3. Use AI Memories for Stable, Recurring Context
Memories let Vitally AI pull the same context into every generation automatically, so you stop re-explaining your terminology, business model, and tone preferences in every prompt. Used well, they increase quality and personalization across the board: summaries, drafts, and answers all start from the same accurate baseline whether you're the one asking or a teammate is.
Two scopes:
Global Memories apply to every AI generation for everyone on the team. Only Admins and Leaders can create or edit these, which serves as a built-in review gate.
Account-level Memories apply only to that Account/Org. Any non-observer user (Admins, Leaders, and Team Members) can add these for accounts they have access to.
Memories are visible from the memory icon in the Copilot panel on any Account/Org. Check what's already there before adding a duplicate, and review periodically as your business or that account evolves.
What belongs in a Memory
Custom terminology: if you call Accounts "Buildings" or Orgs "Districts," say so once, globally.
Business model and product context: your tiers, who you sell to, how pricing/seats work.
Output format and tone preferences: how you want risk framed, what phrases to avoid, what tone customer-facing drafts should use.
Account-specific situational context: where a customer is in their renewal cycle, a recent stakeholder change, anything that should color how the AI treats that account specifically.
What doesn't belong in a Memory
The one mistake worth avoiding: don't use a Global Memory as a field or object dictionary. A Global Memory gets injected into every AI generation across your whole workspace, so loading it with individual trait or custom field definitions adds irrelevant context to generations where it doesn't apply, which can dilute or bias unrelated outputs. If the question is "what does this specific trait or field mean," that belongs on the field's own description (see sections 1 and 2 above). Reserve Memories for context that's genuinely true everywhere, or genuinely specific to one account.
More generally, a Memory should read like an instruction or a fact, not a source document. Concrete things to avoid:
Pasting an entire help doc, wiki page, or PRD into a Memory. Memories aren't a knowledge base. Every word gets loaded into every generation whether it's relevant or not, so a multi-page document turns into wasted context on every single Copilot interaction.
Dumping raw data like a CSV export, a full list of account names, or a table of numbers copied from a report. If it's structured data, it almost certainly already lives in Vitally as a trait, object, or integration and the AI can retrieve it directly. A stale copy in a Memory just creates a second, unmaintained source of truth.
Anything that changes often. Current pipeline totals, this week's headcount, whoever happens to be on-call. Memories are meant for things that stay true for months. Volatile information goes stale fast and the AI has no way to know it's outdated.
Near-duplicate Memories that say almost the same thing slightly differently. Conflicting or overlapping Memories don't average out. They confuse the model about which version to trust, which is worse than having no Memory at all.
As a rule of thumb: if what you're about to paste is longer than a paragraph or two, it's probably a document, not a Memory. Put it somewhere the AI can look it up on demand (a Doc, a description field, a linked resource) rather than force-feeding it into every generation.
4. Structure Your Prompts
The Copilot input field supports headers, bulleted/numbered lists, and bold/italic, and this isn't cosmetic. Structured prompts are how Copilot reliably parses multi-part requests, and it's exactly the pattern in Vitally's own Prompt Library for anything with more than one deliverable (e.g., "chain together: draft a follow-up, create tasks, log any product requests as their own step"). If you want three separate outputs, ask for three separate, labeled things rather than one run-on sentence, and save the ones that work well as Saved Prompts so the phrasing doesn't get reinvented each time.
5. Keep Your Data Model Lean
Every trait you add to an object is either a wasted line in an AI tool call or a useful one. There's no neutral. Vitally caps traits passed into "Update Object" tool calls at roughly 100, and every additional trait fills the context window faster in both Copilot and MCP sessions. Before adding a new trait, ask whether an existing one already covers it. Archive or consolidate traits that are duplicative, unused, or left over from a migration. This is one of the few levers you have that improves accuracy while also lowering token cost.
If you want to keep certain traits around but don't want the LLM to use them, add something like this to the description to steer the LLM away:
DEPRECATED: [reason for deprecation]
6. Match the Tool to the Task
Copilot and MCP aren't interchangeable. Getting this pairing right matters more than any single setting.
Use native AI Copilot for day-to-day account work: summaries, next steps, churn risk, drafting follow-ups. It already has your business context loaded via system prompt and automatically scopes itself to the record you're on, so it's faster and cheaper per question.
Use the MCP server when you need to connect Vitally data to something outside Vitally: building a QBR deck in Google Slides from usage data, chaining Vitally data into another tool's own MCP, or scripting bulk operations. MCP is built for orchestration across systems. Copilot is built for the individual contributor's daily workflow.
Pointing a multi-step, cross-system workflow at Copilot (or a simple "what's this account's sentiment" question at MCP) wastes the strengths of both.
7. Manage the Context Window Deliberately
Both Copilot and MCP sessions have a limited context window that fills as the model pulls in traits, records, and citations to answer you. It fills based on how much data each answer requires, not on how many questions you've asked. Aggregate, multi-part, or vague questions ("how's this account doing?") fill it fastest and are also the ones most likely to produce a mediocre answer.
Ask specific, single-part questions, and start a New Chat once you've gotten what you need from a thread rather than continuing to stack unrelated questions into the same session.
A quick feel for the difference:
Instead of... | Try... |
"How's this account doing?" | "Have we heard complaints or frustration from stakeholders in the last 90 days?" |
"What does this customer want?" | "What are the customer's top 3 product requests based on logged Product Request objects?" |
"Are issues being resolved promptly?" | "Give me a churn-risk summary with a save plan, owners, and timelines." |
The pattern in each case is the same: name the object, the timeframe, and the shape of the answer you want.
Copilot can only reason about what's tracked inside Vitally. Questions about product usage or support tickets that live in another system and haven't been synced in will come back empty or guessed. That's a data gap, not a prompting problem.
8. Extend Descriptions to Segments, Playbooks, and Health Scores
Descriptions aren't just a Traits-and-Custom-Objects thing. Segments, Playbooks, and Health Score components support them too, and anywhere a description exists, it's another thing the AI can retrieve and reason with precisely instead of guessing from a name alone.
A Segment described as "Accounts with 3+ open Risks and no executive sponsor" gives the AI something concrete to match against. A Segment named only "At Risk – Tier 2" doesn't. Treat every description field Vitally gives you as an opportunity to make retrieval more precise, not just as internal documentation.
9. Add Prompts to Conversation and Note Templates
If you use Draft a Follow Up or AI-assisted Note creation, the template you select is used as a reference the LLM works from, not purely copy to fill in. That means you can inject prompt-like instructions directly into a template: ask it to summarize topics discussed, pull out key takeaways, or list action items by owner. When the template is selected, the AI follows those instructions when generating the draft.
A template written this way (e.g., "Subject: Follow-up from {Meeting Name}... Instructions: Summarize topics discussed, list key takeaways, list action items for each side") tends to produce a more useful result than a template that's just a fixed structure with merge fields. This isn't all-or-nothing. Even adding one or two instructional lines at the top of an existing template is worth trying.
10. Govern Memories Like Documentation
Global Memories affect every AI interaction company-wide, so treat additions the way you'd treat a change to a shared runbook: one person shouldn't unilaterally redefine "at risk" for the whole team. Since only Admins and Leaders can create or edit Global Memories, use that as a natural review gate, and reserve Account-level Memories (open to Admins, Leaders, and Team Members) for context that's genuinely account-specific.
Periodically review the Global list for contradictions or duplication as your definitions evolve. Conflicting memories can confuse the model, and nothing currently flags that for you automatically.
Data Security
Vitally AI runs on AWS Bedrock. Your data is not used to train any model. Model providers (Anthropic, Cohere, etc.) never see your prompts or completions directly, and AI-processed data follows the same retention and deletion policies as everything else in Vitally.