Claude Code's Projects Feature Recovers Architecture From Build Records Alone

Anthropic's redesigned Projects feature in Claude Code beta gives AI agents a shared memory that persists across separate sessions. The feature stores decisions and context that would otherwise vanish when a new conversation starts. To explore how agents might recover context from another source entirely, an engineer at Bit Cloud ran an experiment: could Claude Code rebuild understanding of a production system using only the dependency records that a build platform creates when versioning components?

The problem Claude Code users encounter repeatedly is familiar. A developer returns to a codebase built weeks earlier, starts a fresh session with no prior conversation and no local code, and asks for a small change. The agent must rediscover the system's shape: which service owns the data, which frontend consumes it, what types flow between them. The original conversation that explained these relationships is either gone or compressed into a summary. The source files show what exists but not what depends on what.

Since September 17, Claude Code's redesigned Projects have kept shared memory across threads in beta cloud sessions, allowing the agent to recall facts like "the release moved to Friday" or "check with the billing team before touching that service." But the engineer wanted to test a different information source: the dependency records that a build platform writes automatically when it creates each version of a component.

What a fresh session recovered without memory

The test subject was a small support console built earlier with Claude Code. It contains four components: a React app, an Express service backed by MongoDB, a shared ticket entity, and a platform component that places the app and service behind a single gateway. All four are versioned in a public scope called bit-oss.support and run in production over HTTPS.

The engineer opened a fresh Claude Code session in an empty workspace—no conversation history, no local code—and issued a single request:

Add filtering by ticket status and assignee to the support console in bit-oss.support.

Claude found the workspace empty and recognized that the console lived remotely. It called read_scope for bit-oss.support, which returned the four components and their dependencies. It then called read_components for the app, service, and ticket entity, retrieving API references and file inventories before touching any source code.

The critical discovery came from the records themselves. Both the app and service depended on the same version of the ticket entity. The entity's class documentation stated, "shared between the support service and the agent-facing app," and this sentence appeared in the API reference. The dependency records supplied this context without any prior conversation.

Claude imported all four components with bit import, inspected the source, and implemented client-side filtering inside the app. Validation reported 41 passing tests, including nine new filtering tests. The agent discovered the system through MCP, established how to modify it through source inspection and tests, and kept the change inside the app, leaving the shared ticket entity and service untouched. Understanding what is shared also tells an agent what not to touch.

Where the records ran out

The dependency records stopped providing useful information at the level of behavior. The app's API reference does list the routes it calls—GET /tickets, POST /tickets, PATCH /tickets/:id, and POST /tickets/:id/comments—in the documentation for a fake service used in tests. But nothing verifies that this list matches the real service's actual routes. The records showed which components shared the ticket contract; whether the routes on each side still aligned required manual inspection and testing.

A green build also proves less than it appears. The MongoDB integration tests skip when their temporary database fails to start on the CI runner, so a passing build does not confirm they actually ran. The engineer verified persistence by hand: create a ticket, add a comment, restart the platform against the same database, and confirm both persist.

The support console is a demo with a predefined account and a public signing secret. Concurrency control, migrations, recovery procedures, and mandatory database tests remain unimplemented. These represent ordinary engineering work, and the engineer noted this is where engineer time should be spent.

Memory files or dependency records?

Memory holds what someone chose to document. In Claude Code, this means CLAUDE.md or AGENTS.md instructions written by a person, plus auto-memory notes that Claude generates from corrections and preferences. The redesigned Projects add decisions—such as why an export was dropped—that no build system will ever record. Each note is accurate at the moment it was written. Claude Code records each memory file's write time, and its documentation explains the reason: "the timestamp shows how current the fact is."

A build system writes a dependency record when it creates a component version, and that record becomes part of the version itself. When the support app was versioned, the build system recorded its dependency on a specific version of the ticket entity without anyone deciding it was worth noting, and the record cannot drift from the version it describes. Because read_scope returns each component at its latest version, the records Claude read were current. A memory note carries the time it was written, but nothing ties it to a code version. In the test, the session had no conversation and no local code. The only memory in the workspace was the generic AGENTS.md that bit new writes, instructing the agent to look things up on the platform. The records did the rest: they were enough to find the shared contract.

The two sources cover different ground and work best together. Memory captures intent—the release date, the person to ask, or why a feature was cut. Records capture structure and meaning: which version of what depends on which. Nx serves its project graph to agents over MCP, and Sourcegraph serves code search and navigation across repositories; both excel at that. For this test, the engineer wanted something narrower: a record per component, written when its version was created, that remains valid when the other side of a dependency lives somewhere the agent has not indexed.

When should a team start?

At the first component. The records in this test cost nothing extra because they were written as each version was made, starting on day one. The engineer created the workspace with bit new, which supplied the Bit Cloud MCP connection in .mcp.json and an AGENTS.md with agent instructions. At the start of the original build, Claude used that connection to search an existing design-system scope for parts it could reuse; the four components now depend on 16 that already existed, ten from that design system. Rebuilding that map later, after one team renames a shared field and another discovers the change through error logs, is the expensive version of the same work.

None of this requires Bit Cloud's product specifically; it just requires dependencies to be recorded wherever the work happens. Agents can already reach production. What they still lack, on every request after the first, is a view of the system they are about to change. That view is cheapest to build before the second component exists.