Our agents kept rediscovering repository knowledge on different tasks. In 107 coding sessions on Vercel's AI SDK, we found 68 facts that recurred across tickets. We saved an earlier collection of findings in Dosu and checked whether its pages preserved the explanations and evidence. The pages connected failures to fixes, but we also found incorrect paths and a claim whose citation didn't support it.
The clearest example was a build requirement our agents learned in 59 sessions across 40 tickets. In our replay of Vercel AI SDK pull request #19701, our Codex agent was adding a model ID to two providers. Its tests failed because the runner couldn't import @ai-sdk/provider-utils. The package was present, but its compiled output was missing. Our agent built the workspace dependencies and got the tests running.
The repository told contributors to build before testing. Our agent still had to connect the failed import to the missing compiled output. We wanted the next agent to have that explanation when it encountered the same error.
Figure 1Build dependencies before running package testsOur agents learned this rule across 82% of the tasks. Choose a ticket to explore the sessions behind it.
Build dependencies before direct tests
59learning sessions
40different tickets
Package tests import compiled dist/ files from other workspace packages. Build those dependencies first so the test runner can load them.
Tap a spoke to compare the agents on that ticket. Each dot is one session that learned the build rule.
The counts describe extracted learning, not 59 identical failures. Neither agent had access to the other sessions’ findings.
Tracing failed imports to a missing build
The setup instructions name the preparation step without explaining the missing-import failure. Our Codex agent loaded AGENTS.md in every included run. At the revision we checked, AGENTS.md lists pnpm install followed by pnpm build. CONTRIBUTING.md says only a package's dependencies need building before its tests.
Workspace packages consume each other's compiled dist/ exports, so installing dependencies alone doesn't make their tests load. Running a test tool directly inside a package also bypasses the build ordering configured in turbo.json.
Setup automation can enforce the build step before tests run. A shared troubleshooting note explains why that step matters when an agent encounters a missing import mid-task. The session logs supply the symptoms and diagnosis for that explanation.
What did our agents learn across GitHub tasks?
Our agents rediscovered 28% of the repository facts on different tasks. Both Claude Code and Codex attempted the same pull-request tasks in vercel/ai, so the analysis separates repetition within one task from knowledge that appeared across different tasks.
Knowledge that recurs across tickets is worth reviewing for reuse. A build requirement, a test helper, or a documentation convention can apply long after the original ticket closes. Saving the explanation gives a later agent a starting point when it encounters the same problem.
Figure 2Knowledge our agents found across GitHub tasks28% of the extracted facts appeared on different tasks. Open a finding to see what our agents learned.
Choose a group to explore what our agents learned.
242 extracted facts · 142 recur in multiple sessions.
How many tasks shared each finding?Choose a finding below, or select its dot on the chart.
Distinct tickets per fact
Read what our agents learned
Open a finding to read the details.
59 sessions · 40 tickets
Packages in this monorepo import each other's compiled output, so on a fresh checkout you have to build a package's dependencies before its tests or type check will even load.
Model-extracted finding from the current 107-session cohort.
Recurrence identifies candidates for reuse. It does not establish that a finding was undocumented or expensive to discover.
Notes
Each fact counts once. Recurrence means at least two distinct sessions, including repeats and different agents attempting the same ticket.
The counts cover model-extracted findings. We haven't verified a failure-and-fix sequence in every counted session.
The build rule came up most often. Our agents also found faster ways to check types, provider-test helpers, and the right places to add provider documentation.
Both Claude Code and Codex learned 82% of the recurring facts. Keeping that knowledge available across agents would let the next task use an explanation regardless of which agent found it.
Can the next agent check the source?
Dosu saved the build-related findings in a troubleshooting page so later agents could diagnose missing imports. The page explains why package tests and examples need compiled dependencies and gives commands for building them.
The page predates the Codex replay above and draws on an earlier collection of saved findings. Those notes cover package-test failures, missing example types, fresh checkouts, and applications that import compiled output.
Figure 3Help the next agent diagnose the errorExplore how the notes connect an error to its cause and a build command.
Choose a failure to see the explanation our agents could reuse.
↓ Four cited observations
Why tests and examples need a build
Symptom
Workspace imports fail before tests load.
Explanation
The packages consume compiled dist/ exports. Building their dependencies makes those imports available.
Action
Build dependencies before direct package tests.
An added explanation to check
Turbo enforces build order. Invoking the test tool directly bypasses it.
↓ Note citation↓ Repository evidence
The cited build-dependency note does not contain the explanation of Turbo task ordering. Its build-dependency observation supports a different part of the page.
A useful explanation can still carry the wrong note citation. The diagram paraphrases the page we audited. We haven't tested it in a later agent session.
Notes
The diagram paraphrases the generated page we audited.
The repository's turbo.json supports the task-ordering explanation. None of the four cited notes contains it.
The page also explains why a direct test command can fail when Turbo's test task handles the build first. The repository's turbo.json requires dependency builds and the package's own build through ^build and build. The page gets that explanation right, but cites a note that doesn't contain it.
To verify the task-ordering claim, our next agent needs the repository configuration as its source. Following the page's citation to the build-dependency note wouldn't explain why the test commands behave differently.
What knowledge can the next agent use?
Dosu's pages covered about three-quarters of the findings in our earlier collection. A model matched saved facts to pages, and our spot checks examined those matches. The remaining findings stayed available as notes.
A match tells the next agent where to look. Before relying on the page, the agent still needs to check that its explanation applies to the task and that its sources support the advice. Match confidence describes how closely a page covers a finding.
Figure 4Explore the knowledge Dosu connected74% of saved findings matched a page. Choose a finding to inspect its match.
Earlier saved knowledge
Each segment is one saved fact. Choose a group, then open a finding to inspect its page match.
What knowledge would help your next task?
Open a finding to read the details.
High confidence
Highest-confidence page match:
Workspace Dependency Build Order
From the earlier collection of saved findings.
Match confidence is not a correctness score.
Notes
This figure uses the earlier collection of saved notes and generated pages. The session analysis uses a later collection.
Each fact counts once at its highest match confidence. Unmatched facts remain notes.
Confidence measures the fact-to-page match. The spot checks and path audit below assess correctness separately.
Which file path is right?
Another saved page collected documentation locations to help agents add batch API docs. It pointed twice to content/docs/05-ai-sdk-providers, a directory that doesn't exist. The correct path is content/providers/01-ai-sdk-providers. Dosu had that correct path elsewhere in the saved knowledge, but the page still gave the wrong one.
Our broader path check found missing references in two generated pages. Checking whether a path exists catches this kind of error. Reading the referenced code establishes whether it supports the explanation.
Saving the correct directory in one note didn't prevent another page from listing the wrong path. That conflict can leave the next agent to investigate a location the Library knows. Reconcile conflicting instructions and check each citation before asking an agent to use the page.
How much budget do our agents spend relearning?
Requests associated with relearning accounted for about a third of our estimated session cost. Inspecting those requests can help identify investigation a later agent could avoid. Each request can also include required work, such as building dependencies, that an agent would still need to do with the explanation available.
The cost attribution uses Decant, our session-log accounting tool, and counts each request once. Removing the longest stretches, mostly build or type-check polling, left the share at roughly a third.
Requests included
Estimated cost
Share of session cost
Requests associated with relearning
$25.38
33.0%
Excluding ten long Codex stretches
$24.20
31.5%
Notes
Both rows use the same total estimated session cost of $76.87. The excluded stretches each span more than 15 API requests.
Dollars use recorded tokens at pinned API rates. The sessions ran on subscriptions. Codex's cache-write charge remains unmeasured.
The denominator excludes the later cost of extracting findings and generating pages.
We haven't measured how much saved knowledge reduces that work. A replay with the knowledge available would test whether an agent retrieves the explanation, applies it correctly, and completes the task at lower total cost. The comparison must score the patches and include the cost of capturing and retrieving the knowledge.
How we checked the findings
Fresh checkouts expose setup requirements that an established workspace may satisfy. Claude Code on Opus 5.5 and Codex on GPT 6.1 Sol attempted 49 merged pull-request tasks from Vercel's AI SDK. Each session started from the pull request's base commit with its title and description, without the diff or other sessions' findings. Our paired cost study describes ticket selection and agent configurations.
Models extracted findings from the transcripts and grouped equivalent claims. Our spot checks examined the groups. A session counts as learning a fact when its transcript supplies a finding in that group. The counts describe selected tasks and fresh checkouts, so they don't establish how often agents relearn facts during everyday development in an established workspace.
Repeated runs can make a fact look common even if it applies to only one task. The analysis therefore separates recurrence within one task from recurrence across tasks and counts each fact once. The page audit covers only the earlier Library collection, which our team and Claude reviewed before auditing its pages. The newer findings hadn't entered that Library yet.
When a transcript range ends on a tool's output, the attribution includes the next request so the estimate covers the agent reading that output. We couldn't repeat a separate check against the extraction models' original ranges because we hadn't retained the Claude Code originals.
Start time determines the accounting order, but sessions could overlap. An earlier-starting agent hadn't necessarily finished learning a fact before another started. All included Claude Code sessions started before our Codex sessions. That ordering, the paired tasks, and unequal repeat counts prevent the attribution or overlap counts from supporting a ranking of the agents.
The setup isolated user-level configuration except for a recorded leak in some Codex runs, where the agent opened a user-level skill. The study doesn't score patches or comprehensively assess every page claim.
Let Dosu learn from your coding sessions
Dosu can study your existing sessions from Claude Code, Codex, and Cursor. It reads the transcripts and saves useful findings, such as build requirements and code locations, to your Library. Your team and connected coding agents can then retrieve that knowledge on later tasks.
After Dosu studies your sessions, run dosu knowledge report to explore what it saved. Ask your agent about a part of the repository you've worked on, inspect the knowledge it retrieves, and help it learn any missing details. Our September Drop shows how session study and source inspection work.
Found this article helpful?
Share it with your network to help others discover valuable insights.
Join leading organizations using Dosu to automate documentation, streamline support, and empower development teams to focus on building great products.
