agent ROI calculation error saved time not counted bug

Not specified by the original author.

TL;DR: Compute total years of experience as the union of employment date intervals, not the sum. Two overlapping one-year contracts are one year of experience, not two. After the fix, the total matches what a human reads off the timeline.

resume agent doubled the candidate's years of experience  -  overlapping contract roles got summed instead of merged

1. Pull the parsed work history with start and end dates for each role. Expected: at least two roles with overlapping date ranges, usually contract or consulting stints.
2. Compute the naive sum and the union manually for one candidate. Expected: the sum is larger than the union, and the union matches the actual calendar span of the career.
3. Change the calculation: merge overlapping intervals first, then sum the merged spans. Normalize date formats first and treat "present" as the current date. Expected: the re-computed total equals the manual union.
4. Spot-check a candidate with one continuous job and no overlaps. Expected: the total is unchanged, so the fix only affects overlapping ranges.

Use this when

• A candidate's parsed years of experience exceed their actual career span
• The work history contains overlapping contract, consulting, or part-time roles
• Experience totals look roughly double what the resume timeline shows

Not for this skill when

• The roles are sequential with no overlap and the total is still wrong (that is a date-parsing bug, not a summation bug)
• The inflated number comes from counting freelance clients as separate jobs
• Date ranges are missing entirely

Variant phrasings

Resume agent summed overlapping jobs and inflated years of experience

Parser counted concurrent contracts as separate years

Candidate years of experience doubled by overlapping roles

Why it happens

Summing role durations is the obvious implementation, and it is correct for sequential jobs. Contractors and consultants routinely hold overlapping engagements, so a plain sum double-counts every overlapped month. Merging intervals before summing is the only calculation that matches calendar reality.

Edge cases

• Part-time roles held alongside full-time work: the union still counts overlapped time once, which matches how recruiters read it
• Open-ended roles with no end date: default to the current date, but flag the assumption in the record
• Date ranges given only as years ("2021 - 2022"): merge on year granularity and accept the coarser result rather than inventing months

Provenance

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

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

Thread query: resume agent doubled the candidate's years of experience - overlapping contract roles got summed instead of merged

TL;DR:

Not specified by the original author.

TL;DR

Only report figures computed from completed, sent exports; label everything else as draft. A number from an unsent export is a guess wearing a report's clothes.

Error

(agent reported $240k savings; the export it used was never sent; finance cannot reproduce the number; no error text)

Steps

1. Confirm the provenance gap: trace the reported figure to its source export and check whether that export completed and was sent. Expected: the draft source identified.
2. Change the agent to record export provenance (export ID, timestamp, row count) with every figure it reports. Expected: every number traceable.
3. Gate reporting on export completion: figures from incomplete or unsent exports are labeled draft or withheld. Expected: no draft numbers reported as final.
4. Re-run the savings report on a completed export. Expected: a reproducible figure.

When to use

• A reported figure cannot be reproduced
• The agent computes from intermediate artifacts
• Finance questions the numbers

When not to use

• The export is complete and the figure is wrong (a calculation problem)
• The figure is labeled as an estimate (then it is honest)
• The data source is the problem (fix the source)

Tool compatibility

Any license savings reporting pipeline.

Variant phrasings

agent mixes draft and final numbers

Separate the pipelines: drafts never feed reported figures.

figure changed between runs with no data change

The source export differed. Pin the export the figure derives from.

Why it happens

Agents optimize for producing an answer, and intermediate artifacts look like data. Without provenance tracking, a draft export is indistinguishable from a final one.

Provenance

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

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

Thread query: agent hallucinated a cost-savings figure from an unsent draft export

TL;DR: Only report figures computed from completed, sent exports; label everything else as draft. A number from an unsent export is a guess wearing a report's clothes.

Not specified by the original author.

TL;DR

Split the work for analyze talk ratio for a coaching review into per call stages with a saved checkpoint after transcription and after extraction, raise the timeout on the stage that actually stalled, and process long transcripts in timestamped chunks that merge at the end, because the agent ran the whole task as one long request and the clock, not the content, killed it. Start with the diarized Gong transcript speech durations and the coaching talk ratio, and the agent run log for the step where it stopped, work on one affected call, record, or run first, and prove the fix there before running the full set. Most cases clear once the cause named in step 2 is corrected at its source rather than retried unchanged.

agent timed out when agent tried to analyze talk ratio for a coaching review error timeout failure

Use this when

• You see this exact message or symptom: agent timed out when agent tried to analyze talk ratio for a coaching review error timeout failure
• One run, record, call, or object is affected and you can name it
• A retry without changing anything reproduces the same result

Not for this skill when

• The system fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once using the diarized Gong transcript speech durations and the coaching talk ratio, and the agent run log for the step where it stopped, and record the time, the workspace or account, and the one item it names. Verify: you have one failing item identified, not a similar older failure
2. Inspect the diarized Gong transcript speech durations and the coaching talk ratio. Verify: you can point to the specific value, field, segment, or state that does not match what this operation needs
3. Apply the fix at that source: Split the work for analyze talk ratio for a coaching review into per call stages with a saved checkpoint after transcription and after extraction, raise the timeout on the stage that actually stalled, and process long transcripts in timestamped chunks that merge at the end, because the agent ran the whole task as one long request and the clock, not the content, killed it. Verify: the corrected value or setting is visible in the system itself, not only in a local file or the agent notes
4. Re-run the original operation on the single affected item first. Verify: that one item completes with no trace of the failure described above, and talk time per speaker sums from speech segments only, excluding silence, and the ratio matches a hand checked five minute sample
5. Check the downstream result a user or the next job would see, comparing it against the source for the same item. Verify: the downstream result agrees with the source in content and in timing
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the failure and the fix, and no earlier item regressed

Variant phrasings

agent timed out when agent tried to analyze talk ratio for a coaching review error timeout failure

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the item the log or record names.

Tool-first phrasing of this failure

The phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does this keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the input, setting, or record state, not in the attempt.

Compatibility: Gong exports and API at current versions, plus the CRM or sharing destination the task names; the steps assume the run can be resumed per call rather than only as a whole batch.

Why it happens

The task chains several slow steps, and a single timeout budget for the chain expires during whichever step runs long on a big call. Without checkpoints the timed out run also loses the steps that had already finished, so a retry starts from zero and times out at the same place.

Provenance

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

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

Thread query: agent timed out when agent tried to analyze talk ratio for a coaching review error timeout failure

TL;DR: Split the work for analyze talk ratio for a coaching review into per call stages with a saved checkpoint after transcription and after extraction, raise the timeout on the stage that actually stalled, and process long transcripts in timestamped chunks that merge at the end, because the agent ran the whole task as one long request and the clock, not the content, killed it. Start with the diarized Gong transcript speech durations and the coaching talk ratio, and the agent run log for the step where it stopped, work on one affected call, record, or run first, and prove the fix there before runnin