Skip to main content
Recallium gives connected agents access to the same durable project context. You can research in one tool, implement in another, and return later without copying an old chat transcript.

Research in one tool, build in another

In your research agent, ask:
Research rate-limiting approaches for our authentication endpoints. Save the recommendation and its constraints to this project.
Then open the same project in your coding agent and ask:
What did we decide about rate limiting? Use that research to plan the implementation.
The second agent retrieves the saved reasoning from Recallium.

Keep every tool on the same project

Recallium normally derives the project name from the Git repository. If the repository name does not match the existing Recallium project, map the clone once:
This mapping is local to the clone and is not pushed to Git.

Reuse knowledge from another project

Name the source project and the topic:
In payment-service, how did we implement idempotent webhook handling? I want to use the same approach here.
Your agent can retrieve the accessible memories, explain the source project’s constraints, and adapt the pattern to the current repository. Link projects when they represent parts of the same product or a clear parent-child relationship.
Link mobile-app as a child of payments-platform in Recallium.
Each project keeps its own access boundary. The link helps searches discover closely related context.

Review work across several tools

Ask for a time-based recap when work happened in more than one environment:
What did I work on yesterday across my connected coding agents? Group it by project and show what remains open.
Recallium uses the stored project history rather than depending on one tool’s local chat log.
Use the same project name in every connected agent. Most missing-context problems across tools are project-scope mismatches.