• A company account where a sales agent logs call intel, a CS agent tracks health signals, a product agent monitors usage, and a human manager reviews the combined picture
• A deal where an SDR qualifies, an AE strategizes, an SE evaluates technical fit — each picking up where the last left off with zero context loss
• A support ticket where a bot triages, an agent investigates, an engineer escalates, and a manager tracks resolution — all on the same record
• A student where an enrollment advisor, academic coach, career counselor, and AI tutor all contribute to the same developmental picture

"I can help you set up a shared workspace on any entity — so agents, humans, and systems can collaborate on the same record. What entity do you want to collaborate on, and who are the contributors?"

• Need to store entity data (not coordination state) → use entity-memory
• Need to manage organizational rules/policies → use governance
• Need to build a data sync pipeline → use entity-memory (CRM sync section) or no-code-pipelines

client.memory.memorize()

memory_store_pro

client.memory.memorizeBatch()

client.memory.smartDigest()

memory_recall_pro

client.memory.smartRecall()

memory_recall_pro

client.memory.recall()

memory_recall_pro

client.memory.search()

client.ai.smartGuidelines()

ai_smart_guidelines

client.ai.prompt()

client.collections.create/list/update/delete()

Important: Use

smartRecall()

(not

recall()

) for workspace reads that need

limit

,

fast_mode

, or

include_property_values

. The simpler

recall()

only accepts

query

,

email

,

record_id

,

website_url

, and

filters

. See

reference/api-examples.md

for raw REST equivalents.

Guiding AI agents via MCP? Read

reference/agent-prompts.md

for complete system prompt templates, MCP tool call examples, role-specific prompts (sales intel, CS health, product analytics, human-in-the-loop), and multi-agent coordination patterns.

reference/architecture.md

GUIDELINES    →  "What are the rules?"             →  ai_smart_guidelines
MEMORY        →  "What do I know about this entity?" →  recall / smartDigest
WORKSPACE     →  "What's been done & what's next?"  →  recall by tag / memorize

Using workspaces in workflows (n8n, Trigger.dev, cron)? Agents in workflows don't have access to Skills — they only have MCP tools. Upload the workspace protocol as a governance variable so any agent gets it via

ai_smart_guidelines

. Read

reference/governance-setup.md

for the guideline template, upload instructions, and workflow prompt injection snippets.

Using the GTM Workflows Builder skill? The

recipes/trigger-dev-bridge.ts

recipe shows how a Trigger.dev pipeline can analyze a CRM lead and write findings back to the contact's workspace — bridging the GTM and Shared Workspace skills.

• Roles? The

  author

  field on every entry tells you who contributed. No registry needed.
• Handoffs? A task assigned to someone with context IS a handoff. The workspace history IS the context transfer.
• Conflict resolution? Two contributors say different things? That's two data points. The consumer reads both and decides.
• Permissions? Governance via

  smartGuidelines()

  tells each agent what they can and can't do. The organizational guidelines are the access control.
• Escalation? An issue with severity

  critical

  IS an escalation. Whoever monitors the workspace acts on it.

1. Ask: What entity? (contact, company, deal, project, ticket, custom?) What contributors? (which agents, which humans, which systems?)
2. Design: Start from the 5-property starter. Adjust property names, descriptions, and entry schemas to match their domain language.
3. Output: Complete workspace schema ready to create in the Personize web app or via

   client.collections.create()

   .
4. Verify: After creation, confirm with

   client.collections.list()

   and test with a sample contribution.

Full guide: Read

reference/create.md

for the complete design workflow, property specifications, entry schemas, domain-specific naming examples, and verification steps.

pending

Full guide: Read

reference/use.md

for all contribution patterns, entry formats, consumption patterns, tagging conventions, agent loop examples, and human contribution flows.

Full guide: Read

reference/grow.md

for complete property definitions, entry schemas, when-to-add guidance, and examples of workspaces at different maturity stages.

1. Query: Use

   recall()

   and

   export()

   to pull workspace entries across entities.
2. Analyze: Check for health signals above.
3. Report: Summarize findings — what's working, what's stale, what needs attention.
4. Recommend: Suggest fixes — new contributors, governance updates, property additions, workflow changes.

Full guide: Read

reference/review.md

for the complete audit checklist, query patterns, health scoring, and improvement recommendations.

• Sales agent (runs after every call): Adds notes from call transcripts, updates tasks with next steps, flags issues when a champion goes dark
• Product agent (runs daily): Adds updates on feature usage trends, raises issues when adoption drops, creates tasks when an expansion signal appears
• CS agent (runs weekly): Rewrites the context with a holistic health summary, creates tasks for QBR prep, adds notes on risk factors

smartDigest()

• Note: "Spoke with VP Eng. Evaluating because current vendor can't handle scale. Technical decision, not budget."
• Task: Assigned to AE — "Schedule deep-dive. Key angle: scale story. Bring SE for architecture discussion."
• Update: "Qualified. Moving to AE."

• Support agent detects 3 tickets in 2 weeks → raises an issue (severity: high, "recurring support volume")
• Product agent detects login frequency dropped 40% → adds a note (category: observation)
• CS agent reads both, rewrites the context ("At-risk: support volume up, engagement down, renewal in 60 days"), creates a task for the CSM with a recommended action plan

• Engineering agent: Updates on build progress, issues on technical blockers, tasks for code review
• Design agent: Notes on design decisions, updates on asset delivery, issues on scope creep
• PM agent: Rewrites context with overall status, creates tasks for stakeholder updates, flags issues when timelines slip

Keywords follow RFC 2119: MUST = non-negotiable, SHOULD = strong default (override with stated reasoning), MAY = agent discretion.

1. SHOULD start with the 5-property starter schema (Context, Updates, Tasks, Notes, Issues) -- because premature schema complexity kills adoption; expand only when the existing properties force workarounds.
2. MUST include an

   author

   field or

   source:agent-name

   tag on every workspace entry -- because without attribution, consumers cannot evaluate the reliability or recency of contributions.
3. MUST NOT overwrite or delete existing Updates or Notes entries -- because append-only history provides the timeline that makes collaboration legible; if something changes, add a new entry.
4. MUST use the

   status

   field on Tasks and Issues to track state transitions (pending → done, open → resolved) -- because statusless mutable entries create ambiguity about whether work is complete.
5. MUST use

   replace

   semantics for the Context property -- because Context is the current summary, not a log; appending creates unbounded growth that breaks

   smartDigest

   token budgets.
6. MUST use the standard workspace tags (

   workspace:tasks

   ,

   workspace:updates

   ,

   workspace:notes

   ,

   workspace:issues

   ) and add

   source:agent-name

   for attribution -- because tag-based recall is the primary workspace query mechanism; non-standard tags create invisible entries.
7. MUST call

   smartDigest()

   before contributing to a workspace -- because acting without reading the current state leads to duplicate work, contradictions, and stale decisions.
8. SHOULD memorize generated outputs and actions taken as workspace updates -- because the feedback loop prevents duplicate work and gives other contributors visibility into what happened.
9. SHOULD call

   smartGuidelines()

   before generating or deciding -- because governance constraints define what the agent is permitted to do; skipping it risks policy violations.
10. MAY attach a workspace to any entity with an identity (contacts, companies, deals, projects, tickets, patients, etc.) -- because the schema is entity-agnostic by design.

workspaceUpdates: true

• On SEND —

  workspace:updates

  entry: "Notification sent: <subject>"
• On DEFER —

  workspace:tasks

  entry: "Review deferred notification for <entity>"

WorkspaceUtils

signal.workspace.addTask(email, { title, priority, assignee })

memorize({ content: JSON.stringify(task), tags: ['workspace:tasks', 'source:signal'] })

workspace:tasks

signal.workspace.addNote(email, { content, tags })

memorize({ content, tags: ['workspace:notes', 'source:signal'] })

workspace:notes

signal.workspace.addUpdate(email, update)

memorize({ content: update, tags: ['workspace:updates', 'source:signal'] })

workspace:updates

signal.workspace.addIssue(email, { title, severity })

memorize({ content: JSON.stringify(issue), tags: ['workspace:issues', 'source:signal'] })

workspace:issues

signal.workspace.getDigest(email)

smartDigest({ email, include_properties: true, include_memories: true })