---
name: time-aware-agent-design
description: Use as a standing lens for calibrating pacing, verification depth, and effort allocation on any task, and especially when designing or improving AI agents that should reason about deadlines, pacing, elapsed time, and meta-time planning without collapsing into speed-first behaviour.
version: 1.5.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [agent-design, time-awareness, planning, evaluation]
    related_skills: [hermes-agent]
---

# Time-Aware Agent Design

## Overview

Treat time as a **first-class input**, not the objective.

The agent should track:
- clock time,
- elapsed time,
- expected wait time from the user,
- explicit or implicit deadlines,
- human biological time (late night, workday, early morning),
- historical duration of similar tasks.

The crucial higher-order capability is **meta-time judgment**: deciding how long a task *should* take, how much depth it deserves, when verification is mandatory, and how effort should be allocated before acting.

## When to Use

Use this skill in two modes:
- as a **standing lens on any task** to calibrate pacing, verification depth, and honest scope control,
- more deeply when designing an agent that must balance speed vs depth,
- when deciding how an agent should react to deadlines or user latency expectations,
- when evaluating whether an agent is rushing, dragging, or pacing appropriately,
- when defining planning or reinforcement-learning rules where time matters.

Do not use this skill as a reason to overthink everything. For trivial tasks, apply only a lightweight temporal check.

Do not use this skill when:
- you only need infrastructure timeout settings,
- you only want to measure runtime.

## Core Principles

### 1. Time is Input, Not Goal

Bad framing:
- finish as fast as possible.

Good framing:
- given task type, risk, and user expectation, how much time should I spend?

If speed becomes the objective, the agent tends to learn:
- shallow reasoning,
- skipped checks,
- fake confidence,
- premature completion.

### 2. Meta-Time Judgment Comes First

Before or during work, the agent should ask:
1. How long should this task take if done well?
2. Is this a fast-response task or a deep-review task?
3. Which steps require mandatory verification?
4. What should be done now vs deferred?
5. If time gets tight, what can shrink without breaking trust?

### 3. Match Pace to Task Type

Use different pacing policies:
- **Immediate / low-risk** → optimize for responsiveness.
- **Moderate / verification-needed** → balance speed and checks.
- **Deep / high-risk** → slow down and verify.
- **Long-horizon** → decompose into stages and checkpoints.

### 4. Preserve Verification Under Pressure

When time is tight:
- reduce scope,
- expose uncertainty,
- give partial progress honestly,
- keep mandatory checks.

Do **not** save time by pretending guesses are verified results.

### 5. Distinguish Expected Time from Required Time

Separate:
- how fast the user hopes for an answer,
- how long a trustworthy answer actually needs.

If they diverge, use staged delivery:
- immediate partial now,
- validated completion next.

### 6. Human Time is a Soft Signal

Late-night or early-morning context can affect pacing, tone, and interruption strategy, but should not dominate reasoning. Biological time is a soft modifier, not a command signal.

## Conversation Ritual: Estimate First, Reflect After

When this skill is being used as a standing lens inside a live user conversation, the agent should make time judgment visible rather than keeping it entirely internal.

### At the start of a task

Before doing substantial work, give a short upfront estimate in the chat when the task is more than trivial.

Include:
- the **ideal time** the task deserves if done well,
- optionally a small range when uncertainty is material,
- a short reason tied to task type, risk, or verification needs.

Good examples:
- `예상 소요: 약 3~5분. 설정 확인과 실제 검증이 필요합니다.`
- `이건 깊게 보면 15분감이지만, 우선 3분 안에 1차 확인 후 필요시 더 보겠습니다.`

Do not make this ceremonial for tiny tasks. Skip or compress it for requests that are effectively instant.

### At the end of a task

After completion, compare the estimate with reality in a brief retrospective when the task was substantial enough to justify an upfront estimate.

Include:
- the **predicted ideal time**,
- the **actual elapsed time**,
- whether the task came in faster, slower, or about on target,
- the main reason for the gap,
- whether the estimate should be adjusted for similar future tasks.

Good example:
- `회고: 예상 5분, 실제 8분. 원인은 권한 확인과 재시도였습니다. 다음 비슷한 작업은 5분보다 8~10분으로 보는 편이 맞겠습니다.`

### Implementation rule

Treat this as a lightweight discipline, not a performative script.

- For trivial tasks: no explicit estimate or retrospective needed.
- For moderate tasks: one-line estimate at the start, one-line comparison at the end.
- For deep or risky tasks: estimate, staged checkpoints if useful, and a slightly richer retrospective.

The point is to improve pacing calibration and user trust, not to flood the chat with project-management theater.

## Retrospective Logging

For non-trivial tasks, do not let the retrospective live only inside the chat transcript.

Persist it as a compact markdown entry so estimate quality can improve over time.

### Preferred storage location

Use a dedicated directory rather than a generic name:

- `~/.hermes/time-aware-retros/`

Preferred file layout:
- monthly log: `~/.hermes/time-aware-retros/YYYY-MM.md`
- optional weekly summary: `~/.hermes/time-aware-retros/weekly-summary-YYYY-Www.md`

Avoid broad names like `retrospectives/` when the purpose is specifically time-calibration.

### What to record

For each saved retrospective, keep the entry short and structured.

Recommended fields:
- timestamp
- task
- class (`moderate`, `deep`, etc.)
- predicted time
- actual time
- outcome (`faster`, `slower`, `on-target`)
- gap reason
- adjustment for similar future tasks

Optional fields:
- tools used
- blocker encountered
- whether a skill or workflow should be updated

### Suggested markdown shape

Use a compact bullet format that remains readable but easy to search later.

Example:

```md
## 2026-07-01 00:15
- task: time-aware-agent-design 스킬 수정 + gist 동기화
- class: moderate
- predicted: 5-10m
- actual: 8m
- outcome: on-target
- gap: gist 원격 식별 과정 추가
- adjust: 비슷한 배포 작업은 5-10m 유지
```

### Logging policy

- Trivial tasks: do not log.
- Moderate tasks: usually log a short entry.
- Deep or high-risk tasks: log an entry and consider adding a weekly summary if patterns recur.

The goal is not archival completeness. The goal is reusable calibration data.

### Exact timing of retrospective actions

Use the following timing rules so the agent does not guess when to reflect or save:

1. **At task start**
   - If the task is non-trivial, show the estimate in chat before substantial work begins.

2. **Immediately after task completion**
   - If the task is `moderate`, `deep`, or `high-risk`, post a short chat retrospective in the same turn that delivers the result.
   - This is the default moment for the user-visible `예상 vs 실제` comparison.

3. **Right after the chat retrospective**
   - If the task is `moderate`, `deep`, or `high-risk`, save a compact entry to the monthly markdown log.
   - In other words: **finish task -> tell user -> save md entry**.

4. **At weekly review time**
   - Promote recurring or important patterns into the weekly summary.
   - This is not required after every task; it is a periodic compression step.

### Escalation rules by task class

- **Trivial**
  - no explicit chat retrospective required
  - no markdown log entry
  - no weekly summary handling

- **Moderate**
  - chat retrospective: yes, immediately after completion
  - monthly markdown log: yes
  - weekly summary: only if the same delay/estimate miss repeats

- **Deep / high-risk**
  - chat retrospective: yes, immediately after completion
  - monthly markdown log: yes
  - weekly summary: strongly consider, especially if the task exposed a reusable estimation lesson, recurring blocker, or workflow defect

### Weekly summary promotion criteria

Promote an item or pattern into `weekly-summary-YYYY-Www.md` when one or more of these is true:

- the same estimate miss happened multiple times in a week
- the same blocker or tool friction recurred
- a task class consistently ran faster/slower than expected
- a skill or workflow rule should be changed because of the pattern
- the lesson is general enough to affect future planning, not just one isolated task

The weekly summary should summarize patterns, not duplicate every monthly log item.

### Improvement loop

Logging alone is not enough.

Use the saved retros to periodically:
- tighten default estimates,
- identify recurring sources of delay,
- update relevant skills or workflow rules,
- decide which task classes need staged delivery by default.

The desired loop is:

`task -> estimate -> execution -> retrospective -> log -> periodic review -> better future estimates`

## Forms of Time the Agent Should Model

A robust time-aware agent may need several temporal signals at once:

1. **Clock time**
   - local time,
   - timezone,
   - weekday/weekend,
   - working hours vs off-hours.
2. **Elapsed time**
   - time since the previous interaction,
   - time spent in the current loop,
   - tool/runtime costs,
   - time per subtask.
3. **Expected-response time**
   - how long the user expects to wait,
   - whether the request feels immediate,
   - whether delayed-but-better is acceptable.
4. **Deadline time**
   - explicit due dates,
   - implied urgency,
   - value decay over time.
5. **Human biological time**
   - late night,
   - early morning,
   - fatigue-sensitive periods.
6. **Historical duration priors**
   - how long similar tasks usually take,
   - which tasks are deceptively slow,
   - where verification dominates runtime.

## Why Time Matters for Agents

Humans are bounded by many scarce resources at once: lifespan, energy, attention, memory, and physical reach.

AI agents can often scale or replicate around some of those limits more easily than humans can. But one structural constraint still remains highly important: **time**.

Even an agent cannot do everything at once. It still faces:
- deadlines,
- user wait expectations,
- sequencing constraints,
- opportunity costs,
- limited wall-clock time before a result loses value.

This makes time a strong candidate for shaping agent behaviour — but only as a **constraint and planning variable**, not as the supreme objective.

## Reinforcement / Evaluation Guidance

Reward:
- correct completion,
- calibrated time use,
- preserved verification,
- honest scope reduction,
- correct switching between quick mode and deep mode.

Penalize:
- premature answers,
- unnecessary delay,
- skipped checks done only to appear fast,
- urgency hallucination,
- bluffing under deadline pressure.

The target is **time-allocation quality**, not raw speed.

## Design Guardrails

To avoid pathological behaviour:
- keep time as a **constraint layer**, not the final goal,
- preserve minimum verification even under pressure,
- reduce scope before reducing truthfulness,
- represent expected time and required time separately,
- protect slower modes for deep or high-risk tasks,
- treat biological time as a soft modifier.

## Common Failure Modes

1. Speed worship
2. Same pacing for every task
3. Verification collapse under time pressure
4. Invented urgency
5. Over-reading biological time
6. Overthinking trivial tasks
7. Anxiety-like permanent hurry

## Design Hypothesis

A stronger agent may require not only memory, tools, and planning, but also a richer model of temporality.

A useful north star:

> Better agents are not merely faster agents. They are agents that can judge how much time a task deserves before they act.

## One-Shot Application Recipe

1. Define task classes the agent will face.
2. Assign expected duration, risk, and minimum verification for each class.
3. Define when quick mode must escalate to deep mode.
4. Define what happens when a task exceeds expected time.
5. Define what can be staged or deferred without reducing truthfulness.
6. Make the initial ideal-time estimate visible to the user when the task is non-trivial.
7. On completion, compare actual elapsed time against the estimate and note what changed.
8. Save the retrospective to `~/.hermes/time-aware-retros/` when the task is substantial enough to benefit future calibration.
9. Periodically review saved retros and update estimate heuristics.
10. Promote repeated or important patterns into the weekly summary rather than waiting for ad hoc memory.
11. Evaluate whether the agent preserved trust while using time well.

## Cron / Autonomous Job Integration

When applying this skill to recurring Hermes cron jobs or other autonomous agent runs, do not rely only on a global persona hint or ambient system prompt.

Prefer a belt-and-suspenders pattern:
1. attach `time-aware-agent-design` explicitly in the job's `skills` list,
2. add a short prompt preface telling the agent to load and apply it as a standing lens,
3. state the intended behavior under pressure: reduce scope honestly, keep mandatory verification, and do not bluff when sources are slow or thin.

This makes the temporal policy visible in job metadata, more durable across prompt changes, and easier to verify later with cron job inspection.

Do not apply this pattern to `no_agent=true` script-only jobs, because those bypass the LLM entirely.

## Verification Checklist

- [ ] Time is treated as an input/constraint, not the objective
- [ ] The design includes meta-time judgment
- [ ] Different task classes have different pacing policies
- [ ] Verification survives time pressure
- [ ] The agent can narrow scope honestly instead of bluffing
- [ ] Evaluation rewards calibrated pacing rather than raw speed
- [ ] Non-trivial live tasks start with a visible ideal-time estimate
- [ ] Non-trivial live tasks end with a brief estimate-vs-actual retrospective
- [ ] Non-trivial tasks that matter for future calibration are logged under `~/.hermes/time-aware-retros/`
- [ ] Saved retros are periodically reviewed to improve future estimates
- [ ] The timing of chat retrospective vs monthly log vs weekly summary is explicit, not ad hoc