Org Profile

Org Profile gives TeamLoop standing context — things the system always knows about your organization without rediscovering them on every query. As DECISION entities accumulate, TeamLoop infers patterns like “prefers PostgreSQL for data stores” or “avoids self-hosted infrastructure” and surfaces them automatically in query results.

Why Org Profile?

Without Org Profile	With Org Profile
”What tech should we use for the payments API?” returns matching decisions	Same decisions returned, plus standing context: “org prefers managed services, uses Auth0 for identity, requires gRPC for inter-service communication”
You re-state preferences every time you ask	Preferences are remembered and surfaced automatically
New team members don’t know unwritten rules	Inferred traits capture implicit patterns from past decisions

How It Works

Trait sources

Org traits come from two sources:

1. Declared — Explicitly stated by a user via the API or MCP tool. These have confidence: high automatically.
2. Inferred — Detected by analyzing patterns across DECISION entities using an LLM. Each inferred trait includes a confidence level and the IDs of supporting decisions for provenance.

Trait properties

Each org trait includes:

• Name — A concise statement (e.g., “Prefer TypeScript over JavaScript”)
• Category — preference, standard, constraint, or deprecation
• Confidence — high, medium, or low
• Source — declared or inferred
• Supporting decision IDs — For inferred traits, the UUIDs of decisions that support this trait
• Status — active or archived

Inference triggers

Trait inference runs in two ways:

1. Threshold-based — Automatically triggered when the number of DECISION entities reaches 5, 10, 20, or 50. This happens asynchronously and never blocks the save flow.
2. On-demand — Manually triggered via the MCP tool (action: "infer") or REST API (POST /v1/org/profile/infer).

The inference prompt includes decision UUIDs so the LLM can reference which decisions support each trait. These are mapped back to entity IDs and stored as supporting_decision_ids for provenance.

Integration with context reconstruction

Org traits are gathered as a signal during context reconstruction. When you query with reconstruct: true (the default), relevant org traits appear in the ## Context section of the response:

## Context

### Org Profile
- **Prefer PostgreSQL for data stores** [high] (inferred)
- **All services must use gRPC for inter-service communication** [high] (declared)
- **Avoid self-hosted infrastructure** [medium] (inferred)

In the dashboard, org traits appear in the context_data.org_traits array of the query response.

MCP Tool

teamloop_org_profile

Manage organizational traits: list, add, remove, or infer from decisions.

Parameters:

Parameter	Type	Required	Description
action	string	Yes	list, add, remove, or infer
trait	string	For add/remove	The trait text (e.g., “Prefer TypeScript over JavaScript”)
category	string	For add	One of: preference, standard, constraint, deprecation (default: preference)

List all active traits:

Tool: teamloop_org_profile
Input: {
  "action": "list"
}

Example output:

## Org Profile (4 traits)

### Standard
- **All new services must use gRPC** [high] (declared)
- **Design reviews required for auth changes** [high] (declared)

### Preference
- **Prefer PostgreSQL for data stores** [high] (inferred)
- **Prefer managed services over self-hosted** [medium] (inferred)

Declare a new trait:

Tool: teamloop_org_profile
Input: {
  "action": "add",
  "trait": "All new services must use gRPC for inter-service communication",
  "category": "standard"
}

Remove a trait:

Tool: teamloop_org_profile
Input: {
  "action": "remove",
  "trait": "All new services must use gRPC for inter-service communication"
}

Removing a trait archives it (sets status to archived) rather than deleting it.

Infer traits from decisions:

Tool: teamloop_org_profile
Input: {
  "action": "infer"
}

Requires at least 3 DECISION entities from the last 6 months. Returns a count of newly inferred traits.

REST API

All endpoints require authentication.

List active traits

GET /v1/org/profile

Response:

{
  "traits": [
    {
      "id": "550e8400-e29b-41d4-a716-446655440000",
      "name": "Prefer PostgreSQL for data stores",
      "category": "preference",
      "confidence": "high",
      "source": "inferred"
    },
    {
      "id": "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
      "name": "All new services must use gRPC",
      "category": "standard",
      "confidence": "high",
      "source": "declared"
    }
  ],
  "count": 2
}

Declare a trait

POST /v1/org/profile

Request body:

{
  "trait": "Avoid self-hosted infrastructure",
  "category": "constraint"
}

Response:

{
  "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "name": "Avoid self-hosted infrastructure",
  "category": "constraint",
  "source": "declared"
}

Archive a trait

DELETE /v1/org/profile/:id

Sets the trait status to archived. Archived traits are excluded from listings and context reconstruction.

Response:

{
  "success": true,
  "status": "archived"
}

Infer traits from decisions

POST /v1/org/profile/infer

Analyzes DECISION entities from the last 6 months and generates up to 10 new traits. Existing active traits are deduplicated by name.

Response:

{
  "inferred": 4,
  "total_decisions": 23
}

If fewer than 3 decisions exist:

{
  "inferred": 0,
  "message": "Not enough decisions to infer traits (found 2, need at least 3)"
}

Workflow

Week 1: Building the knowledge base

User: "Remember: We decided to use PostgreSQL for the payments database.
       JSONB support and pgvector were the main drivers."

AI: [uses teamloop_remember]
-> Remembered 1 entity (DECISION).

User: "Remember: We chose Auth0 for identity management across all services."

AI: [uses teamloop_remember]
-> Remembered 1 entity (DECISION).

As more decisions accumulate, TeamLoop builds a richer picture of organizational patterns.

Week 3: First inference trigger

After the 5th decision is saved, TeamLoop automatically infers traits:

• “Prefer managed services over self-hosted” (medium, from 3 decisions)
• “Prefer PostgreSQL for data stores” (high, from 4 decisions)
• “Use Auth0 for all identity/auth” (high, from 3 decisions)

Week 4: Traits surface in queries

User: "What tech should we use for the new notification service?"

AI: [uses teamloop_query with reconstruct: true]
-> Results include matching decisions, plus context:
   "Your org prefers managed services (medium confidence),
    uses Auth0 for identity (high), and prefers PostgreSQL
    for data stores (high)."

Anytime: Declare explicit standards

User: "Add an org standard: all new services must use gRPC
       for inter-service communication."

AI: [uses teamloop_org_profile with action: "add"]
-> Created org trait: "All new services must use gRPC" (standard, declared)

Tips

• Declared traits have high confidence — When you explicitly add a trait, it’s treated as authoritative. Inferred traits may have medium or low confidence depending on how many decisions support them.
• Inference needs 3+ decisions — The LLM needs enough signal to detect patterns. With fewer than 3 decisions from the last 6 months, inference is skipped.
• Traits are deduplicated by name — Running inference multiple times won’t create duplicate traits. Only new patterns are added.
• Remove traits that are wrong — If inference produces an incorrect trait, remove it. Archived traits won’t reappear in future inference runs.
• Supporting decision IDs enable provenance — Each inferred trait records which decisions led to the inference. This helps you understand why a trait was inferred and whether it’s still valid.
• Org profile is per-user — Consistent with TeamLoop’s data model, org traits are scoped to the authenticated user. Multi-user organizations should coordinate trait declarations.

Next Steps

• Context Reconstruction — How org traits surface in query results
• Agent Memory — The teamloop_remember tool that feeds decisions into trait inference
• Knowledge Graphs — Understanding entity types including ORG_TRAIT