Groups

A group is a container of topics and a pipeline definition — a bundle of configuration that maps 1:1 to a use case. If you have multiple use cases (e.g. personalization and continual learning), create separate groups for each.

Each project can have multiple named groups, but most use cases only need the default group.

• A stable UUID identifier for the pipeline configuration
• Topic definitions that control what gets extracted
• Pipeline steps that define the processing flow
• Topic name isolation — different groups can have topics with the same name without collision (e.g. two agents can each have a user_preferences topic in separate groups)

When you create a project, Engram provisions a group named default. All API requests use this group unless you specify another with the group parameter. Project templates may seed the default group with a starter set of topics — the Personalization template, for example, seeds it with a UserKnowledge topic.

Create additional groups when you have distinct use cases that need different topic definitions or pipeline configurations. For example, a customer support agent might have one group for tracking user preferences and another for learning resolution patterns.

A customer support agent could use two groups:

• personalization — Its topics are user-scoped, storing per-user facts like "prefers email over phone" or "has a Pro subscription". A user_id is required when adding to these topics so each user's memories stay separate.
• continual_learning — Its topics are project-wide, storing knowledge the agent learns about how to do its job, like "always check the billing FAQ before escalating refund requests". No user_id needed, so these memories are shared across all users.

Scoping is configured per topic, not per group, so a single group can mix user-scoped and project-wide topics.

When the agent handles a support ticket, it searches the personalization group with the user's ID to recall their history, and searches the continual learning group to recall best practices.

A multi-product company might create a separate group per product:

• product_a_support — Topics and pipeline tuned for Product A (e.g. topics like "known_issues", "feature_requests")
• product_b_support — Different topics for Product B, possibly with a different pipeline configuration

This keeps topic names isolated — both groups can have a "known_issues" topic without collision — and lets each product team configure extraction independently.

Have a question or feedback? Here's how to reach us.