How do you make AI agents give consistent decisions across sessions?

Encode decisions as Reusable Decision Units (RDUs) — versioned markdown files with frontmatter (id, domain, version, trigger), a trigger section describing when to apply, a situation section explaining the context, and a judgment section with the committed decision. Store them in a stable location the agent can access at session start. When the trigger condition matches, the rule fires automatically, not from memory.

What is a Reusable Decision Unit (RDU)?

An RDU is a domain-agnostic, versioned rule file that encodes a single committed judgment. It has: (1) a specific trigger — a grep-able token or condition, (2) a situation description — why this judgment was needed, (3) a judgment — the committed decision (no 'it depends'), (4) an action — what to do when triggered, (5) evolution metadata — version, created date, source. It differs from documentation because it fires automatically on trigger, not on reading.

How does RDU differ from just writing prompts or CLAUDE.md rules?

CLAUDE.md rules are global and always-loaded, making them expensive. RDU files are trigger-specific — only the relevant rules fire. Each RDU is versioned (v1, v2...) with explicit evolution conditions, preventing silent drift. RDUs also have explicit falsification conditions: every judgment states under what circumstances it should be superseded.

Can RDUs work across different domains like iOS, trading, and AI?

Yes. The pattern is domain-agnostic. Our 140+ RDU library spans iOS deployment (ASC API limits, fastlane patterns), trading (no LLM probability production, walkforward validation), AI agent design (council patterns, hook architectures), real estate analysis, and game development. The trigger-judgment structure works identically across all domains.

RDU: Reusable Decision Units for Consistent AI Agents

To keep an AI agent behaving consistently across sessions, encode each repeatable decision as a Reusable Decision Unit (RDU) — a versioned markdown file with a grep-able trigger and a committed judgment, stored where the agent loads it at session start, so the rule fires automatically on trigger instead of relying on the model's memory.

A pattern in production use across a 140+ rule library spanning iOS deployment, trading, AI-agent design, game development, and real estate — each rule fires automatically on a grep-able trigger, not from model memory.

← hexisteme · notes · June 13, 2026 · 8 min read

If you use AI agents daily, you've hit this: the agent gives a correct, well-reasoned answer on Monday. On Friday, in a fresh session, it gives a different answer to the same question. Not wrong, just different — shaped by whatever context happened to come up first.

This is drift. And it's not fixable with better prompts or more examples in CLAUDE.md. Those approaches scale poorly and don't version. Here's what does work: Reusable Decision Units (RDUs).

The Problem with "Just Write It Down"

The naive fix is to document decisions. Write a CLAUDE.md or AGENTS.md entry: "When X happens, do Y." Two problems:

Documentation requires reading. Rules buried in a long markdown file compete for attention. They get read once, then drift as the file grows.
No version control on the judgment itself. If you discover a better approach, you overwrite the old rule silently. There's no history of why the judgment changed.

The fix is to treat decisions like code: versioned, trigger-driven, with explicit evolution conditions.

What an RDU Looks Like

Each RDU is a markdown file with YAML frontmatter:

---
id: RDU-047
title: App Store Connect in-flight limits — 1 version / 2+5 reviewSubmissions
status: active
domain: [ios, deploy, app-store-connect]
version: 3
created: 2026-04-28
last_applied: 2026-05-10
sources: ["ASC API docs", "direct curl validation 2026-05-10"]
---

## Trigger
- `app_versions_create` returns 409 STATE_NOT_SUITABLE
- User wants to ship CPP + PPO + new version simultaneously

## Situation
ASC enforces two independent concurrency limits:
- **Version**: only 1 in-flight (PREPARE/WAITING/IN_REVIEW) per platform
- **reviewSubmissions**: max 2 in-flight, max 5 total

READY_FOR_REVIEW orphans can't be deleted via API (403) or canceled (409).
They auto-expire after 7 days or require manual ASC web UI action.

## Judgment
**Check both limits before any submission attempt.**
Bundle CPP + PPO + appEvent into one reviewSubmission to minimize slot consumption.
Never assume a clean slate — always query current state first.

## Action
```bash
# Check in-flight versions
GET /v1/appStoreVersions?filter[appStoreState]=PREPARE_FOR_SUBMISSION,WAITING_FOR_REVIEW,IN_REVIEW

# Check reviewSubmission slots
GET /v1/reviewSubmissions?filter[state]=READY_FOR_REVIEW,WAITING_FOR_REVIEW,IN_REVIEW
```

The key structural elements:

Section	Purpose	Anti-pattern it prevents
`Trigger`	Grep-able condition that fires the rule	Rules that require the agent to "remember" to check
`Situation`	Why this judgment was needed	Rules that become obsolete without anyone noticing
`Judgment`	Committed decision, no hedging	"It depends" answers that push the decision back to the user
`version: N`	Explicit evolution tracking	Silent rewrites that erase why a decision was made
`sources`	Provenance of the judgment	Rules derived from hallucinated "facts"

The Four Core Principles

1. No Absolutes

Every RDU is the best judgment at the time of writing. The meta-rule (RDU-000) states: "절대란 절대로 없다" — there are absolutely no absolutes. Every rule carries implicit evolution conditions: if a better approach is found, propose a version bump or supersession. Never silent-rewrite.

2. Trigger Specificity

A trigger must be a grep-able token, not a vague description. "When working on iOS" is not a trigger. "When app_versions_create returns 409" is. If the trigger can't be matched by a regex, the rule won't fire reliably.

3. Proactive Registration

When the agent notices it's re-deriving a judgment it's made before — or the user signals "this is useful, save it" — the agent should propose an RDU draft immediately, not wait. The pattern: propose → user approves → write file. No silent creation.

4. Domain-Agnostic

The trigger-situation-judgment structure works across all domains. Our library of 140+ RDUs spans:

iOS deployment — ASC API limits, fastlane patterns, Swift 6 concurrency
Trading — no LLM probability production (RDU-021), walkforward validation required (RDU-022)
AI agent design — council orchestration patterns, stop hook architectures
Game development — Godot platformer feel numbers (coyote time 100ms, jump buffer 150ms)
Real estate — LTV computation, loan headroom calculation

How It Works in Practice

At session start, the agent loads ~/.claude/skills/rdu/index.md — a single-line-per-rule index. When a trigger condition appears in the conversation, the agent reads the full RDU file. The index stays short; the full rules only load when relevant.

For evolution: when a newer approach is discovered, the agent proposes a diff:

# RDU evolution example
- version: 2 → version: 3
- Judgment updated: fastlane now works in READY_FOR_SALE state (ASC MCP doesn't)
- History: v2 assumed ASC MCP parity — incorrect for Editable Properties
- Source added: direct fastlane validation 2026-05-10

Key insight: The value isn't in having 140 rules. It's in the trigger mechanism. A rule that fires automatically is worth 10× a rule that requires the agent to remember to check.

What RDUs Don't Solve

RDUs encode repeatable judgments. They don't handle novel situations, value questions (user preferences, risk appetite), or decisions that genuinely depend on runtime context. For those, the agent should ask — but RDUs reduce the surface area of what actually needs asking.

Getting Started

Minimal viable setup: a single directory (~/.claude/skills/rdu/rules/), an index file, and a template. When you catch yourself re-explaining the same judgment twice — or when you fix a bug caused by forgetting a previous decision — that's your signal to write an RDU.

The template we use:

---
id: RDU-XXX
title: [one-line description]
status: active
domain: [list of domains]
version: 1
created: YYYY-MM-DD
last_applied: YYYY-MM-DD
sources: ["where did this judgment come from"]
---

## Trigger
[Specific, grep-able condition]

## Situation
[Why was this judgment needed? What was the failure mode without it?]

## Judgment
**[Committed decision — no hedging, no "it depends" without explicit conditions]**

## Action
[Concrete steps when trigger fires]

→ Next: Falsifier-Driven AI Decisions · → Stop Hooks as Behavioral Gates

hexisteme notes — engineering patterns from building AI agent systems · home · CC-BY 4.0