Updated 5 November 2026. Checked against Anthropic’s current Projects documentation. Availability and local execution have changed since the September launch; this is a practical assessment guide, not a product benchmark.
How does project memory work in Claude Projects?
Anthropic’s Projects documentation describes one ongoing conversation that coordinates related work. The coordinator starts or reuses threads, and each thread reports its results back. A cloud coding thread works on its own branch and can open a pull request for review. Overlapping changes still need reconciliation.
Project memory consists of files containing requirements, decisions and pitfalls. Every cloud thread reads the MEMORY.md index at startup and opens other memory files when needed. Project instructions are separate text sent to new threads and to the coordinator. Repository instructions in CLAUDE.md remain separate again. Put a release constraint in the authoritative instructions and test that the worker has received it.
For example, the project may remember who must approve a billing change. That note helps continuity, but access controls and an independent release decision still need to enforce the boundary. Check important remembered facts against their source when requirements change.
Who can use Projects now?
The current documentation describes a public beta on Pro, Max and Ultra plans, with gradual rollout. Team and Enterprise are not yet offered this Projects experience. Check for Projects in the sidebar or under More at claude.ai/code or in the desktop Code tab. A qualifying plan does not establish that rollout has reached your account.
For coding work, confirm the Claude GitHub App has access to the required repositories. A connection that works for an ordinary cloud session is not sufficient evidence that project threads have the same access. Check the project’s repositories, cloud environment and required tools before assigning a pilot.
Can project threads run on your own computer?
Yes. Anthropic now documents local project threads through Remote Control, replacing the launch announcement’s cloud-only limitation. This needs Claude Code v2.1.280 or later on the computer and an explicit folder connection. A local thread runs only while that computer is awake and connected; other project threads can continue in the cloud.
The context differs: local threads start with project instructions but do not load project memory files. They use the local machine’s tools and settings. A task that depends on a remembered requirement therefore needs that requirement in the instructions or the local source the worker actually reads. Two workers sharing one folder can overwrite changes, so use separate worktrees for concurrent repository edits.
What are the limits to check before a pilot?
Projects draw on the same plan limits as other Claude Code sessions and can consume them faster through parallel work. Set the coordinator and thread models and effort deliberately, then measure the cost of retries and human review alongside delivery time.
The current documentation also says a project belongs to one user, with no project or thread sharing and no organisation-level project controls during the beta. Establish who will maintain the work and preserve the accepted changes in your own repository. A private project conversation should not become the only record of a business-critical decision.
Where can persistent agents help a business?
The strongest candidates are changes with separable work, maintained source code and an observable finish line. Examples include checking several pages for the same accessibility defect, updating API callers after an interface change or investigating a performance issue with a repeatable test.
Parallel work is less helpful when every task depends on a decision that has not been made. If nobody has agreed what a customer may cancel, splitting the cancellation feature across several agents will not resolve the policy. It may produce several incompatible interpretations faster.
Before selecting a tool, write down the work that currently causes delay. Is it repeatedly briefing developers, waiting for tests, finding previous decisions, obtaining approval or resolving conflicting changes? A memory feature addresses only some of those problems.
For an early assessment, choose a task whose output can be reviewed without giving the system unrestricted access to customer records or production administration. Our AI automation readiness checklist helps establish those boundaries before work begins.
An example: improve a quotation form without changing sales rules
Illustrative pilot, not a reported client result: a service company wants its existing quotation form to work more clearly on mobile devices. Email and phone must remain required, enquiries must keep reaching the current destination, and no new automated sales messages are authorised.
A project coordinator could organise separate tasks to inspect the current interface, propose changes and extend the tests. The developer responsible for the release would reconcile the resulting changes and review the full form journey.
The pilot brief should include:
- Current source: the exact production version or approved source revision, not an old local copy.
- Permitted change: improve labels, validation feedback and small-screen layout without changing the required fields or submission destination.
- Test evidence: show valid and invalid inputs, keyboard operation and failure handling using a test destination, not real customer enquiries.
- Dependency rule: agree the field contract before parallel implementation touches it.
- Release authority: a named person approves the combined change after testing; the coordinator cannot approve its own deployment.
- Recovery: retain a verified previous version and instructions for restoring it if the live check fails.
The pilot succeeds when the form works better and the existing enquiry process still works. It does not succeed merely because every thread reports completion.
Keep project memory separate from authority
A remembered instruction can be outdated, incomplete or drawn from the wrong context. Treat important decisions as versioned records with an owner and a source, even when the agent has its own memory.
A useful decision record contains the decision, its scope, who approved it, when it took effect and what replaces it. For example: “The quotation form requires both contact fields; changing that rule requires approval from the project owner.” That is clearer than an unexplained note saying “make the form shorter”.
Separate facts from proposals. A suggestion to remove a field should not become an approved requirement because it appeared in yesterday’s discussion. Likewise, an issue description or source-code comment is project material, not permission to expose credentials or deploy to production.
When requirements change, update the authoritative record and identify which active tasks are affected. Letting old and new instructions coexist silently is a predictable way to get plausible but incompatible work.
Measure accepted delivery, not generated output
Use the same task boundaries when comparing the pilot with your current process. Record enough information to distinguish speed from transferred effort:
- Time from an agreed brief to an accepted change.
- Human time spent reviewing, correcting and resolving conflicts.
- Whether the required tests passed on the combined version.
- Usage or direct cost, including failed attempts and rework.
- Defects found before release and during the agreed observation period afterwards.
- Whether another developer can understand and maintain the result.
Keep difficulty and scope visible. A small label change is not a fair comparison with a payment integration. Nor should a team claim that delivery time fell while excluding the person who spent the afternoon fixing generated work.
A promising result is less total effort for a change that meets the same quality requirements. The number of parallel threads, code lines or completed chat messages is not a substitute for that evidence.
Questions to ask your development supplier
Ask who owns the code, where work runs, which systems it can access and who is accountable for the release. Request a demonstration of the combined result against the agreed acceptance criteria, not a recording of the agent producing code.
Also ask how the supplier handles conflicting edits, stale memory, failed tests, usage limits and interrupted work. A credible answer should explain what stops, what is preserved and how someone resumes safely.
If the proposed workflow needs private business information, discuss the data-access questions raised by AI browser assistants. If it includes narrow routing or classification decisions, a structured decision model may suit that component better than another open-ended agent.
How we can help
Our website development service is a practical starting point for a bounded form or customer-journey improvement. Bring the current problem, the constraints that must stay and the result your team would accept. If the change affects sales follow-up, we can scope that through ConvertX, D4J’s CRM, with explicit rules and a named owner. Follow-up runs on those rules, not agent memory. Track closed deals and money received separately from form fills, and approve the combined change before release.
