How to give AI agents your company context without copy-pasting
Four ways to give AI agents your company context without copy-pasting: chat projects, repo instruction files, MCP connections and a shared source.
To give AI agents your company context without copy-pasting, write that context down once in a short, owned source, then connect each agent to it: through project files, repo instruction files, or a live connection such as MCP. The goal is one source that every agent reads, not a different pasted preamble in every chat.
Many teams rely on copy-paste. Someone keeps an "about us" block in a notes app and pastes it into ChatGPT, Claude or Cursor at the start of each task. It works for one person. It breaks for a team, because every copy drifts. This guide covers what to give agents, the four main ways to deliver it, and how to keep it current.
Why copy-pasting context breaks down
Pasting context feels free, but it has real costs:
It goes stale. The pasted block still says "monthly and annual plans" three weeks after you dropped monthly.
It varies by person. Each teammate has their own version, so agents give different answers to the same question.
It has no source. When an agent states a fact, nobody can tell where it came from or whether it is current.
It ignores permissions. People paste whatever they have, including things the agent should not see.
It does not reach background agents. An agent that runs on a schedule or inside another tool never sees what you pasted into your chat.
What company context agents actually need
Agents do not need your whole wiki. They need the few facts that change their answers. Start with these:
A company summary. What you sell, to whom, and how you describe it. Half a page.
A glossary. Product names, internal terms and words people get wrong. "Workspace" vs "account" matters to a support agent.
Current decisions. Pricing, scope, policies and "we don't do X" calls, each with a date and reason.
Style rules. Tone, spelling, formats, what never goes in customer-facing text.
Pointers to sources. Where the full pricing page, the security policy and the product docs live.
Keep it short. Anthropic's guidance on context engineering is to find the smallest set of high-signal information for the task. A tight page beats a 40-page export. For the team-wide version of this process, see context engineering for teams.
Four ways to deliver context to agents
1. Projects in chat assistants
ChatGPT projects and Claude projects let you attach files and instructions that apply to every chat in the project. Both can be shared with teammates, though Claude limits project sharing to Team and Enterprise plans. This is the easiest place to start: create a "Company context" project, add your summary, glossary and decisions, and share it.
The limit is that the context stays inside that one product. Your Claude project does not reach Cursor or a custom agent.
2. Instruction files in your repo
Coding agents read instruction files from the repository. Claude Code loads CLAUDE.md files at the start of every session. Cursor reads project rules from .cursor/rules. Many tools, including Codex, Gemini CLI and Cursor, support AGENTS.md, an open Markdown format for agent instructions.
These files are version-controlled, so changes are reviewed like code. They work well for engineering conventions and technical decisions. They are a poor home for sales or pricing context that non-engineers need to update.
3. Live connections through MCP
The Model Context Protocol is an open standard for connecting AI applications to data sources and tools. With an MCP connector, an agent can read the current version of a doc, ticket or record at the moment it needs it, instead of relying on a pasted copy. Claude, ChatGPT, Cursor and VS Code all support MCP in some form. See MCP explained for people who don't write code.
The trade-off: a connection gives access, not judgment. An agent connected to your whole drive still has to find the right page, and may find an outdated one first.
4. A shared context layer
The fourth option is a single, maintained source of company context that sits above your tools and feeds all of them: projects, repo files, connectors and custom agents. It holds the summary, glossary, decisions and style rules once, with owners and sources, and each tool reads from it.
This is the hardest to set up yourself, because you need to keep it in sync with every destination. It is also the option most likely to keep every agent on the same facts.
Comparing the options
Approach | Setup effort | Reaches other tools | Stays current | Best for |
|---|---|---|---|---|
Copy-paste | None | Only where pasted | No | One-off tasks |
Chat projects | Low | No, one product only | If someone updates it | Teams standardized on one assistant |
Repo instruction files | Low | Coding agents that read the file | Yes, through code review | Engineering conventions |
MCP connections | Medium | Any MCP-capable tool | Yes, reads live data | Live records and docs |
Shared context layer | Higher | All of them | Yes, with owners | Teams using several tools and agents |
Expect to use more than one. A sensible setup: repo files for code conventions, a shared project for the chat assistant most people use, and MCP for live data.
A worked example: a new support agent
You set up an AI agent to draft replies to billing emails. With copy-paste, someone pastes last quarter's pricing doc into its instructions. A customer asks about switching to monthly billing. The agent says yes, because the doc predates your annual-only decision.
With a shared source, the agent's instructions point to the current decision log and glossary. It sees "March 2026: annual plans only" and drafts a correct reply that explains the change. When pricing changes again, one person updates one entry, and the agent picks it up on the next email.
Guardrails to set before you connect anything
Decide what each agent can read. A support agent does not need salaries or board notes.
Prefer read access first. Add write actions only when you trust the agent and the tool.
Keep sources visible. You should be able to trace any stated fact back to a document and an owner.
Name an owner for each piece of context. No owner means no updates.
There is more on this in guardrails for AI agents.
FAQ
What is the fastest way to start?
Write a one-page company summary, a glossary and a list of current decisions. Put them in a shared project in the assistant your team uses most. That takes an afternoon.
Should we connect agents to our entire drive?
Usually not at first. Broad access means the agent may find outdated or sensitive documents. Start with a small, curated set of sources and expand.
Do we need MCP?
Not to start. MCP helps when agents need live data from other systems. For stable facts like your summary and glossary, a shared file or project is enough.
How often should company context be updated?
Decisions should be logged when they are made. Review the summary and glossary monthly.
Fewer copies, fewer mistakes
Copy-paste is how many teams give agents context, and it fails quietly as facts change. Write the important context once, give it an owner, and connect each agent to that source through projects, repo files or MCP. The fewer copies you keep, the fewer ways your agents can be wrong.
We're building Shane to be that single source: one place for a team's context and decisions, with sources and permissions, handed to every AI tool and agent. If that's a problem your team has, you can join the waitlist at tryshane.ai.