Copilot Spaces, Agentic Memory and Repository Indexing
One of the most critical factors that determines the quality of an AI assistant's responses is context. The more a language model understands your project, your conventions and your goals, the better the suggestions it produces. Until recently, providing context to Copilot required manual effort: opening relevant files, writing detailed prompts, repeating information already provided in previous sessions.
With the introduction of Copilot Spaces, Agentic Memory and improvements to Repository Indexing, GitHub has addressed this problem structurally. These three tools work in synergy to ensure that Copilot always has the right context at the right time, drastically reducing the need to repeat information and improving response consistency over time.
In this fourteenth article of the series, we will explore each of these tools in detail: how they work, how to configure them and how to use them to maximize productivity in daily work.
Complete Series Overview
| # | Article | Focus |
|---|---|---|
| 1 | Foundation and Mindset | Setup and mindset |
| 2 | Ideation and Requirements | From idea to MVP |
| 3 | Backend Architecture | API and database |
| 4 | Frontend Structure | UI and components |
| 5 | Prompt Engineering | Prompts and MCP Agents |
| 6 | Testing and Quality | Unit, integration, E2E |
| 7 | Documentation | README, API docs, ADR |
| 8 | Deploy and DevOps | Docker, CI/CD |
| 9 | Evolution | Scalability and maintenance |
| 10 | Coding Agent | Autonomous development agent |
| 11 | Code Review | Automatic AI review |
| 12 | Copilot Edits and Agent Mode | Multi-file editing |
| 13 | GitHub Spark | Apps from natural language |
| 14 | You are here → Copilot Spaces and Memory | Organized context and memory |
| 15 | AI Models | Guide to model selection |
| 16 | Customization | Custom instructions and knowledge |
| 17 | Enterprise and Business | Copilot for organizations |
| 18 | Extensions and Marketplace | Extending Copilot with tools |
| 19 | Security | Security and AI compliance |
Copilot Spaces: Organizing Context for Focused Conversations
Copilot Spaces is a feature that allows you to create organized collections of context for conversations with Copilot. A Space is essentially a container where you can include different types of information relevant to a specific task, project or work area. Instead of having to explain to Copilot every time what you are working on, you create a Space once and reuse it for all conversations related to that context.
What You Can Include in a Space
The strength of Spaces lies in the flexibility of the supported content types. You are not limited to code alone: you can include any information useful to give Copilot the necessary context.
Supported Content Types
| Type | Description | Usage Example |
|---|---|---|
| Repository | Entire GitHub repositories or specific folders | Include the main project repo |
| Code files | Individual files or code selections | The data model, main APIs, config files |
| Pull Request | Open or closed PRs with diffs and comments | Recent PRs to understand latest changes |
| Issue | GitHub Issues with discussions | Open bugs, feature requests, architectural decisions |
| Free text | Notes, instructions, context in text format | Team conventions, business rules, requirements |
| Images | Screenshots, diagrams, wireframes | Reference designs, architectural diagrams |
| Uploaded files | Documents, PDFs, configuration files | Technical specifications, requirements documents |
Smart Loading: Intelligent Context
A fundamental aspect of Spaces is the Smart Loading mechanism. When you include a repository in a Space, Copilot does not load the entire repository contents into the conversation context. This would be impossible for large repositories and inefficient even for small ones.
Instead, Smart Loading works similarly to a semantic search engine: when you ask a question, Copilot dynamically searches and retrieves only the files and code sections relevant to your specific request. This approach offers the best of both worlds: you have access to the entire repository as a context source, but only the relevant parts occupy the model's context window.
How Smart Loading Works
- Indexing: When you add a repository to the Space, it gets indexed for semantic search
- Query: When you ask a question, Copilot analyzes the intent and identifies relevant topics
- Retrieval: Relevant files and sections are retrieved from the index
- Ranking: Results are sorted by relevance
- Context Assembly: Only the most relevant fragments are included in the prompt to the model
- Response: The model generates the response with precise and pertinent context
Creating and Managing Spaces
Creating a Space is done through GitHub's web interface or directly from the IDE. The process is simple and intuitive.
Creating a Space for a Project
SPACE: "E-commerce Backend"
INCLUDED REPOSITORIES:
- org/ecommerce-api (main repository)
- org/shared-libs (shared libraries)
- org/ecommerce-docs (documentation)
SPECIFIC FILES:
- ecommerce-api/src/models/*.ts (all data models)
- ecommerce-api/prisma/schema.prisma (database schema)
- ecommerce-api/.copilot-instructions.md (project conventions)
- ecommerce-api/docs/architecture.md (architectural decisions)
INCLUDED ISSUES:
- #234: "Migrate to Event-Driven Architecture" (under discussion)
- #267: "Performance degradation on product search" (critical bug)
FREE TEXT:
"This project uses NestJS with Prisma ORM. The database is PostgreSQL.
Authentication is based on JWT with refresh token.
APIs follow the CQRS pattern with event sourcing for orders.
We use the Repository pattern for data access.
Tests follow the pyramid: 70% unit, 20% integration, 10% E2E.
Deployment happens via GitHub Actions on AWS ECS."Use Cases for Spaces
Spaces is particularly useful in scenarios where the context is complex, distributed across multiple repositories, or where different team members work on different aspects of the same project.
Common Use Scenarios
| Scenario | Recommended Space | Contents to Include |
|---|---|---|
| Multi-repo project | One Space per project | All repos, shared schema, architectural docs |
| New member onboarding | "Onboarding [Project]" | README, setup guides, ADR, conventions, FAQ |
| Bug investigation | "Debug [Feature]" | Involved files, issues, logs, stack traces |
| Feature development | "Feature [Name]" | Spec, wireframes, files to modify, existing tests |
| Cross-team collaboration | "Integration [Team A + B]" | API contracts, shared schemas, agreement documents |
| Migration project | "Migration [Legacy → New]" | Legacy code, new target, mapping, migration plan |
| Code review preparation | "Review [PR #xxx]" | PR, tests, related documentation, team standards |
Best Practices for Spaces
Do
- Create context-specific Spaces (not one generic Space for everything)
- Always include project conventions (.copilot-instructions.md file)
- Update the Space when the project evolves
- Add free text for information not present in the code
- Share Spaces with team members
- Include both code and related documentation
- Use different Spaces for different phases (development, debug, review)
Don't
- Don't include too many irrelevant repositories (noise in the context)
- Don't create a single Space for all your work
- Don't forget to update the Space after significant changes
- Don't include binary files or large assets
- Don't neglect free text: it's often the most valuable context
- Don't share Spaces with sensitive content without verifying permissions
- Don't overload a Space with dozens of barely relevant issues
Agentic Memory: Persistent Memory for Copilot
Agentic Memory is one of the most revolutionary features introduced in Copilot, currently available in Early Access for users on Pro and Pro+ plans. It is a persistent memory system that allows Copilot to remember information learned during previous interactions, eliminating the need to repeat the same explanations in every new chat session.
How Memory Works
Agentic Memory works through a process of automatic deduction. During conversations with Copilot, the system identifies information that could be useful in the future and saves it as "memories". These memories are not exact copies of conversations, but structured summaries of key information deduced from the interaction.
Memory Lifecycle
- Deduction: During a conversation, Copilot identifies potentially useful information
- Creation: The information is synthesized and saved as a structured memory
- Association: The memory is associated with the specific repository where it was created
- Usage: In subsequent conversations in the same repository, the memory is used as context
- Validation: Each time the memory is used successfully, its lifetime is extended
- Expiration: Unused memories automatically expire after 28 days
Types of Memories
The system does not memorize everything indiscriminately. Memories are categorized and filtered by relevance, focusing on information that has high reuse value.
Memory Categories
| Category | Examples | Value |
|---|---|---|
| Project structure | Folder organization, architecture, main modules | Avoids re-explaining how the code is organized |
| Coding conventions | Naming style, patterns used, linting rules | Generates code consistent with team standards |
| Recurring patterns | How to create new endpoints, how to write tests, how to handle errors | Reproduces approved patterns without requiring instructions |
| Technical decisions | Why a specific library is used, architectural trade-offs | Suggests solutions aligned with team choices |
| Domain information | Business rules, specific terminology, regulatory constraints | Understands the domain without repeated explanations |
| Personal preferences | Comment style, detail level, response format | Customizes responses based on preferences |
Persistence and Expiration
Memories have a well-defined lifecycle, designed to balance usefulness and relevance over time.
Persistence Rules
| Rule | Detail |
|---|---|
| Initial duration | 28 days from creation |
| Renewal | Each usage resets the 28-day timer |
| Expiration | Auto-deletion after 28 days of inactivity |
| Scope | Repository-specific memories (not global) |
| Compaction | At 95% of the token limit, least relevant memories are compacted |
| Privacy | Memories are not shared between users or repositories |
| Deletion | The user can manually delete any memory |
| Visibility | The user can view all active memories |
Repository-Specific Scope
A fundamental aspect of Agentic Memory is that memories are repository-specific. Information learned while working on repository A is not used when working on repository B. This design ensures that context is always pertinent and prevents contamination between different projects.
This design choice has important implications: project A's conventions will not influence suggestions for project B, even if you use the same Copilot account. Each repository has its own independent "brain" that grows and enriches itself only through interactions specific to that repository.
Implications of Repository Scope
- Monorepo: In a monorepo, all memories are shared across modules (be careful with different conventions between modules)
- Fork: Forks are separate repositories, so memories are not transferred
- Rename: Renaming the repository preserves memories (the internal ID remains the same)
- Multi-repo: You need to build separate memories for each repository, even if they are part of the same project
- Transfer: Transferring a repository to another organization preserves memories
Auto-Compaction
When the volume of memories reaches 95% of the maximum token limit allocated, the system activates an auto-compaction process. Memories are evaluated based on usage frequency, recency and relevance. The least used memories are condensed or removed to make room for new information.
This mechanism ensures that Copilot's "brain" for each repository stays focused on the most useful information, without accumulating information debris that could degrade response quality. It is an automatic process that does not require user intervention, although it is possible to manage memories manually if needed.
Practical Benefits of Agentic Memory
Before and After Agentic Memory
| Scenario | Without Memory | With Memory |
|---|---|---|
| New chat session | You need to re-explain project structure and conventions | Copilot already knows how the project is organized |
| Creating new endpoint | You need to specify pattern, middleware, validation | Copilot reproduces the pattern of existing endpoints |
| Bug resolution | You need to describe how the involved system works | Copilot knows the architecture and suggests where to look |
| Code review | You need to explain team rules | Copilot automatically applies team conventions |
| Refactoring | You need to define the target architecture | Copilot knows the architectural preferences |
| Testing | You need to specify framework, style, coverage target | Copilot generates tests consistent with existing ones |
| Documentation | You need to indicate format, style, conventions | Copilot produces docs aligned with the rest of the project |
Manual Memory Management
Although the system is designed to be automatic, users have full control over stored memories. You can:
- View: Access the complete list of memories for each repository
- Edit: Correct inaccurate memories or add details
- Delete: Remove obsolete or incorrect memories
- Force creation: You can explicitly ask Copilot to remember something
// In the Copilot chat, you can say:
"Remember that in this project we always use
the Result<T, E> pattern for error handling
instead of throwing exceptions. Every service must
return Result<SuccessType, ErrorType>."
"Remember that database migrations should always
be created with the command: npx prisma migrate dev --name <descriptive-name>"
"Remember that our branch naming convention is:
feature/JIRA-XXX-brief-description
fix/JIRA-XXX-brief-description
chore/JIRA-XXX-brief-description"
"Remember that integration tests must use
the test database (TEST_DATABASE_URL) and not the
development database."Repository Indexing: Instant Semantic Search
Repository Indexing is the engine that powers Copilot's deep understanding of code. When a repository is indexed, Copilot creates a semantic representation of the code that allows it to understand not only the file structure, but also the logical relationships between components, the dependencies between modules and the data flow through the system.
Automatic Indexing
Indexing happens automatically the first time a user starts a Copilot Chat conversation in a repository. No configuration or manual action is required. Once indexing is complete, all Copilot users accessing that repository benefit from the shared index.
Indexing Details
| Aspect | Detail |
|---|---|
| Trigger | Automatic on first Copilot conversation in the repository |
| Speed | Under 60 seconds for most repositories |
| Update | Incremental on each push (only modified files) |
| Sharing | The index is shared among all Copilot users of the repository |
| Privacy | The index is not used to train AI models |
| Size | Supports repositories up to millions of lines of code |
| Languages | All languages supported by GitHub |
| Branch | Indexing covers the default branch (main/master) |
What Gets Indexed
Indexing goes well beyond a simple text search index. The system creates a semantic understanding of the code that includes:
Indexing Levels
| Level | What It Analyzes | Benefit |
|---|---|---|
| File structure | Folder organization, naming conventions, project patterns | Copilot understands where to look for each type of resource |
| Definitions | Classes, interfaces, functions, types, constants | Precise suggestions for types and method signatures |
| Relationships | Import/export, inheritance, composition, dependencies | Understands the impact of changes on other files |
| Patterns | Recurring architectural patterns, coding conventions | Generates code consistent with existing patterns |
| Logic | Data flow, error handling, transformations | Suggests implementations that integrate with existing logic |
| Documentation | Comments, JSDoc, README, markdown | Uses documentation to understand code intent |
| Tests | Test cases, assertions, mocks, fixtures | Generates tests consistent with the project's testing strategy |
| Configuration | Config files, environment, build settings | Understands the project's environment and dependencies |
Indexing Speed
One of the most significant innovations is the reduction of indexing time to under 60 seconds. In previous versions, indexing could take minutes or even hours for large repositories. Today, thanks to optimizations in the embedding algorithm and indexing infrastructure, semantic search is available almost instantly.
After the initial indexing, updates are incremental: when you push new commits, only the modified files are re-indexed, keeping the index always up to date without requiring a complete re-indexing.
Impact on Response Quality
Repository Indexing has a direct and measurable impact on the quality of Copilot's responses. Without indexing, Copilot can only see the files currently open in the editor. With indexing, it has access to the entire codebase.
Impact Example
| Question | Without Indexing | With Indexing |
|---|---|---|
| "How does the project handle authentication?" | Generic response based on best practices | Specific response describing the JWT middleware, auth service and guards |
| "Create a new endpoint for payments" | Generic endpoint without context | Endpoint following project patterns, with consistent middleware, validation and errors |
| "Why is test X failing?" | Analysis limited to the test file | Analysis that includes the service under test, dependencies and required mocks |
| "Which files do I need to modify to add a field to the User model?" | Only the model file | Model, migration, DTO, validation, serializer, test, docs |
Enterprise Controls
For organizations, Repository Indexing offers granular controls to manage which content gets indexed and which is excluded. This is particularly important for repositories containing sensitive code or proprietary information.
# Files and folders to exclude from Copilot indexing
# Similar to .gitignore but specific to Copilot
# Secrets and credentials
.env
.env.*
**/secrets/
**/credentials/
**/*.pem
**/*.key
# Sensitive data
**/fixtures/customers.json
**/seed/production-data.sql
# Proprietary code
src/core/proprietary-algorithm/
src/core/patent-pending/
# Generated files (noise in indexing)
dist/
build/
node_modules/
coverage/
*.min.js
*.bundle.js
# Vendor code
vendor/
third-party/
# Large files (not useful for context)
**/*.csv
**/*.sql.gz
**/*.dumpSynergy Between Spaces, Memory and Indexing
The true power of these three tools emerges when they work together. Each one covers a different aspect of the context problem, and together they provide Copilot with a complete and persistent understanding of the project.
How the Three Systems Collaborate
| Tool | Context Type | Persistence | Scope |
|---|---|---|---|
| Repository Indexing | Code structure and relationships | Permanent (incremental update) | Entire repository |
| Copilot Spaces | Multi-source context curated by user | Persistent (managed by user) | Multi-repository |
| Agentic Memory | Knowledge deduced from interactions | 28 days (renewable) | Specific repository |
In practice, when you ask Copilot a question:
- Repository Indexing retrieves the relevant files and code structures
- Spaces adds additional context (issues, PRs, documentation, notes)
- Agentic Memory applies conventions and preferences learned in previous sessions
- All these contexts are combined and sent to the model to generate the response
Practical Examples
Let's see how these tools apply in daily work scenarios.
Example 1: Space Setup for Multi-Repo Project
PROJECT: E-commerce platform with 5 microservices
REPOSITORIES:
1. ecommerce-gateway (API Gateway - Node.js)
2. ecommerce-products (Product catalog - Python/FastAPI)
3. ecommerce-orders (Order management - Java/Spring Boot)
4. ecommerce-payments (Payments - Go)
5. ecommerce-notifications (Notifications - Node.js)
RECOMMENDED SPACE: "E-commerce Platform"
CONTENTS:
- All 5 repositories
- proto/ files with shared gRPC definitions
- OpenAPI files for each service
- Architecture document (C4 model)
- ADR (Architecture Decision Records)
- Team notes: "The payments team is external,
communication via Slack #payments-integration"
RESULT:
When you ask "How does the checkout flow work?",
Copilot can trace the flow across all services:
Gateway -> Products (check availability)
-> Orders (create order)
-> Payments (process payment)
-> Notifications (send confirmation)Example 2: Using Memory for Conventions
SESSION 1 (Day 1):
Developer: "Create a new service for invoice management"
Copilot generates the service following generic patterns.
Developer: "No, in our project services always follow
this pattern: InvoiceService extends BaseService<Invoice>
with methods findById, findAll, create, update, delete.
We also use the @Injectable() decorator and the
Result<T, E> pattern for errors."
Copilot generates the correct version.
>> MEMORY CREATED: "Services follow the
BaseService<T> pattern with @Injectable() decorator and Result<T,E>"
SESSION 2 (Day 5):
Developer: "Create a service to manage customers"
Copilot automatically generates:
- CustomerService extends BaseService<Customer>
- @Injectable() decorator
- All CRUD methods with Result<T, E>
- Error handling consistent with InvoiceService
>> NO ADDITIONAL INSTRUCTIONS NEEDEDExample 3: Repository Indexing for Code Exploration
CONTEXT: New developer on the project (50K lines of code)
QUESTIONS AND ANSWERS (with Repository Indexing):
Q: "How is the project structured?"
A: The project follows a Clean Architecture with 4 layers:
- src/domain/ (entities and business rules)
- src/application/ (use cases)
- src/infrastructure/ (database, external APIs)
- src/presentation/ (controllers, DTOs, middleware)
[cites specific files and folders]
Q: "How does authentication work?"
A: Authentication uses JWT with refresh token:
- src/infrastructure/auth/jwt.strategy.ts (validation)
- src/infrastructure/auth/auth.guard.ts (route protection)
- src/application/auth/auth.service.ts (login logic)
[shows the flow with references to actual code]
Q: "Where should I put a new endpoint for reports?"
A: Based on the project structure:
- Controller: src/presentation/controllers/report.controller.ts
- Service: src/application/services/report.service.ts
- Repository: src/infrastructure/repositories/report.repository.ts
- DTO: src/presentation/dto/report.dto.ts
- Test: test/unit/report.service.spec.ts
[follows exactly the pattern of other endpoints]Advanced Configuration
To get the most out of these tools, it is important to configure them correctly based on the needs of the project and team.
.copilot-instructions.md File
The .copilot-instructions.md file in the repository root is
automatically included in the context of every Copilot conversation. It is the most
direct way to provide persistent instructions to Copilot for a specific repository.
# Instructions for Copilot
## Technology Stack
- Backend: NestJS 10 with TypeScript 5.3
- Database: PostgreSQL 16 with Prisma 5
- Cache: Redis 7
- Queue: BullMQ
- Testing: Jest + Supertest
- Linting: ESLint + Prettier
## Coding Conventions
### Naming
- Files: kebab-case (user.service.ts)
- Classes: PascalCase (UserService)
- Methods: camelCase (findById)
- Constants: UPPER_SNAKE_CASE (MAX_RETRY_COUNT)
- Interfaces: PascalCase with I prefix (IUserRepository) -- NO, without prefix
### Patterns
- Services: extend BaseService<T>
- Repositories: implement IRepository<T>
- Controllers: use @Controller() decorator with plural path (/users, /orders)
- DTOs: use class-validator for validation
- Errors: Result<T, AppError> pattern (never throw exceptions)
### Testing
- Unit tests: file.spec.ts in the same folder as the source
- Integration tests: test/integration/ with test database
- E2E tests: test/e2e/ with supertest
- Coverage target: 80% for services, 60% for controllers
### Git
- Branch: feature/PROJ-XXX-description, fix/PROJ-XXX-description
- Commit: conventional commits (feat:, fix:, chore:, docs:)
- PR: template in .github/PULL_REQUEST_TEMPLATE.md
## Business Rules
- Prices are always in cents (integer, never float)
- Dates are always in UTC
- IDs are UUID v4
- Soft delete for all entities (deletedAt field)
- Audit trail for every CRUD operation (createdBy, updatedBy fields)Optimizing Indexing
To improve indexing quality and semantic search performance, follow these guidelines:
Improve Quality
- Maintain a clear and consistent folder structure
- Use JSDoc/TSDoc to document functions and classes
- Write meaningful comments for complex logic
- Keep READMEs updated for each module
- Use descriptive names for files, classes and functions
- Document relationships between modules in README files
Reduce Noise
- Exclude generated files with .copilotignore
- Exclude unnecessary vendored dependencies
- Exclude large data files (CSV, dumps)
- Exclude legacy code that is no longer used
- Exclude lock files (package-lock.json is useful, yarn.lock less so)
- Exclude binary assets (images, fonts, videos)
Comparison with Alternative Approaches
To contextualize Spaces, Memory and Indexing, it is useful to compare them with alternative approaches to providing context to AI.
Context Approaches Comparison
| Approach | Pros | Cons | When to Use |
|---|---|---|---|
| Files open in editor | Simple, immediate | Context limited to open files | Local changes to a few files |
| #file mentions in chat | Precise control | Manual, requires file knowledge | Questions about specific files |
| Repository Indexing | Automatic, complete | Only repository code | Always (active by default) |
| Copilot Spaces | Multi-repo, multi-format | Requires initial setup | Complex projects, multi-repo |
| Agentic Memory | Automatic, persistent | Limited to 28 days, per repo | Recurring conventions, patterns |
| .copilot-instructions.md | Persistent, shared with team | Text only, not dynamic | Project rules and conventions |
| Detailed manual prompt | Maximum control | Not persistent, repetitive | Specific and complex tasks |
Limitations and Considerations
Despite the obvious advantages, it is important to know the current limitations of these tools in order to use them with realistic expectations.
Current Limitations
| Tool | Limitation | Impact | Mitigation |
|---|---|---|---|
| Spaces | Does not support automatic content updates | Risk of outdated context | Periodic Space review |
| Spaces | Limit on number of repositories per Space | Highly distributed projects may not fit in a single Space | Create smaller thematic Spaces |
| Memory | 28-day expiration for unused memories | Knowledge lost if not reused | Use .copilot-instructions.md for permanent info |
| Memory | Scope limited to single repository | Does not transfer knowledge between repos of the same project | Use Spaces for cross-repo context |
| Memory | Available only on Pro and Pro+ plans | Not accessible for Free and base Business plans | Use instruction files as alternative |
| Indexing | Only default branch indexed | Feature branches don't benefit from indexing | Frequent merges into main branch |
| Indexing | Files excluded by .gitignore not indexed | Local configurations not in context | Include example files in the repository |
| All | Depend on code and documentation quality | Poorly documented repositories benefit less | Invest in documentation and comments |
Data Privacy and Security
An important aspect to consider, especially for enterprise teams, concerns the privacy and security of data used by these tools.
Privacy Guarantees
- No training: Data from Spaces, Memory and Indexing is not used to train AI models
- Isolation: Memories are isolated per user and per repository
- Encryption: Data is encrypted in transit and at rest
- User control: The user can delete all memories and data at any time
- Content exclusion: The organization can exclude files and repositories from indexing
- Compliance: Data is handled in accordance with GitHub terms of service
- Data residency: For Enterprise plans, data can be localized in specific regions
Conclusion
Copilot Spaces, Agentic Memory and Repository Indexing represent a qualitative leap in how we provide context to AI development tools. Instead of repeating the same information in every session, we can build a persistent context ecosystem that grows and enriches itself over time.
The combination of these three tools covers all aspects of context: the code (Repository Indexing), external information (Spaces) and implicit knowledge (Memory). Together, they transform Copilot from a generic assistant to a partner that knows your project, your conventions and your preferences.
The practical advice is: start with Repository Indexing (automatic), add a
.copilot-instructions.md file with project conventions, and then create
Spaces for the most complex contexts. Memory will build naturally over time
through your daily interactions.
Series Progress
| # | Article | Status |
|---|---|---|
| 1 | Foundation and Mindset | Completed |
| 2 | Ideation and Requirements | Completed |
| 3 | Backend Architecture | Completed |
| 4 | Frontend Structure | Completed |
| 5 | Prompt Engineering | Completed |
| 6 | Testing and Quality | Completed |
| 7 | Documentation | Completed |
| 8 | Deploy and DevOps | Completed |
| 9 | Evolution | Completed |
| 10 | Coding Agent | Completed |
| 11 | Code Review | Completed |
| 12 | Copilot Edits and Agent Mode | Completed |
| 13 | GitHub Spark | Completed |
| 14 | Copilot Spaces and Memory | You are here |
| 15 | AI Models | Next |
| 16 | Customization | Next |
| 17 | Enterprise and Business | Next |
| 18 | Extensions and Marketplace | Next |
| 19 | Security | Next |