What You Will Build

You will plan a TypeScript coding-agent system that can receive a repository task, gather relevant project context, request actions through tools, and preserve selected facts for later sessions. The central design goal is not to save every conversation. It is to make useful knowledge available when the next task begins.

That distinction matters because a model’s immediate conversation context is not the same thing as long-term memory. A memory-aware agent treats memory as persistent, structured infrastructure outside the model. At startup, it can load prior context; while working, it can retrieve relevant state and tools; after an interaction, it can extract or refine facts and write them back. This makes memory a designed subsystem rather than an ever-growing transcript.

The supplied evidence does not verify a particular Bun runtime, SQLite schema, FTS5 search implementation, OpenAI SDK version, or complete coding-agent code sample. Accordingly, this tutorial gives an implementation plan and architectural checkpoints, not a copy-and-paste program. Choose and verify the runtime, storage adapter, model provider, and API usage against their current official documentation before writing production code.

Prerequisites

• Comfort with TypeScript, asynchronous application flows, and agent tool concepts.
• A clear definition of the repository or project the agent is intended to assist.
• A decision about which information may be retained between sessions and which must not be stored.
• A model provider and storage technology selected from their current documentation, with credentials handled outside source code.

Step 1: Define the Agent’s Memory Contract

Begin with a written contract that states what the agent may remember, how those facts will be used, and how they can be corrected or removed. Memory engineering treats long-term memory as first-class infrastructure: it exists outside the model and is structured so that an agent can use it deliberately. This is a more useful starting point than simply retaining every message and placing the entire history into every future prompt.

For a coding assistant, candidate memory categories might include project conventions, architectural decisions, known risks, and commands or procedures confirmed during prior work. These are design examples, not a claim that any specific framework stores those categories automatically. Keep the contract narrow: retain only durable information that could help a future repository task, and distinguish confirmed observations from assumptions.

Write down the boundary between session context and long-term memory. A task-specific question or temporary debugging detail may be useful only while the current task is active. A confirmed project convention may be useful later. A secret, credential, or unrelated personal detail should not become a durable project memory. The verified sources establish the value of structured memory and fact-extraction pipelines, but they do not prescribe a universal retention policy; define one for your application.

Also decide who or what can update the memory. A write-back loop can let an agent update its own memory autonomously, but that capability is a design choice, not proof that every proposed fact is correct. Specify how updates will be checked, how conflicting facts will be handled, and how a human can inspect or correct stored knowledge.

Step 2: Design the Memory Lifecycle

Plan memory as a lifecycle with four distinct stages: loading, retrieval, consolidation, and write-back. Keeping these stages separate makes it easier to reason about what information enters a model request and why a fact was preserved.

1. Load at startup. Initialize the agent with the persistent state appropriate to its task. The objective is to begin with useful prior context, not to indiscriminately replay every previous interaction.
2. Retrieve for the current task. Select the facts and tools that are relevant to the task at hand. Memory-aware agent design uses retrieval to assemble context, state, and tools during execution.
3. Extract and consolidate. Turn conversation evidence into structured facts, then consolidate episodic information into more reusable semantic knowledge where appropriate. The source material describes these as memory-engineering patterns; it does not provide a universal schema or extraction prompt.
4. Write back deliberately. Store useful updates so a later session can retrieve them. Treat this as a separate operation with its own validation and retention rules, rather than assuming every model response belongs in long-term storage.

This lifecycle also clarifies the difference between a record and a useful memory. A transcript is a record of what was said. A durable memory is selected information intended to help with future work. Converting the former into the latter requires extraction, structure, and consolidation; simply preserving more text does not by itself create better recall.

Step 3: Decide How Retrieval Will Work

Retrieval is the bridge between persistent storage and the current task. A coding agent may have far more stored context or available tools than it can use effectively in one request. The verified course description specifically highlights semantic search as a way to scale tool access and retrieve only relevant tools at inference time, addressing the challenge of agents with hundreds of tools.

Before choosing a search method, list the information the agent must find. Project conventions, an architectural...