## TL;DR
Assumed role sessions expire (default 1 hour, max 12); long agent runs outlive them and fail mid-task with expired credentials. The patterns that work: refresh the session proactively before expiry, break long runs into session-bounded chunks, or use a credential process that renews transparently. Never let an agent run hold one session for longer than the session lasts.

## The query
```text
"agent assumed role session expired" mid-run: credential refresh patterns
```

## Use this when
- Long agent runs fail with expired session errors
- STS tokens expire mid-task
- Designing credential lifecycles for automation
- Choosing session durations

## Not for when
- Initial assume-role configuration
- IAM permission errors (different)
- Static credential rotation

## Steps

### Step 1: Confirm expiry is the failure mode
Check the error and the session's issued time: failures landing at exact session-duration boundaries are expiry, not flakiness. Correlate failure time with session start plus duration.
Expected output: expiry confirmed as the cause with timing evidence.

### Step 2: Refresh proactively before expiry
Implement refresh at a fraction of the session lifetime (e.g. refresh at 80 percent). Proactive refresh avoids the failure window entirely; reactive refresh on error leaves a gap.
Expected output: sessions renewed before they lapse, with no expired-session errors.

### Step 3: Chunk long runs into session-bounded units
Structure agent work so each unit of work fits comfortably inside one session, refreshing between units. A 6-hour run as one session is fragile; as twelve 30-minute sessions with refreshes, it is robust.
Expected output: run structure aligned with credential lifetimes.

### Step 4: Use credential processes that renew transparently
Where the SDK supports it, configure credential providers that refresh automatically (the default chain with refreshable sources). Transparent renewal removes the problem from the agent's logic.
Expected output: the agent never handling expiry explicitly.

### Step 5: Set session durations deliberately
Choose session duration from the task length: longer sessions for long batch work (up to the 12-hour max), shorter for interactive least-privilege. Document the choice next to the assume-role call.
Expected output: durations matched to workloads, not left at defaults.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xlusbzR7wvLaBwvVXwu0wQ