Teamcentric Context
Early accessGive every coding agent instructions your team can trust.
Govern the prompts, rules and agent files that explain your software to AI coding tools — with one versioned library, a review path, and a visible record of what reached each repository.
Teamcentric Context is in early access, onboarded as a guided pilot rather than self-serve signup.
acme/billing-service
Assistant instructions
- CLAUDE.md v7 current
- .cursor/rules/api.mdc v3 → v5 outdated
- AGENTS.md v4 modified in Git
- .github/copilot-instructions.md v2 missing
ai artifacts apply brings this repository back to the published versions, and records what it changed.
Fig. 1 — A repository scan comparing local instruction files with the versions the project has published. Sample data.
The problem
Instruction files became load-bearing without becoming governed
Coding assistants keep obeying these files long after they were copied, edited locally and forgotten. Without an owner and a version, nobody can say which instruction is current or where it is in use.
- The same conventions written four different ways in four repositories
- Instruction files copied from a project nobody works on any more
- Nobody certain which version of a rule is the current one
- Local edits that never make it back, and central edits that never arrive
- No record of who changed an agent's instructions, or why
The unit of work
Everything is an artefact
A typed, versioned piece of reusable content with an owner, a lifecycle and a place it belongs. That single object is what makes review, testing, distribution and drift detection possible at all.
Each carries a status of draft, published or archived, a knowledge layer, tags, placement rules for where it belongs on disk, and links to the project, team, technology or client it applies to.
Artefact types in use today
- Prompts
- Templates
- Guidelines
- Agent files
- Coding conventions
- Snippets
- Runbooks
- ADRs
- Test strategies
- Domain glossaries
- Policies
- Workflows
The platform
Governed centrally, delivered in the formats tools already read
The web application is the system of record. The CLI is what connects it to the repositories your engineers actually work in — inspecting a working copy, applying published versions, and reporting drift. Nothing clones or stores your repository on our side.
Capabilities
Treat AI artefacts the way you already treat code
Versioned, reviewed, tested, released — and checked afterwards to confirm it is still what you released.
- Discovery across your repositories
- Use the CLI to inspect a working copy for the AI assistant files already there — under their real names, across many tool formats — and bring the ones worth keeping into the library.
- Versioned, canonical content
- Every artefact carries numbered versions with content, variables, a changelog and an author. Compare any two versions, and roll back to an earlier one when a change turns out badly.
- Review before publishing
- Line comments, threads and change requests with approve, reject and merge. An artefact can require review or a passing test run before it is allowed to reach the published state.
- Apply from the command line
- A CLI binds a repository to its project, previews what would change, applies published artefacts to their configured paths, and records what it wrote — so the same operation works on a laptop and in CI.
- Drift detection
- Compare files in a working copy with the published versions recorded in its project binding. Current, outdated, locally modified and missing states are reported without silently overwriting either side.
- Scoped knowledge layers
- Classify content by regulatory, organisation, team, technology, project, client or environment scope. The layers say where knowledge belongs; they are not presented as an automatic merge engine.
- Test before release
- Define regression suites and cases against an artefact, run them with assertions, and gate publication on the result — the same instinct you already apply to code.
- Repository integration
- Attach GitHub, GitLab or Bitbucket repositories as publishing destinations. Provider credentials are encrypted at rest, used only for the requested action, and no tenant repository is cloned or persisted by the service.
- Publish through a pull request
- Deliver approved artefacts to an attached repository as one commit on a fresh branch, with a pull request opened for review. Nothing is merged automatically, and a base branch that has moved since the preview invalidates the plan rather than overwriting anyone's work.
- Restricted artefacts
- An artefact can be restricted to named people and teams instead of being readable across the whole organisation. Team grants resolve through live team membership, and an administrator who reaches a restricted artefact is recorded as using an override.
- An audit trail per project
- Every project records changes and outbound Git actions — repository attachments, publication plans, commits and pull requests — with a timestamp and the actor responsible.
- Placement you maintain
- Where an artefact's file is written in a repository is a tenant-maintained list rather than a fixed set. Three built-in strategies are seeded for every organisation, and custom entries can be retired without disturbing the artefacts already using them.
The application
What it looks like in use
The artefact library, narrowed to a single knowledge layer, with each artefact carrying its type, status and version.
How it works
From scattered files to a governed library
Four steps, in the order a pilot actually runs them.
-
Step 01
Inventory a working repository
Run the CLI where the code already lives. It recognises instruction-file patterns across supported tools without sending the repository to a hosted scanner.
-
Step 02
Create the governed source
Bring the useful files into the library, give them an owner, scope and placement, and bind the repository to the right project.
-
Step 03
Review and publish
Edit centrally, comment inline, raise a change request, and publish once it is approved. The published version becomes the one that is allowed out.
-
Step 04
Deliver, then watch for drift
Apply published artefacts in a working copy, or publish them to an attached repository through a pull request. Then compare local files with the versions the project expects.
Formats
The files your tools already read
A shared registry of assistant-file patterns, so an artefact can be governed centrally and still land where each tool expects to find it.
- Claude and Claude Code
- CLAUDE.md, settings, commands, MCP configuration, skill bundles
- OpenAI Codex
- AGENTS.md, codex.md, nested and override files
- Cursor
- .cursorrules, .cursorignore, .cursor/rules/*.mdc
- GitHub Copilot
- Copilot instruction files
- Windsurf and Codeium
- Rules and configuration files
- Aider
- Configuration, model metadata and ignore files
- Continue
- .continuerc.json
- Cline, Roo Code, Amazon Q
- Rules and MCP configuration files
To be precise
Context discovers, versions, places and monitors these file formats. It is not an integration with each vendor's API, and it does not translate content between tools — with the exception of Claude skill bundles, which have a dedicated import and export path.
What it does not do yet
Context is an early-access product. These are the things teams ask about most often that are not part of it today — worth knowing before a conversation rather than after one.
- Single sign-on, SAML and SCIM provisioning
- Direct-commit publishing — a pull request is the only enabled write mode
- A deterministic merge engine across the seven knowledge layers
- A hosted MCP server or runtime agent
- Formal compliance certification or attestation
- Guaranteed unattended enforcement in CI
Start with one repository and the instructions already in it
Early access runs as a guided pilot: inventory one working copy with the CLI, bring the useful files under review, and deliver a first published artefact. Tell us which tools and file formats you use today.