Engineering memory
Agents check history before they edit.
Before a coding agent changes anything, it receives the earlier fixes, decisions and lessons that matter, each with its source. After the work, it records what was accepted. Memory advises; the agent and your review still decide.
What engineering memory includes.
Preflight before work, writeback after it, and the records that show where reused code came from and why it can be trusted.
Engineering preflight
Shows an agent the earlier fixes and decisions that matter before work starts.
Decision writeback with receipts
Agents record accepted decisions and outcomes, and get a receipt for each save.
Trust records
Shows people and coding agents why a piece of memory is trusted.
Implementation lineage
Tracks where code was reused, how often it was used and its production status.
Dependency drift
Flags when old code no longer fits the dependencies a project uses today.
Proven-over-similar reuse ranking
Ranks code that was proven in use above code that only looks similar.
Duplication and change signals
Turns repeated content and document changes into signals that help answers.
What the agent gets back.
Preflight returns bounded, sourced evidence. It is advice, not instruction: current code, tests and review decide what is safe.
Sorted by what matters
Decisions and constraints, similar problems, reusable implementations, and incidents or failed approaches, each with its primary source.
Honest about coverage
Results say when coverage is partial. Not finding a precedent is reported as a limit, not as proof that none exists.
Receipts for every save
Each recorded decision gets a receipt. The agent can check whether it was saved and is searchable, and retry an uncertain write without redoing the work.
Why code is trusted
A trust record shows where reused code came from, how it was verified, what is unknown and what conflicts, with every statement labelled by how it is known.
Proven over similar
Reuse ranking puts code proven in use above code that only looks alike. Below the evidence threshold it answers "needs review" instead of offering the closest match.
Drift is flagged
Old code that no longer fits the dependencies a project uses today is flagged, so the agent adapts it instead of copying it as is.
A new task. A history it can build on.
A webhook needs retry handling. Your team has already lived through an incident, changed its policy and built a useful guard. Here is how that history changes the next implementation.
Illustrative engineering walkthrough
An illustrative scenario using synthetic records within one authorised workspace.
01 The request
Add retry handling to the billing webhook handler.
02 The company context
ADR-042: bounded webhook retries
Retry transient delivery failures with a bounded schedule and an idempotency record.
Use at most three delivery attempts for transient failures. Do not retry malformed events or permanent provider responses.Where it applies. Applies: the billing provider distinguishes transient responses from permanent failures.
03 The informed plan
Reuse the idempotency guard. Allow at most three delivery attempts for transient failures. Exclude malformed events and permanent failures from retries.
04 The work and its checks
Adapt the guard to the handler’s transaction boundary. Review the change and test duplicate events, retry limits, transient failures and malformed payloads.
05 The lesson carried forward
Record the reviewed implementation and the conditions that made it work: stable event IDs, an atomic claim and a bounded retry policy. Make that lesson available to the next relevant task.
The next task can retrieve the reviewed lesson with its source and conditions. Current project rules and tests still decide what is safe to reuse.
Give your agents your team’s history.
Anuvrit is in beta and opening to engineering teams in stages. Join the waitlist and we will contact you when there is a place for your team.