4 Tools

Decision Tools

Log, track, and learn from decisions. Build precedent libraries, trace decision lineage, and improve outcomes over time.

Decision Intelligence Workflow

Recommended workflow for tracking decisions

Search Precedents

Use find_precedent to check for similar past decisions

Recall Context

Use recall to gather relevant memories

Log Decision

Use log_decision with memoriesConsidered

Update Outcome

Use update_decision_outcome when result is known

Quick Navigation

log_decision find_precedent get_decision_context update_decision_outcome

log_decision

Log a decision with full context for Decision Intelligence

When to Use

You make a significant decision on behalf of the user
A policy or rule is applied (or an exception granted)
A choice is made that could inform future similar decisions
You want to create an audit trail of reasoning

Parameters

Name	Type	Required	Description
action	string	Required	Decision action identifier in snake_case (e.g., approved_discount, denied_refund)
context	string	Required	Full context of the decision situation (10-2000 chars)
rationale	string	Required	Reasoning behind this decision - explain WHY (10-1000 chars)
memoriesConsidered	array	Optional	Memory IDs that informed this decision (from recall results)
query	string	Optional	Original user query that triggered this decision
alternativesConsidered	array	Optional	Other options that were considered but not chosen
isException	boolean	Optional	True if this deviates from standard policy
exceptionType	string	Optional	Type of exception (required if isException=true)
setsPrecedent	boolean	Optional	True if this should guide future similar decisions
policyApplied	string	Optional	Policy or rule identifier that was applied
confidence	number	Optional	Confidence level 0.0-1.0 (default: 0.8)
outcome	string	Optional	Current status: pending, successful, failed, unknown
outcomeNotes	string	Optional	Notes about the decision outcome (max 2000 chars). For pending decisions, use update_decision_outcome later.
domain	string	Optional	Life domain: work, finance, projects, goals, etc.
importance	number	Optional	Importance 1-10 (default: 7 for decisions)
supersedesDecisionId	string	Optional	Memory ID of decision this replaces
revisitAfter	string	Optional	ISO date when to revisit this decision
revisitReason	string	Optional	Why this decision needs revisiting
participants	array	Optional	Who was involved (e.g., ["@alice", "engineering-team"])
approvedBy	string	Optional	Who approved this decision
userId	string	Optional	User identifier

Example Usage

{
  "action": "approved_20pct_discount",
  "context": "Customer requested discount on annual subscription. They've been a customer for 3 years with no support issues. Revenue at risk: $2,400/year.",
  "rationale": "Long-term customer loyalty justifies retention discount within guidelines. Customer lifetime value significantly exceeds discount cost.",
  "memoriesConsidered": ["mem_abc123", "mem_def456"],
  "policyApplied": "retention_discount_policy",
  "setsPrecedent": true,
  "confidence": 0.9,
  "outcome": "pending"
}

Example Response

Decision logged: approved_20pct_discount [precedent, policy: retention_discount_policy]
ID: mem_1735638400000_xyz789
Links: informed_by:mem_abc123, informed_by:mem_def456

Tips & Best Practices

Use recall first to get memory IDs for memoriesConsidered
The returned ID can be used with update_decision_outcome later
Set setsPrecedent=true for decisions that should guide future choices
Auto-creates INFORMED_BY links to memoriesConsidered
Use supersedesDecisionId when reversing or updating a past decision

find_precedent

Search for similar past decisions that can inform the current situation

When to Use

Making a decision that might have been made before
Looking for how exceptions were handled in the past
Wanting to ensure consistency with past decisions
Needing justification for a policy exception

Parameters

Name	Type	Required	Description
situation	string	Required	Describe the current situation you need precedent for (10-2000 chars)
outcomeWanted	string	Optional	Filter by outcome: successful, failed, or any (default: any)
includeExceptions	boolean	Optional	Include policy exceptions in results (default: true)
domain	string	Optional	Filter by life domain
includeChain	boolean	Optional	Include chain of related memories (default: false)
topK	number	Optional	Number of precedents to return (default: 5, max: 20)
userId	string	Optional	User identifier

Example Usage

{
  "situation": "Customer requesting refund after 60 days. They claim they never received the product, but tracking shows delivered.",
  "outcomeWanted": "successful",
  "includeExceptions": true,
  "topK": 5
}

Example Response

Found 3 relevant precedents:

### 1. approved_partial_refund
Similarity: 87%
Flags: Precedent | Successful

**Context:** Customer claimed non-delivery after 45 days. Investigation showed package left at door...
**Rationale:** Partial refund appropriate when delivery confirmed but customer experience poor
**Policy:** refund_policy_v2

ID: mem_abc123
---

### 2. denied_refund_late_claim
Similarity: 72%
Flags: Precedent | Successful

**Context:** Refund request 90 days post-delivery with confirmed signature...
**Rationale:** Beyond policy window with verified delivery

ID: mem_def456
---

Tips & Best Practices

Use the returned memory IDs in log_decision.memoriesConsidered to cite precedents
Filter by outcomeWanted='successful' to find decisions that worked well
Use get_decision_context on any result for deeper analysis
Novel situations may have no precedents - consider setting a precedent

get_decision_context

Get the full context of a past decision including lineage

When to Use

You found a relevant precedent and want more detail
Reviewing why a past decision was made
Understanding the chain of events around a decision
Auditing decision-making patterns

Parameters

Name	Type	Required	Description
decisionId	string	Required	Memory ID (mem_* format) of the decision to analyze
includeChain	boolean	Optional	Include full chain of related memories (default: true)
includeReplay	boolean	Optional	Show what was known at decision time (default: false)
userId	string	Optional	User identifier for replay context

Example Usage

{
  "decisionId": "mem_abc123def456",
  "includeChain": true,
  "includeReplay": true
}

Example Response

# Decision Context: approved_20pct_discount

## Decision Details
**ID:** mem_abc123def456
**Action:** approved_20pct_discount
**Outcome:** successful
**Domain:** work
**Importance:** 8/10
**Created:** 2024-12-30
**Flags:** Sets Precedent | Policy: retention_discount_policy

## Context
Customer requested discount on annual subscription. They've been a customer for 3 years...

## Informed By
This decision was informed by 2 memories:

- **INFORMED_BY:** Customer has been loyal since 2021...
  ID: mem_customer_history
- **INFORMED_BY:** Previous discount approved for similar case...
  ID: mem_prior_discount

## Led To
This decision led to 1 subsequent memory:

- **RESULTED_IN:** Customer renewed subscription at discounted rate...
  ID: mem_renewal_confirmed

## Related Entities
@customer_12345, retention-team, annual-subscription

## Timeline
- 12/30/2024: [INFORMED_BY] Customer loyalty history reviewed...
- 12/30/2024: [DECISION] Approved 20% discount...
- 12/31/2024: [RESULTED_IN] Customer accepted and renewed...

Tips & Best Practices

Get decisionId from find_precedent or recall with decisionsOnly=true
Timeline shows the chronological flow of related events
Use includeReplay to understand what was known at decision time
Related entities help identify patterns across decisions

update_decision_outcome

Update the outcome of a previously logged decision

When to Use

A decision's outcome becomes known (pending -> successful/failed)
You need to record what happened after a decision was made
Tracking decision effectiveness for future improvement

Parameters

Name	Type	Required	Description
decisionId	string	Required	Memory ID (mem_* format) of the decision to update
outcome	string	Required	New status: pending, successful, failed, or unknown
outcomeNotes	string	Optional	Notes about what happened (max 2000 chars)
outcomeMetrics	object	Optional	Quantitative metrics (e.g., { "revenue_retained": 2400 })
userId	string	Optional	User identifier

Example Usage

{
  "decisionId": "mem_abc123def456",
  "outcome": "successful",
  "outcomeNotes": "Customer accepted the 20% discount and renewed their annual subscription. They also referred two new customers.",
  "outcomeMetrics": {
    "revenue_retained": 2400,
    "customer_ltv_years": 4,
    "referrals_generated": 2
  }
}

Example Response

Decision outcome updated: successful
ID: mem_abc123def456
Notes: Customer accepted the 20% discount and renewed their annual subscription...
Metrics: {"revenue_retained":2400,"customer_ltv_years":4,"referrals_generated":2}

Tips & Best Practices

ALWAYS include outcomeNotes explaining what happened
Outcome metrics help build quantitative precedent data
Future agents can filter by successful/failed outcomes
This closes the feedback loop for decision learning

Task Tools Back to MCP Overview