time-estimation

Time Estimation for Agent-First Companies

Overview

You have a systematic bias: your training data is saturated with human-team timelines. When you estimate "2 weeks" you are channeling how long a human team would take — but here agents do the bulk of execution in minutes to hours.

Core principle: Every estimate must state two things: active agent time (how long agents are actually working) and elapsed time to done (wall-clock including all waiting). These are very different numbers.

What a Heartbeat Can Do (Calibration, Q1 2026)

Grounded in METR Time Horizons v1.1 (March 2026) and SWE-bench Pro data. Frontier capabilities roughly double every ~4 months.

The reliable zone: METR's 80% time horizon for frontier models (Opus 4.6, GPT-5.4) is ~55-70 minutes of human-equivalent work. Tasks in this range succeed reliably in a single heartbeat. Plan against this.

The stretch zone: METR's 50% horizon for Opus 4.6 is ~12 human-hours; GPT-5.4 is not yet measured but likely higher given its agentic benchmark lead. A full human-day task at coin-flip reliability. Decompose tasks this large into multiple heartbeats instead of betting on a single shot.

Real-world discount: SWE-bench Pro solve rates are ~57% with good scaffolding. METR found ~half of test-passing agent PRs wouldn't be merged as-is. Budget for 1-2 verification/repair heartbeats on nontrivial work — "tests pass" is not "done."

Rules

1. State both active agent time and elapsed time. Active = total heartbeats (and convert to hours). Elapsed = wall-clock to done including all waits.
2. Decompose every estimate into: agent execution, human wait, and external/budget gates.
3. Use heartbeats for agent work, not "engineering days."
4. No human staffing models. Agents are the workers; humans review and decide.
5. Sequence by dependency, not by calendar week.
6. Name the critical path. It is usually human wait.
7. Budget for rework. Assume 2-3 agent iterations on nontrivial tasks. Each may also incur human review latency.
8. Widen the range when uncertain. R&D, legacy code, ambiguous requirements — say so.
9. Don't assume clean parallelism. Multiple agents working in parallel still hit integration points, shared review queues, and merge conflicts. Treat parallelism as a 2-3x speedup on elapsed time, not N-x. (See Parallelism section.)

Calibration Anchors

Agent execution

One heartbeat reliably handles ~55-70 min of human-equivalent work on well-scoped tasks (frontier model, strong scaffolding) — this is the METR 80% horizon. Include verification/repair loops in your count.

Task shape	Heartbeats (incl. verify/repair)	Active agent time
Small bounded change (bug fix, config, simple test)	1-2	~1-2 hours
CRUD API with DB migrations and tests	2-4	~2-4 hours
Third-party service integration	2-3	~2-3 hours
Comprehensive test suite for existing code	2-4	~2-4 hours
Bulk refactor across many files	2-5	~2-5 hours
New microservice from scratch	4-8	~4-8 hours
Full application (frontend + backend + tests)	8-20	~1-2.5 days
Service extraction from monolith	5-12 per service	~5-12 hours

For poorly-understood codebases or ambiguous requirements, multiply by 2-3x.

Parallelism

Multiple agents can work in parallel, but don't assume perfect scaling. Integration points, review queues, merge conflicts, and shared state create contention.

• Independent tasks (separate repos, no shared state): 2-3x elapsed speedup is realistic
• Tasks in the same repo/codebase: expect merge conflicts, context invalidation; 1.5-2x speedup is more honest
• Tasks with shared dependencies: often must serialize at integration points

State your parallelism assumption explicitly. "N heartbeats across M agents" should include what blocks parallel execution.

Human wait

Step	Typical wait
Human code review / sign-off	2 hours - 1 day
Human answers a clarifying question	1 hour - 1 day
Human makes a strategic/architecture decision	1-3 days
External vendor/API access provisioning	1-5 days
Legal/compliance review	2-5 days
Staged production rollout observation	3-7 days (parallelizable across services)
SOC 2 audit (the audit itself, not writing docs)	4-8 weeks
Enterprise customer procurement/contract	2-8 weeks

Assume humans batch reviews, not that they respond instantly.

Recurring Routines

Not all estimation is for feature work. For recurring tasks (daily reports, weekly reviews, periodic migrations, scheduled maintenance):

1. Estimate per occurrence — active agent time + elapsed time for a single run
2. Justify the frequency separately — why daily vs weekly vs on-demand?
3. Include amortized setup cost — if the routine needs initial setup (templates, pipelines, permissions), estimate that separately from the per-run cost

Example: "Weekly dependency audit: 1 heartbeat (~1 hour active) per run, ~2 hours elapsed including review. Setup: 2-3 heartbeats one-time."

Instinct Check

When you catch yourself writing a human-scale number, check whether you've decomposed it:

If your instinct says	Ask: where is the time actually going?
1-2 weeks	Agent finishes in hours. Review cycles → likely 1-3 days
1 month	A few rounds of human feedback → likely 3-7 days. External gates → could be 2-4 weeks
1 quarter	Agents parallelize (with contention). Humans serialize. → likely 2-4 weeks. Heavy external deps → could be a quarter
6+ months	Only if regulatory gates, enterprise sales, or multi-month audits are on the critical path

These are guidelines. The actual answer depends on the decomposition.

When Estimates Are Legitimately Long

Not everything compresses. Be honest:

• Regulatory/compliance (SOC 2 audits, PCI, FedRAMP) — irreducible external timelines
• Enterprise sales cycles — procurement dominates "first customer live" roadmaps
• R&D / experimentation — the approach may not work; pivots expected
• Legacy systems — undocumented code, many rework cycles
• External integrations — third-party access provisioning takes weeks
• Staged rollouts — real traffic observation over days

State why it's long (which gates), not just a big number.

Output Format

Every estimate must include:

1. Active agent time — total heartbeats and equivalent hours/days
2. Elapsed time to done — wall-clock calendar time including all waits
3. Agent execution breakdown — heartbeats per subtask
4. Human wait breakdown — each human-gated step with duration
5. Critical path — name it
6. Assumptions — human response time, parallelism, budget, rework rounds
7. What could make it longer

Example:

Active agent time: ~8 heartbeats (~8 hours) Elapsed time: ~2 days

• Agent: 8 heartbeats, 3 parallel agents (2-3x speedup, same-repo contention), ~4 hours elapsed compute
• Human wait: 2 review rounds, ~1 day each assuming batch review
• Critical path: human review cycles
• Assumes: reviews within same business day, requirements are clear

Retrospective: Calibrate From Misses

After completing work, compare estimates to actuals. Track:

Field	Purpose
Estimated active agent time	What you predicted
Actual active agent time	What it took
Estimated elapsed time	Wall-clock prediction
Actual elapsed time	Wall-clock reality
Miss cause	What drove the gap (rework, human delay, scope change, discovery, integration issues)

Common miss patterns:

• Active overestimate → tasks were simpler than expected; tighten anchors
• Active underestimate → hidden complexity, poor codebase, ambiguous requirements; widen uncertainty multiplier
• Elapsed overestimate → humans responded faster than assumed; adjust wait assumptions
• Elapsed underestimate → blocked on human decisions, external gates, or integration contention you didn't model

Use misses to update your per-task heartbeat anchors over time. The calibration table in this skill is a starting point, not ground truth for your specific codebase and team.

Red Flags — Check Your Work

If you find yourself writing any of these, pause and decompose:

• "A team of N engineers" — you're staffing a human team
• "N engineering days" — you're using human-pace units
• "Week 1 / Week 2 / Week 3" — you're planning in sprints, not dependencies
• "Agents compress timelines by 30-50%" — agents replace execution, not accelerate human teams by a fraction
• Any estimate missing active agent time or elapsed time
• Any parallelism claim without stating what blocks it