Today, we’re launching Qontext 1.0, a self-maintaining context repository that gives AI agents a shared source of truth about the company they work for.

We’ve spent the past few months building alongside some of the most AI-native companies. They’re using agents to help engineers ship products, support customer conversations, inform decisions, and run internal processes. These applications become significantly more useful when they can build on each other’s work.

A commitment made during a sales call should inform an engineering task. An engineering decision should inform the next customer response. When an agent resolves a new question, that answer should be available to others.

Qontext provides the shared context that makes this possible, while giving people control over how knowledge changes and who can access it.

Anatomy of a context layer

“Context layer,” “company brain,” and “organizational memory” are often used interchangeably. The labels alone tell you little about how a system works. Implementations take significantly different shapes, combining documents, search, knowledge graphs, source connections, and application memory. As a result, comparing approaches requires comparing the underlying specific design choices.

Infrastructure vs. application: Some products manage context within an application that also performs tasks for the user. Others provide context as infrastructure that separate applications consume. The distinction: where the knowledge is maintained and how independently it can be used across models, agents, and workflows.

Human friendliness: Systems differ in how much of their stored knowledge people can see and change directly. A document interface, a graph explorer, and a developer repository offer different ways to inspect information, correct mistakes, and manage permissions. These choices affect how easily people can understand what their agents rely on and intervene where it matters.

Agent access: As the number of agents and tasks grows, the cost and latency of accessing context become increasingly important. Two design choices shape those economics: the format in which context is stored and returned, and the operations agents can perform on it. Search results, structured files, and graph relationships require different amounts of retrieval and interpretation. The ability to search, read selectively, follow references, or write knowledge back affects token consumption, tool calls, and the quality of the resulting work.

Retrieval from sources vs. context consolidation: Some systems retrieve information from connected tools when a request arrives. Others consolidate information from multiple sources into maintained records that agents can read and contribute to. Systems can combine both approaches, with different tradeoffs around freshness, repeated retrieval work, provenance, and maintenance.

These choices shape how context fits into a company’s AI systems. They also determine how the system adapts when knowledge or permissions change, new agents are added, or existing models and applications are replaced.

How Qontext works

Qontext gives a company’s agents a shared source of truth they can use and improve together. It connects to existing tools and builds a context repository organized around the business, with a structure that can reflect customers, products, projects, processes, and their relationships.

The repository organizes company knowledge into folders and readable Markdown files, with references linking related information and its sources. A customer file can bring together information from several tools. A product decision can link to the projects and customer requirements it affects. People can browse and edit this structure, and agents can search it and follow the same relationships.

Company knowledge changes every day. Keeping a context repository useful shouldn’t require someone to rewrite it after every product update, process change or customer conversation. Our continuous update agents process new or changed information after syncs with the connected sources and decide what to create, update, or leave alone. Structure files provide guidance about what belongs in each folder, which sources to use, and how to maintain the information.

Models, tools, and agent frameworks also change quickly. Your company’s knowledge and intellectual property need to remain useful as the tools around them evolve. Qontext keeps that foundation independent: agents can search, read and update the same repository through API, MCP or CLI, securely governed by fine-grained access controls. When a better model or application comes along, it can build on the knowledge you already have.

The four dimensions above translate into concrete choices in Qontext’s design. Together, they support a growing number of agents sharing knowledge while keeping that knowledge understandable and manageable for people.

Companies can start with the context needed for one workflow and make it available to others as they add agents. A customer record maintained for sales can also inform support or engineering, within their permissions. Each new agent can use and enrich a foundation the company has already built.

The engineering challenges behind shared context

When agents across a company depend on the same context, that repository becomes critical infrastructure. A lost update, an incorrect permission decision, or slow retrieval can affect many workflows at once. We’ve approached Qontext as a database engineering problem, building for a future where companies run orders of magnitude more agents than they do today.

Concurrency becomes difficult when agents and source systems update shared knowledge at different speeds. An agent may spend minutes reasoning before submitting a change, while human review can take hours. Other contributions continue throughout that time, so the repository has to accommodate overlapping work without losing information or letting outdated assumptions overwrite newer knowledge.

Permissions create a second challenge: finding relevant information within the portion of the repository an agent may access. Checking access to one known file is different from searching a large hierarchy with inherited permissions. Retrieval and permission evaluation have to be designed together so the system can remain responsive as the repository and its use grow.

Human oversight must also scale as more agents contribute. Routine maintenance cannot require a person to inspect every update, but important changes still need accountable review. Qontext supports automatic updates and review requirements for selected files, allowing companies to decide where human judgment is necessary.

These challenges are closely connected: changes, permissions, retrieval, and review all operate on the same evolving knowledge. We’ve brought together database, AI, and product engineers with experience at Snowflake, Databricks, Neon, and Stripe to build that foundation.

Building a business on shared context

Our customers are using Qontext as the foundation for redesigning processes across their businesses. Customer success agents can answer questions using product knowledge, company policies and customer history, then add newly established answers to the shared FAQ. Coding agents can account for customer commitments, design decisions and ongoing engineering projects before making changes. Agents retrieve that context as they work, reducing the background people need to gather and explain for each task.

Internally, we’re building our own company around the same foundation. Each new agent can draw on knowledge already accumulated and enrich it through its work. As that context compounds, companies can design increasingly ambitious processes that build on what others have learned. This is multiplayer AI: agents and people contribute to a shared understanding of the business that lasts beyond individual conversations.

Qontext 1.0 is available now. Book a demo to see it in action.