Team Decisions

Searchable institutional memory that persists across all team members' AI sessions. Never re-debate a settled decision again.

The "Didn't We Already Decide This?" Problem

Three engineers debate in Slack. Someone summarizes in Confluence. Six months later, a new engineer asks "why did we choose Kafka?" Nobody can find the page. The debate restarts. Team Decisions fixes this — decisions are recorded once, searchable forever, and auto-surfaced when AI agents work on related stories.

Record & Search Team Decisions

How It Works

Record

When your team makes a decision — in a meeting, a PR review, a pairing session — record it with context and rationale. Takes 10 seconds via your AI agent.

Search

Full-text search across all decisions. Before a meeting, before a debate — search first. PostgreSQL-powered relevance ranking finds what you need.

Auto-Surface

When an AI agent calls prepare_implementation, relevant decisions are automatically included in the context. No manual lookup needed.

MCP Tools

All three tools are available in any MCP-compatible AI agent (Claude Code, Cursor, VS Code, etc.) when connected to your Elixium workspace.

`record_decision`

Record a team decision, meeting outcome, or architectural choice. Shared across all team members' AI sessions.

// In your AI agent chat

record a team decision:
  "All new API endpoints must use pagination
   with a default limit of 25 and max of 100"
  category: architecture
  tags: api, standards

Parameters

title	string	Required. Short title for the decision.
content	string	Required. Full description with context and rationale.
category	string	Optional. One of: architecture, meeting-note, convention, tooling, decision, general.
tags	string[]	Optional. Tags for filtering, e.g. ["auth", "self-hosted"].
storyId	UUID	Optional. Link this decision to a specific story.
epicId	UUID	Optional. Link this decision to an epic.

`search_decisions`

Full-text search across all team decisions. Uses PostgreSQL relevance ranking to find the best matches.

// Search for decisions about databases

search team decisions for "database"

Parameters

query	string	Required. Search keywords.
category	string	Optional. Filter by category.
limit	number	Optional. Max results (default 10, max 50).

`list_decisions`

List recent team decisions with optional filters. Great for reviewing what the team decided this week or in a specific category.

// List all architecture decisions

list team decisions with category "architecture"

Parameters

category	string	Optional. Filter by category.
tag	string	Optional. Filter by tag.
since	ISO date	Optional. Only decisions after this date.
limit	number	Optional. Max results (default 20, max 100).

Decision Categories

architecture

Technical architecture choices — database selection, API design patterns, infrastructure decisions.

convention

Team standards — coding conventions, naming patterns, review processes.

tooling

Tool choices — CI/CD pipelines, monitoring, development environments.

meeting-note

Meeting outcomes — sprint retros, planning sessions, stakeholder decisions.

decision

General decisions that don't fit other categories.

general

Default category when none is specified.

Real-World Examples

architecturedatabasesessions

PostgreSQL over DynamoDB for session storage

We chose PostgreSQL over DynamoDB for session storage because we need strong consistency and our team has deep Postgres expertise. DynamoDB would save ~$200/mo but the operational complexity and eventual consistency model don't fit our auth requirements.

conventionapistandards

API pagination standard

All new API endpoints must use cursor-based pagination with a default limit of 25 and max of 100. Offset pagination is acceptable for admin endpoints only.

meeting-notesprint-retro

Sprint 14 retro: AI test quality

Team agreed that AI-generated tests need at least 2 edge cases per acceptance criterion. We saw 3 bugs in prod this sprint from tests that only covered the happy path.

Superseding Decisions

Teams evolve. When a decision is replaced by a newer one, mark the original as superseded. The old decision stays in the record (for context) but won't be surfaced duringprepare_implementation.

Example: In January you decided "use REST for all APIs." In March, after evaluating performance, you decide "use gRPC for internal service-to-service calls." The new decision supersedes the old one — but the old one remains searchable so future team members understand the evolution.

Enabling Team Decisions

Team Decisions is controlled by a feature flag and can be enabled at the board or workspace level.

// Board Settings → Features

enableTeamDecisions: true

The feature uses a 3-level cascade: board settings override workspace settings, which override smart defaults. On paid plans, Team Decisions is enabled by default.

Best Practices

DOInclude the why, not just the what. "We chose X because Y" is infinitely more useful than "Use X."
DORecord decisions immediately — in the meeting, in the PR review, in the pairing session. Context fades fast.
DOUse specific tags. auth, payments, ci-cd are better than important.
DOLink decisions to stories or epics when relevant. This creates a decision trail attached to the work.
DON'TRecord implementation details — those belong in code comments or ADRs. Decisions are about the choice, not the how.
DON'TDelete old decisions. Supersede them instead. The history of why things changed is as valuable as the current state.

Need help? Contact [email protected]