Claude's 1M-token context window and Claude Projects can hold and search a large set of documents, but reading a portfolio and extracting consistent, audit-ready data from every document in it are different problems, and Projects is built to solve the first one, not the second.
Per Anthropic's documentation, a 1M-token context window is now the default — no beta header, no separate pricing tier — on Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5, Claude Sonnet 4.6, and several other current models, available through the Claude API, Amazon Bedrock, Google Cloud, and Microsoft Foundry. That is a real jump from the 200k-token window that other models, including Claude Sonnet 4.5, still use, and it is easy to hear "1 million tokens" and conclude a whole loan file, an entire rent roll, or a full lease portfolio can simply be dropped in and reasoned over at once.
For a single document, or a handful of them, that is often true. For a portfolio — the 300 leases behind an acquisition, the 500 loan files in a servicing transfer, the loss runs across fourteen carriers — the more relevant feature isn't the size of the context window. It's what Claude Projects does once your knowledge base is larger than that window, which is something other than "load it all in."
This is part of a series of articles about AI Build vs Buy.
What Claude's 1M-Token Context Window and Projects Do Well
Claude Projects gives a team a self-contained workspace with its own chat history, a knowledge base of uploaded documents, and custom instructions that shape how Claude responds inside that workspace — real, useful infrastructure for a team working repeatedly against the same body of documents.
A 1M-token context window, standard on current frontier models, can hold a complete lease with every amendment, a full loan file, or a lengthy offering memorandum without splitting it into chunks — genuinely useful for reading one complex document in full.
Project knowledge lets a team upload reference documents once — templates, policies, prior filings — instead of re-uploading them in every conversation.
Custom instructions persist across a project, so a team doesn't have to restate its extraction conventions or house style in every chat.
When a project's knowledge grows past the context window, Claude Projects automatically switches into a retrieval-augmented mode. Per Anthropic's documentation, this expands a project's effective capacity "up to 10x" and happens with no setup or configuration required.
What a Portfolio-Scale Document Workflow Needs That Projects Doesn't Include
A document workflow at portfolio scale needs every document processed and accounted for, not just the ones a search retrieves as relevant to a given question — and that distinction is where Projects' design and a production workflow's requirements diverge.
Anthropic's own documentation describes what happens once a project's knowledge exceeds the context window: Claude uses "a project knowledge search tool to retrieve relevant information from your uploaded documents" for a given query. That is a retrieval model built for answering a question against a knowledge base — it is not a batch process that guarantees every one of 400 leases gets read and produces a row of output.
There is no extraction schema in Projects — no defined field list, no enforced units, no required handling for a missing value. Each chat response is prose shaped by the custom instructions you've written, not a structured record.
Field-level citation, if you want it, has to be requested in the conversation. Nothing in Projects structurally binds an extracted value to the exact clause, page, or line it came from.
Anthropic's documentation on project management and sharing does not describe any version history for project knowledge or instructions — no record of when a reference document was replaced, or what the extraction instructions said on the date a given output was produced.
Visibility and sharing controls in Projects are set per project by the project's owner (public or private, "can view" or "can edit"). The documentation does not describe an organization-wide dashboard for auditing what's inside project knowledge bases across a team.
Context Rot Is a Real, Documented Constraint — Not a Reason to Distrust the Model
Anthropic's own documentation names the limit on "just load the whole portfolio": "as token count grows, accuracy and recall degrade, a phenomenon known as context rot," which is why the documentation frames curating what's in context as being just as important as how much space is available.
That caveat is about how much unfiltered content a single context window can usefully carry, and it is one more reason portfolio-scale work benefits from a system that processes documents individually against a defined schema — each lease, each loan file, each loss run handled on its own — rather than one that depends on either stuffing everything into a single window or trusting a search tool to surface the right passage out of thousands of pages for every question asked of it.
Who Owns the Extraction Logic, the Version History, and the Audit Trail
In a Projects-based deployment, your custom instructions are your extraction logic, and per Anthropic's documentation on managing projects, that logic lives inside a project with no built-in version history — if it changes, there is no record of what it said last month.
That has two consequences a team should plan for before scaling a Projects workspace into a production workflow. First, the instructions that encode your rent-roll conventions, your escalation-clause treatment, or your loan-review checklist become the most valuable and least governed asset in the workflow — reviewable by whoever has "can edit" access, with no change log tying a given output back to the exact instruction wording that produced it. Second, when a document format shifts or a model version changes, re-confirming that the instructions still produce correct output is work your team schedules and performs; nothing in the product does that verification for you.
Claude Projects Compared With a Purpose-Built Document Platform
Claude Projects and a purpose-built document platform split the same list of requirements differently, and the table below shows who ends up owning each one.
Requirement | Claude Projects (1M context + RAG) | Purpose-Built Platform |
|---|---|---|
Reads a single complex document in full | Yes, within the context window | Yes |
Knowledge base beyond context window | RAG retrieval for relevant content, per query | Every document processed on a defined schedule |
Guarantees every document in a batch is processed | Not by design — retrieval targets what's relevant to the question asked | Yes, by design |
Extraction schema enforced per field | You define it in prose instructions | Built with you, enforced on output |
Field-level citation to source location | Only if requested in the conversation | Enforced on every field |
Version history of knowledge and instructions | Not described in current documentation | Built in |
Org-wide audit visibility into knowledge content | Not described in current documentation | Built in |
Consistency of output structure across runs | Depends on prose instructions and the conversation | Enforced output structure |
Re-validation when the model version changes | Your team | Vendor benchmarks and validates before promotion |
Delivery into existing systems (Yardi, MRI, CRM) | Manual export from chat | Structured push into existing systems |
Who owns the accuracy of the outcome | Your team | Shared with the vendor |
When Claude Projects and the 1M-Token Context Window Are the Right Choice
Claude Projects and its long context window are the right tool for document work that is exploratory, occasional, or genuinely single-document in nature — several real situations fit that description well.
One-off deep analysis of a single complex document. An analyst reviewing one heavily amended lease or a lengthy credit agreement before a negotiation benefits directly from a context window large enough to hold the whole thing at once.
A small team's shared reference library. Uploading standard policies, prior filings, or house templates into a project's knowledge base so a team can ask questions against them, without re-explaining context in every chat, is exactly what Projects is built for.
Exploratory questions across a document set. "Does anything in this data room mention a co-tenancy clause?" is a retrieval question with one answer read by a person — a good fit for RAG-based search, since no downstream system depends on an exhaustive, structured result.
Low volume. Below a few hundred documents a year, the cost of building or buying schema, citation, and audit infrastructure usually exceeds what that infrastructure would save. A well-organized Claude Project is often the more economical choice at that volume.
The dividing line isn't how long or complex the documents are. It's whether the output has to be exhaustive, structurally consistent, and defensible months later — across every document in the set, not just the ones a search tool judged relevant to the last question asked.
How Kolena Works
Kolena is an AI document automation platform built for commercial real estate, lending, insurance, and financial services teams working through document sets at portfolio scale. Rather than asking a knowledge base questions one at a time, Kolena deploys AI agents that process every document in a set — leases, loan files, loss runs, rent rolls — against your specific rubric or extraction template, and return structured outputs with every field cited to its exact location in the source.
Kolena reads PDFs, scans, emails, spreadsheets, images, and audio or video, and pushes structured results into the systems teams already use, including Yardi, MRI, Salesforce, and Snowflake. Every run produces a full audit trail — not just what was extracted, but the specific clause, line, or figure that justified each value, along with which template and instructions were in force when it ran. Kolena is SOC 2 Type II certified, processes onshore, and does not train on customer data. Kolena also benchmarks leading models against real document tasks and routes each step to the best performer, so a model version change is validated before it reaches your workflow instead of becoming re-validation work your team has to schedule. One private equity customer uses Kolena this way for data-room due diligence and IC memo drafting across the large, mixed document sets that come with an acquisition — the same kind of portfolio-scale reading a long context window alone doesn't turn into structured, defensible output.
Where a 1M-token context window and Claude Projects are well suited to reading and querying documents one project at a time, Kolena is built for the portfolio: consistent, per-document, structured output across every file in the set, with the citation and version record a data room, a loan committee, or an auditor will eventually ask for.
