Claude Complete #05 — Context, Memory, Instructions and Projects: What Carries Forward?

AIYING • V1.0 REGULAR VIEW

CLAUDE COMPLETE • POST #05

Context, Memory, Instructions and Projects: What Carries Forward?

Understand what Claude can draw on—and keep important facts anchored to current evidence.

By Ravindra Dastikop

Yesterday, you explained a client engagement to Claude. Today, you open a new conversation and write: “Continue the proposal.”

What information will Claude have? Your earlier conversation? Uploaded documents? Saved preferences? The latest approved decision?

The answer depends on several features and their settings. Treating all of them as “memory” can create mistaken expectations.

The central distinction

Context is information available for the current work. Instructions guide behavior. Memory supports continuity. Projects organize a body of work. None guarantees that every relevant fact will be recalled or interpreted correctly.

1. A practical map

The following descriptions are simplified explanations. Specific behavior depends on the Claude environment and settings.

Element	Main role	Illustrative example
Current context	Information available for this task	The proposal and approval record supplied now
Account instructions	General guidance across conversations	Use plain English and distinguish facts from suggestions
Project instructions	Guidance for a particular project	Follow this engagement’s review procedure
Memory	Carry useful information between supported interactions	Your role and recurring working preferences
Past-chat search	Retrieve relevant earlier conversations	Find a previous discussion about the proposal
Projects	Organize related work and supporting material	A workspace for one client engagement

2. Context: what is available for the current work?

For this article, context means the information available to help Claude perform the current task: instructions, conversation material, relevant files and information retrieved through available tools.

Information existing somewhere in your account does not establish that it has been retrieved or used correctly for a particular answer.

In our fictional engagement: a previous draft used a six-week schedule. A later approval record specifies five weeks. Your current task should identify the governing record explicitly.

Use the supplied Approved_Decisions document to determine the delivery schedule. Identify the supporting section. Flag any conflict with the earlier proposal.

This provides a checkable basis for the revision.

3. Instructions: guidance about how to work

Anthropic distinguishes account-wide instructions from instructions that apply within a Project.

Account-level example: “Use plain English. Make assumptions explicit.”

Project-level example: “For this engagement, separate client requests from approved changes. Include a change log with revised proposal drafts.”

Keep general preferences broad enough to suit your wider work. Put engagement-specific procedures with the engagement. Give the immediate deliverable and any task-specific exception in the current request.

These placement suggestions are editorial guidance, not a claim about a universal instruction-priority hierarchy.

4. Memory: continuity that needs inspection

Memory can carry useful information between supported interactions. Past-chat search retrieves earlier discussions; it is a related but distinct capability.

Review and update remembered information when your circumstances or preferences change. For important commitments, consult the current source rather than relying on recall alone.

In our example: remembering that you are preparing a consulting proposal is helpful continuity. Establishing the approved fee requires the relevant approval evidence.

5. Projects: organize the engagement

Anthropic describes Projects as workspaces for related conversations, knowledge and instructions. Its current documentation also describes a new Projects beta rolling out in stages, so interfaces and behavior may differ between accounts.

For the fictional engagement, a practical workspace could contain:

• A short engagement brief.
• The original proposal, clearly marked as the baseline.
• Meeting notes and client requests.
• A dated approval record.
• Current drafts and an unresolved-questions list.

Organizing the files is only part of the work. Maintain clear status labels so a draft, a request and an approval remain distinguishable.

6. Project memory is not automatically isolated

Current documentation says Projects have their own memory, but account memory and project memory can interact. It provides a “Use account memory” setting for separating project memory.

Inspect the actual settings before assuming that a project name alone establishes an information boundary.

This is especially relevant when the same consultant works with several clients. A general preference may be reusable; a client’s confidential commercial terms need an appropriate scope and handling.

7. Cloud and local Cowork have different memory behavior

Anthropic currently documents shared memory between Chat and cloud-based Cowork. It says locally running Cowork sessions do not use that memory.

Consequently, “Claude remembered it in Chat” does not establish that the same information is available in every working environment. Supply essential task context where it is needed.

8. Turning off memory is not the same as deleting history

Current controls distinguish a chat with memory turned off from an incognito chat. The former can remain in conversation history; the latter is handled differently.

Also, deleting a conversation does not automatically remove memories derived from it. Review memory controls separately. Organization retention policies can affect these features.

Consult the current documentation before treating any setting as a complete deletion or confidentiality mechanism.

9. Keep a short engagement record

The following is a proposed working practice for our fictional case, rather than an official Claude feature.

Engagement: [name or identifier]

Current objective: [deliverable being prepared]

Approved decisions: [decision and source reference]

Superseded information: [what changed and why]

Open questions: [items awaiting a decision]

Latest reviewed output: [file and version]

Last verified: [date and reviewer]

Keep this record current and provide it when appropriate. It gives both you and Claude a concise reference that can be checked against the underlying documents.

10. A reusable continuation prompt

Continue work on [engagement/task].

Use the current engagement record and the documents
I identify for this task.

Before drafting:
- Identify the current objective.
- List the sources available to you.
- Identify the approved decisions relevant to this task.
- Flag conflicts, missing sources or potentially outdated information.

Use remembered context as background.
Verify material commitments against current source documents.
If the evidence is unavailable, mark the point unresolved.

Deliver:
[required output]

Review criteria:
[observable checks]

Asking Claude to list its sources helps reveal gaps. Inspect that list and the resulting output; the prompt itself does not prove that retrieval was complete.

11. Your practical accomplishment

1. Choose one ongoing, non-sensitive task.
2. Write down what you expect Claude to carry forward.
3. Classify each item as a preference, instruction, source fact or open decision.
4. Inspect the relevant account and Project settings.
5. Create a short current engagement record.
6. Start a fresh conversation and check which sources and decisions the response actually uses.

Your accomplishment is an inspected continuity setup and a current task record. Record what the trial reveals about your particular account and environment.

AIYING takeaway

Use continuity features to reduce repetition. Use current evidence to establish important facts. Inspect the settings that determine where information applies.

Continue with Claude Complete

• Previous: #04 — How to Give Claude a Clear Task
• Start here: #01 — A Map of the Claude Ecosystem
• Continue to #06 topic: Claude Cowork’s Five Levels — previously published companion article

Official sources

• Use Claude’s chat search and memory to build on previous context
• Understanding Claude’s personalization features
• What are Projects?

Disclaimer and fact-check scope

Core distinctions were checked against official Anthropic documentation on 15 November 2026. Memory and Projects are evolving, and account experiences may differ during staged rollouts.

This article focuses on Claude’s user-facing Chat and Project features, with a limited Cowork comparison. It does not describe every Claude Code or API memory mechanism.

The engagement record, continuation prompt and consulting scenario are illustrative AIYING guidance, not tested deployments or official Anthropic procedures. No exhaustive recall or automatic source verification is implied.

Check current account controls and organizational policies. Claude Complete is an independent AIYING educational series and is not affiliated with or endorsed by Anthropic.

AIYING — See differently. Generate possibilities. Accomplish what matters.

Ravindra Dastikop

Claude Complete #04 — How to Give Claude a Clear Task

AIYING • V1.0 REGULAR VIEW

CLAUDE COMPLETE • POST #04

How to Give Claude a Clear Task

Define the result, supply useful context and make success checkable.

By Ravindra Dastikop

You upload a proposal and ask Claude: “Improve this.”

The result is more polished. But what did you want improved? The language, the scope, the commercial terms or its alignment with the client’s latest feedback?

A fluent revision can still miss the task. Before adding more instructions, identify what a useful result would actually look like.

The central idea

A clear task tells Claude what to accomplish, what information to use, which boundaries matter and how the result will be judged. The amount of detail should fit the work.

1. A prompt is a working brief

A prompt is the instruction or request you give Claude. It can be a single sentence or a structured brief.

A simple task may need very little explanation:

Rewrite this paragraph in plain English for a first-year student. Preserve the technical meaning.

A task involving conflicting documents, financial commitments or external actions needs more context and clearer boundaries. Length alone is not a measure of prompt quality.

2. Six useful elements of a task brief

The following checklist is an AIYING synthesis. Use the elements that matter for the task.

Element	Question to answer
Outcome	What should be accomplished?
Context	Who is this for, and why is it needed?
Inputs	Which sources should inform the work?
Output	What form should the result take?
Boundaries	Which constraints, permissions and uncertainties matter?
Checks	What evidence would make the result acceptable?

3. Worked example: revise a client proposal

In our fictional consulting engagement, the original proposal contains a six-week delivery schedule. Meeting notes record a request for four weeks. An approved decision document confirms a five-week schedule with reduced scope.

“Update the proposal using the latest feedback” leaves an important question unanswered: which source establishes the commitment?

A clearer brief could read:

Task: Prepare a revised client proposal draft reflecting approved changes.

Context: I am the consultant preparing the draft for internal review before client submission.

Inputs: Use Original_Proposal, Meeting_Notes and Approved_Decisions. For changes explicitly covered by Approved_Decisions, use that document as the authority. Treat meeting requests without recorded approval as unresolved.

Outputs: Provide a revised proposal draft, a change log and a list of unresolved questions. In the change log, identify the supporting document and section for each material change.

Boundaries: Preserve original terms unless an approved change supersedes them. Flag contradictions within the approval record. Leave unsupported commercial decisions unresolved. Keep the original files unchanged and do not send the proposal.

Checks: Verify the scope, fee and delivery schedule against the approval record. Report missing evidence and any checks you could not complete.

This brief makes the desired result easier to assess. It does not guarantee that Claude will interpret every source correctly.

4. Define the evidence, not just the tone

Instructions such as “be professional” can help with presentation. They do not establish factual accuracy.

For source-based work, ask for evidence that a reviewer can inspect:

• The document and section supporting a material change.
• A clear distinction between source facts and suggestions.
• Conflicts or missing information that remain unresolved.
• A record of checks completed and checks still needed.

Then inspect the cited material yourself. A source reference can be incorrect or fail to support the associated claim.

5. Add an example when words leave room for interpretation

Anthropic recommends relevant examples to clarify expected behavior and output. For our fictional change log, one example might be:

Item	Original	Revised	Evidence
Delivery	Six weeks	Five weeks	Approved_Decisions, delivery section

This row is illustrative. If you include a fictional example in a real prompt, label it clearly so its values are not mistaken for facts about the engagement.

6. State what to do with uncertainty

“Ask questions if needed” leaves considerable discretion. Identify the gaps that would materially affect the result.

If missing information would change the scope, price or delivery commitment, list the question before finalizing that section. Complete supported sections and mark the unresolved ones clearly.

This lets useful work proceed while preserving decisions that require your attention.

7. Give feedback that points to the defect

If the result is wrong, identify the mismatch between the brief and the output.

The draft uses the four-week request from the meeting notes. The approved decision specifies five weeks. Correct the delivery section and check the remaining dates for the same error. Report any conflicts you find.

Specific feedback gives the next revision a clear target. Retain the original acceptance criteria when reviewing the correction.

8. Reusable task brief

TASK
Accomplish: [specific outcome]

CONTEXT
Audience and purpose: [who needs this and why]

INPUTS
Use: [documents, data or authorized sources]
Source priority, where relevant: [which source governs which decision]

OUTPUT
Return: [deliverables, structure and level of detail]

BOUNDARIES
Respect: [constraints and action permissions]
Handle missing information by: [clarification, flagging or stated assumptions]

CHECKS
The result is acceptable when: [observable criteria]
Provide: [supporting evidence and remaining limitations]

Shorten this brief for simple requests. Add detail where ambiguity would affect the result. A prompt cannot supply unavailable tools, grant technical permissions or replace enforced access controls.

9. Your practical accomplishment

1. Choose one task you expect to perform this week.
2. Write your usual request.
3. Revise it using the task brief.
4. Identify three observable acceptance criteria.
5. Try the revised request with non-sensitive sample material.
6. Check the output and record one remaining weakness.

Your accomplishment is a usable task brief and an inspected result. If you compare versions, record the model, inputs and conditions. A single comparison is an observation, rather than proof of a general improvement.

AIYING takeaway

Make the task clear enough to perform and the result clear enough to check.

Continue with Claude Complete

• Previous: #03 — Models, Plans and Usage Limits Explained
• Start here: #01 — A Map of the Claude Ecosystem
• Next planned post: #05 — Context, Memory, Instructions and Projects: What Carries Forward?

Official sources

• Anthropic — Prompting best practices
• Anthropic — Prompt engineering overview

Disclaimer and fact-check scope

General guidance on clear instructions, examples and success criteria was checked against official Anthropic documentation on 15 November 2026.

The six-element task brief, proposal scenario and sample prompts are AIYING educational interpretations. The scenario is fictional, and the prompts have not been presented as experimentally validated or guaranteed to improve every task.

Prompt behavior varies with the model, inputs, tools and environment. Review outputs appropriately. Prompt instructions are not a substitute for technical security controls or authorization.

Claude Complete is an independent AIYING series. It is not affiliated with or endorsed by Anthropic.

AIYING — See differently. Generate possibilities. Accomplish what matters.

Ravindra Dastikop

Claude Complete #03 — Models, Plans and Usage Limits Explained

AIYING • V1.0 REGULAR VIEW

CLAUDE COMPLETE • POST #03

Models, Plans and Usage Limits Explained

Understand what you are choosing, what your subscription provides and which limits affect your work.

By Ravindra Dastikop

You subscribe to Claude, select a model and begin working. Later, you encounter a usage limit. A developer then tells you that API usage has its own billing.

These experiences concern different parts of the system. Understanding the distinctions helps you make a better decision about access, capacity and cost.

Four questions to keep separate

• Model: Which model will handle the task?
• Plan: What access and allowance do I receive?
• Limits: What constrains this work?
• Billing: Which allowance or payment route applies?

1. Models: choose for the task

A model is the underlying AI system processing your inputs. Anthropic offers models with different capability, speed and pricing characteristics.

At the verification date, its current model overview lists Claude Fable 5.2, Opus 5.5, Sonnet 5.5 and Haiku 5.5. That list is a dated snapshot, not a permanent catalogue.

Availability in an application can differ from availability through the developer platform. Consult the current model selector and documentation for your environment.

In our fictional proposal engagement: extracting document dates and resolving contradictory scope instructions are different tasks. A useful model comparison would test whether each produces acceptable results on representative examples.

Record accuracy, omissions, response time and the review effort required. A more expensive model is worthwhile when its contribution justifies the additional cost for your work.

2. Plans: access and capacity

A subscription plan determines an access package. It can affect available features, model access, usage allowances and organizational capabilities.

At the verification date, Anthropic’s pricing page lists Free, Pro, Max and Ultra for individuals, alongside Team and Enterprise offerings.

Before choosing, check the current feature comparison and checkout details for your location. Prices, taxes, billing intervals and terms can differ or change.

In our example: someone occasionally revising one proposal has different requirements from a consulting team managing many engagements. Shared administration may matter as much as individual usage capacity.

3. Usage limits and conversation length are different

Limit	What it concerns	What to check
Usage allowance	Consumption over a period	Your account’s usage display and reset information
Conversation length	How much context one conversation can accommodate	The relevant product’s length and context guidance
API rate limits	The permitted pace of developer requests or token processing	Developer account limits and API documentation

Opening a new conversation does not replenish a used subscription allowance. Similarly, an available usage balance does not establish that an arbitrarily long conversation will fit.

Anthropic says usage depends on factors such as model choice, conversation length and complexity, features and effort settings. Subscription usage across its product surfaces can share an allowance.

Check the applicable rules rather than assuming every plan has identical reset periods. Current documentation, for example, describes a five-hour-limit exception for verified Ultra accounts, while weekly limits still apply.

4. Subscription allowance, usage credits and API credits

These terms deserve particular attention:

• Included subscription usage: the allowance associated with your plan.
• Usage credits: a separately charged, consumption-based way for eligible paid users to continue beyond included limits when enabled.
• API credits: credits for developer-platform consumption, subject to their terms.

Current documentation says Max and Ultra include monthly API credits. It also explicitly distinguishes those credits from usage credits: the monthly API credits do not pay for usage-credit consumption in Claude, Claude Code or Cowork.

Therefore, avoid both assumptions: that a subscription provides unlimited API use, or that subscriptions can never include API benefits. Inspect your plan’s current entitlements and billing route.

5. What are tokens?

Tokens are units used to represent information processed by a model. Text tokens can correspond to words, parts of words or punctuation. They are not a fixed word count.

Developer pricing commonly distinguishes input tokens from generated output tokens. Applicable tools and other services may introduce additional charges.

For a document workflow, estimate the whole job: reading inputs, producing drafts, checking results and handling retries. A single short demonstration may not represent the recurring cost.

6. Diagnose the problem before upgrading

Suppose the revised proposal contains an unsupported delivery promise. Before changing plans, ask:

1. Was the approved delivery date supplied?
2. Were conflicting documents clearly identified?
3. Did the instructions require unresolved commitments to be flagged?
4. Did the model misinterpret evidence despite adequate inputs?
5. Did an actual capacity or access restriction interrupt the work?

The answers point to different remedies: better inputs, clearer instructions, a model comparison, a workflow change, or additional access and capacity.

An upgrade can address a relevant entitlement or allowance. It does not establish that the proposal is correct.

7. Your practical accomplishment: a usage decision card

Use one real task to complete this card. No purchase is required.

Task and frequency: …

Required features and environment: …

Current plan and available models: …

Observed restriction or quality problem: …

Billing route and spending boundary: …

Acceptance criteria for the output: …

Evidence needed before changing my setup: …

AIYING takeaway

Choose the model for the task, the plan for the access and capacity, and the billing route for the way you work. Verify each separately.

Continue with Claude Complete

• Previous: #02 — Chat, Cowork and Code
• Start here: #01 — A Map of the Claude Ecosystem
• Next planned post: #04 — How to Give Claude a Clear Task

Official sources

• Claude models overview
• Claude plans and pricing
• How usage and length limits work
• Manage usage credits for paid Claude plans
• Claude Platform pricing
• Claude API rate limits

Disclaimer and fact-check scope

Core model, plan and usage distinctions were checked against official documentation on 15 November 2026. Product names and entitlements are dated snapshots. This article is not an exhaustive pricing or feature matrix.

Prices, allowances, included credits and eligibility can change. Confirm current account terms, local checkout details and developer billing before purchasing or enabling additional usage.

The proposal scenario and decision card are illustrative, not tested results or official Anthropic procedures.

Claude Complete is an independent AIYING educational series. It is not affiliated with or endorsed by Anthropic.

AIYING — See differently. Generate possibilities. Accomplish what matters.

Ravindra Dastikop

Claude Complete #02 — Chat, Cowork and Code: Which Should You Use?

AIYING • V1.0 REGULAR VIEW

CLAUDE COMPLETE • POST #02

Claude Chat, Cowork and Code: Which Should You Use?

Choose a working environment by the task, the access it needs and the result you expect.

By Ravindra Dastikop

You need to revise a client proposal. Should you discuss it in Claude Chat, hand the document work to Cowork, or use Claude Code?

Each can contribute to useful work. The choice becomes clearer when you specify what you want to happen.

Are you exploring what to change? Preparing deliverables from several files? Or building software that will handle this process repeatedly?

The starting distinction

Chat is oriented toward conversational work. Cowork is oriented toward knowledge work across files and tools. Claude Code is oriented toward working with software projects. These are overlapping orientations, not rigid boundaries.

1. A comparison at a glance

Environment	Typical orientation	Illustrative result
Chat	Discuss, draft, research and analyze	A reasoned proposal revision plan
Cowork	Carry out knowledge-work tasks involving files and tools	A revised draft and change log
Claude Code	Read, modify and test a software project	A tested proposal-review application

This table illustrates where to begin. It does not establish exclusive capabilities or guarantee successful results.

2. Chat: work through the question together

Claude Chat provides a conversational setting for drafting, research and analysis.

In our fictional engagement: the client wants a shorter delivery timeline, but the meeting notes do not clearly establish whether the scope has changed.

Before revising the offer, you want help identifying the ambiguity.

Read the supplied proposal and meeting notes. Separate confirmed decisions, requested changes and unresolved questions. Explain which points need clarification before I revise the offer.

You review the response, challenge an interpretation and ask for a clearer explanation. The conversation helps you refine your judgment.

Choose this starting point when: discussion and iterative clarification are central to the work.

You can still request concrete outputs in Chat. “Conversational” describes the working approach, rather than a restriction to answering questions.

3. Cowork: specify a bounded piece of work

Cowork supports knowledge work involving local files and connected tools, including tasks that produce documents, spreadsheets and presentations.

In our fictional engagement: the approved decisions are now clear. You want a revised proposal and a record of changes prepared from the source material.

Using the files I authorize for this task, prepare a revised proposal draft and a change log. Apply approved decisions only. Flag conflicts and missing information. Save the outputs separately from the originals. Do not send anything to the client.

This request defines the inputs, outputs and action boundary. You would then check whether the revised draft reflects the approved scope, fees and delivery commitments.

Choose this starting point when: the main need is to carry out a defined task across files or supported tools.

A useful handoff includes what to do when information is missing. “Flag the gap” is often more appropriate than allowing an unsupported assumption to become a commercial commitment.

4. Claude Code: work on the software itself

Claude Code can inspect a codebase, edit files and run commands. Its documentation describes access through terminal, IDE, desktop and browser environments.

In our fictional engagement: you now want a small application that helps reviewers classify proposal changes and track unresolved decisions.

Inspect this project and propose a small implementation plan. Add a review screen that classifies proposal changes as approved, requested or unresolved. Add tests for the classification logic. Summarize the changes and any remaining limitations.

The intended result is a change to a software project, supported by appropriate validation.

Choose this starting point when: the work involves building, debugging, modifying or testing software in its development environment.

In this example, reviewers would need to establish whether the application handles ambiguous or conflicting evidence correctly. A successful demonstration alone would not establish that.

5. The same task can change environments

The proposal example illustrates three different needs:

1. Clarify: identify what the client actually approved.
2. Produce: prepare reviewed documents from those decisions.
3. Build: develop software to support a recurring process.

These are possible stages of work, not a required progression. A single proposal may need only a focused conversation and careful review. Building an application becomes worthwhile only when there is a real recurring need.

6. Four questions that make the choice easier

What needs to change?

Your understanding, a set of work products, or a software system? Name the desired result before choosing the environment.

Where are the inputs?

Are you supplying a few documents, working in an authorized folder, retrieving material from connected services, or operating in a repository?

Which actions are necessary?

Reading, drafting, editing files and running commands are different operations. Identify the access needed for this task.

How will you check success?

A useful explanation needs evidence and sound reasoning. A revised proposal needs source checks and commercial review. Software changes need validation appropriate to their behavior.

7. Common misunderstandings

• “Cowork is simply a stronger model.” The distinction discussed here is the working environment and its capabilities. Model selection is a separate topic.
• “Chat cannot produce deliverables.” Conversational work can include concrete outputs; capabilities overlap across environments.
• “Claude Code is limited to a terminal.” Current documentation describes several supported surfaces.
• “A completed task must be correct.” Completion and correctness need separate checks.

8. Your practical accomplishment

Choose one task and complete this short decision note:

The result I need is: …

The inputs are located in: …

The actions required are: …

My starting environment will be: …

I chose it because: …

I will check the result by: …

Your accomplishment is a justified starting choice. You can revise that choice as you learn more about the task.

AIYING takeaway

Choose the environment that fits the work, the access it requires and the result you can verify.

Continue with Claude Complete

• Previous: #01 — A Map of the Claude Ecosystem
• Next planned post: #03 — Claude Models, Plans and Usage Limits Explained
• Related: Claude Cowork’s Five Levels
• Related: Projects, Skills, Connectors and Plugins

Official sources

• Anthropic — Claude Cowork product guide: Product overview
• Claude Code documentation — Overview

Disclaimer and fact-check scope

This independent educational article explains the main working orientations of Claude Chat, Cowork and Code. Core distinctions were checked against the official sources above on 15 November 2026.

The consulting engagement, prompts and selection questions are illustrative. They are not tested implementations or official Anthropic procedures. The comparison is not an exhaustive capability matrix.

Features overlap and evolve. Availability, permissions, execution behavior and limits vary by plan, platform and organization settings. Confirm current support before implementing a workflow.

Review outputs and actions according to the task’s consequences. Claude Complete is an independent AIYING series and is not affiliated with or endorsed by Anthropic.

AIYING — See differently. Generate possibilities. Accomplish what matters.

Ravindra Dastikop

Claude Complete #01 — Start Here: A Map of the Claude Ecosystem

AIYING • V1.0 REGULAR VIEW

CLAUDE COMPLETE • POST #01

Start Here: A Map of the Claude Ecosystem

Understand the tools. Choose the right approach. Accomplish useful work.

By Ravindra Dastikop

Someone recommends Claude. Another person recommends Claude Cowork. A developer mentions Claude Code. A tutorial discusses Skills, Connectors, Plugins and the API.

Are these different AI models? Separate applications? Features inside the same product? And where should you begin?

The first useful step is to separate the categories. A model, a workspace, a connection and a subscription each answer a different question.

Welcome to Claude Complete

This independent AIYING series provides a practical, evolving guide to the Claude ecosystem. We begin with the main categories, then explore individual tools, workflows and limitations in focused posts.

1. Start with six questions

The following map is an editorial aid. It helps organize the ecosystem; it is not an official Anthropic classification.

Category	Question	Examples
Models	Which underlying model handles the task?	Model families and versions offered by Anthropic
Working environments	Where and how will I work?	Chat, Cowork, Claude Code
Context and methods	What background and instructions should apply?	Projects, memory, instructions, Skills
Tools and packages	What can Claude access or use?	Connectors, Plugins and supported integrations
Developer platform	How can I build an application with Claude?	APIs, SDKs and agent infrastructure
Access and administration	What is available, permitted and billed?	Plans, limits, permissions and organization settings

2. Models: the underlying capability

Claude is Anthropic’s AI offering, supported by a changing collection of models. A model processes the information supplied to it and generates responses or requests to use available tools.

Models can differ in capability, speed, cost and supported features. Check the current model documentation when making a selection.

A useful distinction: selecting a model and choosing a working environment are separate decisions. Tool access and permissions also shape what a particular setup can accomplish.

3. Chat, Cowork and Code: three important ways to work

Anthropic distinguishes conversational work, cross-application knowledge work and repository-based engineering in its product guidance.

Environment	Main orientation	Illustrative task
Chat	Conversational drafting, research and analysis	Discuss a client brief and draft a response
Cowork	Knowledge work involving files and multiple tools	Compare proposal documents and prepare revised deliverables
Claude Code	Building, modifying and testing software in a codebase	Build and test a proposal-review application

These orientations help you choose a starting point. Their capabilities overlap, and the boundaries evolve as products change.

4. Context and methods: make the work specific

Features such as Projects, memory, instructions and Skills help organize context or guide recurring work. They have different scopes and behavior.

In later posts, we will examine where information persists, which instructions apply, and how to capture a reusable task method. For now, distinguish two needs:

• Case information: facts about this client or task.
• Working method: how you want this kind of task performed.

A client’s approved delivery date is case information. A rule to flag unsupported delivery commitments is part of a method.

5. Connections and packages: extend the working setup

Connectors provide access to supported external services. Plugins can package related capabilities for a role or workflow. Availability and behavior depend on the product surface and configuration.

These features raise a practical question: does the task require external access, or can you complete it with material you supply directly?

In the fictional proposal engagement, you could begin with a few supplied documents. A connection may become useful when locating authorized source material repeatedly becomes part of the work.

Explore the distinctions in our companion guide: Claude Projects, Skills, Connectors and Plugins: What Does Each Actually Do?

6. Developer platform: build Claude into an application

The developer platform serves people building software with Claude. Anthropic documents direct model access through its Messages API and managed infrastructure for agent-based work.

An API-based application introduces engineering responsibilities: authentication, input handling, tool execution, errors, evaluation and usage costs.

In our fictional engagement: a developer might build a proposal-review application that accepts documents, flags unresolved changes and presents findings for human review.

That would require an implemented and tested workflow. Describing the application in a prompt does not establish that the system is reliable or ready for deployment.

7. Plans, permissions and controls: establish the boundaries

Access is another part of the map. Before adopting a workflow, check the relevant plan, usage limits, supported environment and organization settings.

Also establish what Claude may read, modify or send. Producing a draft proposal and sending a commercial offer are different actions with different consequences.

For the worked examples in this series, we will make the intended output and review boundary explicit.

8. One engagement across the ecosystem

Throughout Claude Complete, we will revisit a fictional consulting engagement: turning an original proposal, client feedback and approved decisions into a reviewed revised offer.

This example will let us explore conversation, document work, reusable methods, connected sources and application development without changing the underlying business problem.

It will also keep a central distinction visible: a requested change, an approved decision and a generated suggestion are different kinds of information.

9. Your first accomplishment: write a task card

Choose one real task and complete the following. You do not need to install anything to do this exercise.

My task: What am I trying to accomplish?

My inputs: Which information or files are required?

My output: What useful result should I receive?

My environment: Where would this work fit best?

My permissions: What access or actions are necessary?

My checks: How will I judge the result?

Your accomplishment is a clearer specification for one task. That gives you a sound basis for choosing tools.

AIYING takeaway

Begin with the work you want to accomplish. Then choose the model, environment, context, tools and controls that the task requires.

Continue with Claude Complete

• Next planned post: Claude Chat, Cowork and Code: Which Should You Use?
• Read: Claude Cowork’s Five Levels
• Read: Projects, Skills, Connectors and Plugins

Official sources

• Claude product overview
• Claude Cowork product guide — Product overview
• Claude Platform documentation — Introduction

Disclaimer and fact-check scope

Claude Complete is an independent AIYING educational series, not an official Anthropic course or certification. This introductory map covers major categories; it is not an exhaustive inventory of every product, preview or feature.

Core product distinctions were checked against the official sources above on 15 November 2026. The six-category map, task card and consulting engagement are explanatory devices created for this series. The engagement is fictional and is not a tested deployment.

Models, interfaces, plans, integrations and capabilities change. Availability varies by account, platform, region and organization settings. Check current documentation before implementing a workflow.

AI-generated outputs require review appropriate to the task. AIYING and this article are not affiliated with or endorsed by Anthropic.

AIYING — See differently. Generate possibilities. Accomplish what matters.

Ravindra Dastikop