I've been thinking a lot about context recently. A lot of recent AI tools support working in a particular folder and pulling in files to provide the AI with context. I use files a lot to establish and deliberately construct the context for projects and tasks where I collaborate with AI. This is an emergent pattern worth discussing. Files are becoming the meeting point between users and AIs. While context operates differently for both of us, the files that populate the folder feel like our shared context.
But calling them files misses something. I've researched how people collaborate across collections of tools and documents and how co-writers navigate across multiple applications when working on a shared text. The interesting concept here isn't filesystems. It's something researchers in Computer-Supported Cooperative Work have been talking about for decades: Common Information Spaces.
Schmidt and Bannon (1992) define common information spaces in connection with cooperative and collaborative work:
"Cooperative work is not facilitated simply by the provisioning of a shared database, but rather requires the active construction by the participants of a common information space where the meanings of the shared objects are debated and resolved, at least locally and temporarily."
Whenever people collaborate on the same project they need to organise the relevant information and tools. Different roles and tasks require different pieces of information: some folks care about PowerPoints and legal documents; some about EPICs and Features; and others about typescript and markdown files. All of this information is deemed relevant and important to the project by someone. And all of it reveals something about what the project is about.
A lot of projects have a repository, internal documentation, Slack and similar communication channels, and maybe Figma files and Google Workspace. This is the common information space. Some of it is given by the infrastructure the team and organisation are used to. But a lot of the project information is established in files and links that the participants create and organise as they work.
The important point here is that the common information space is constructed by those participating in the project. The knowledge work generates files (presentations, designs, code etc.) and organising and collaborating around the work generates files (plans, tasks, reports, messages). All this is relevant context for the project.
When I start a task with AI, a large part of the work is constructing the context. I pull in specification, documentation, user-stories, reference implementations, designs etc. and when I work with Claude I generate additional documents to steer and guide the work (.claude files, plans.md, persisted context documents, research etc.). And Claude is an active participant on its own. I let Claude update Jira tickets and documentation. Claude and I are actively constructing the context and the work as we go.
So, by merit of this, I would argue that the common information space of a project is co-constructed by the participants including AI agents. Bingo.
When we join a project, we know where to look. There's a Slack channel, a Jira space, maybe a shared folder somewhere. We know that because we've worked in offices before.
AI does not know where to find stuff.
So it helps to think about two kinds of information spaces:
Tasks produce information for the project and subsequent tasks (user-stories are a good example). The project information space is the sum of all the information drawn in and produced across tasks.
If you want AI to be a useful collaborator, the first step is telling it where things live. Make the project information space explicit: list the sources, set up the integrations, give the AI access to search across them. This allows AI to fetch a Jira ticket and, when needed, search for additional information in OneDrive or recent conversations in Slack.
This should not be a project task. Your IT-infrastructure and ways-of-working should be aligned so that every new project follows the same model. And this model is part of the AI-directed rules you initialise the project with.
If your organisation has rules for folder structure and other principles that help humans discover and connect the dots between information, then you should communicate these to your AI collaborators too. Not just the structure, but the meaning behind the structure.
If you have a folder for Architectural Decision Records, tell the AI that's where technical decisions are documented and why. If you have a client folder for material shared with the client, make clear that anything in there is external-facing and should be treated differently from internal working documents. If your Confluence space separates requirements from delivery documentation, explain which is the source of truth for what.
The more the AI understands the intent behind the organisation of information, the more likely it is to look in the right places when searching for context on a task.
The project information space is shared, but different roles draw from it differently. A PM assembling a status report needs recent Jira activity, Github commits, and maybe the latest Figma progress. A developer picking up a ticket needs the design file, the requirements document, and the relevant parts of the codebase. A designer needs brand guidelines, the component library, and client feedback from Confluence or email.
These are all slices of the same information space. Today, each role navigates their own familiar corners and ignores the rest. AI can reach across those boundaries, but only if it knows the full space exists and which parts matter for which kind of work.
This is where task-specific rules become practical. As the project information space grows, you don't want AI searching through deliveries from 2020 when you need last week's sprint activity. The slice you give AI should help focus the task and not derail it into searching everything. Write rules that prioritise the right sources for the task at hand:
These rules can be formalised as task-specific configurations that any team member can invoke when starting a piece of work with AI.
If you already have human-readable best practices for organising your key information spaces, then you are set to onboard AI collaborators with the following steps:
If you do not have shared guidelines for how the different spaces are organised, then you need to fix that as fast as possible. For the sake of humans and AIs alike.