A second brain for a company - where to start

A company second brain is a system that makes scattered knowledge — documents, procedures, contracts, and email threads — searchable through AI, with answers grounded in your data and accompanied by their sources. Do not start by choosing a tool. Start by choosing one painful slice of knowledge.

“RAG” and “knowledge graph” describe technology: how it works. A company second brain describes the promise: what it does for you. This article is about the latter.

Step 1. Choose a slice, not everything

“Let’s index everything” easily expands without a clear completion criterion. A narrower goal, such as “answer questions about warranty terms”, lets you build a quality test sooner. Timing still depends on the number of sources, permissions, and the state of documentation.

Choose the slice using three criteria:

Criterion	Why it matters
Questions recur often or a single error is costly	frequency supports payback, while a rare case may justify delivery because of its risk
Answers have a trustworthy, available source	without a source there is no basis for an answer or update
Correctness can be assessed	otherwise quality cannot be measured

Good first slices include internal procedures and instructions, contract and warranty terms, product technical documentation, or a knowledge base of resolved tickets — provided that a source owner can be named and the answer can be judged.

Step 2. Inventory sources and decide what is true

This may take a substantial part of the project. It is not about copying files; it is about decisions:

• Which version is in force? Three versions of a procedure in three folders can produce contradictory answers. The system should detect or reveal the conflict and route it for a decision, rather than choose without grounds.
• What is outdated? A document from last year that was never formally withdrawn can look as trustworthy as the current one.
• What is excluded entirely? Working notes, intermediate versions, and correspondence with one-off agreements.
• Who may see what? Recreate permissions in the system so an assistant cannot disclose information to someone without access. We expand on this in data security when deploying AI.

Be realistic: organising sources can take a substantial part of the project. The system will not fix disorder; if you give it stale material, it may present stale information convincingly.

Step 3. Collect questions the system should answer

Before building, ask for a list of real questions with expected answers. A pilot often needs only 30–50 well-selected cases, though the number should fit topic variety and error risk. The list is simultaneously:

• a specification, showing what the system should do;
• an evaluation set, used to measure quality after every change;
• a feasibility test, revealing before build whether documents answer half the questions at all.

Include questions for which “I do not know” is the correct answer. They test whether the system can abstain without evidence; balance them with answerable questions so the solution is not optimised only for refusal.

Step 4. Run a pilot, not immediate production

A pilot on the chosen slice includes indexing, search, an answer with a cited source, and a simple interface. Under our August 2026 price list it takes approximately 3–5 weeks and costs 12,000–30,000 PLN net.

A pilot using representative questions and real use measures three things that a demonstration cannot reliably predict:

1. Answer quality on your data. It must be measured on process questions, not inferred from a model demo.
2. Whether and how the team uses it. Distinguish lack of need from an access, interface, or user-onboarding problem.
3. Approximate ongoing cost at the observed volume and length of questions; full production cost also depends on monitoring, integrations, and required response time.

Step 5. Decide whether you need a graph

Retrieving passages with RAG works well for questions such as “where does it say this?”. It may not be enough when reliable traversal across many relationships is required, for example “which contracts with this subcontractor end before the audit?”.

When these questions matter, one option is a knowledge graph, which costs more and needs a domain model. A direct query to a well-structured database may be another option. Start with the simplest solution, measure which questions it fails on, and add a graph only where relationships genuinely improve the result. The reverse is building on instinct.

Step 6. Plan maintenance from day one

Knowledge changes. A document added to a folder should enter the index, and a withdrawn one should leave it under an agreed update policy. Otherwise the system may produce convincing answers based on outdated versions; without tests and source labels, that can remain invisible for a long time.

Minimum maintenance usually includes automatic index refresh, a register of what entered and left, periodic runs of the evaluation set, and a client-side knowledge owner who decides doubtful cases.

When a second brain will not work

• When knowledge has no trustworthy, accessible source. It may be text, a table, a transcribed recording, or multimodal material, but it must be obtainable, controllable, and updateable. The system cannot replace knowledge that exists only in people’s heads.
• When questions concern numbers and aggregation. “How many customers left in June?” needs a controlled data query, not semantic search alone. We design such cases within data and analytics.
• When the collection is small and safely fits in context. Supplying the verified whole to a model can be simpler than building a pipeline, if cost, permissions, and context limits allow it.
• When no one wants to organise the sources. Without current versions, permissions, and a knowledge owner, answers are hard to maintain safely.

How much does it cost?

Our August 2026 ranges are 12,000–30,000 PLN net for a pilot and 30,000–120,000 PLN net for a production system with integrations. We price maintenance separately by update frequency, observability scope, and response time. Model and infrastructure fees are additional and vary with question volume, context length, chosen model, and caching.

Frequently asked questions

Will our documents be used to train a model?

They do not have to be, but this depends on the chosen provider, product, and contract. In a typical RAG architecture, documents remain in the chosen repository and only passages needed for an answer go to the model. Check retention, processing location, data-use rules, and subprocessor access, then record those conditions in the contract.

Can it connect to tools we already use?

Usually yes, if the tool provides an API, webhooks, or another secure integration path. The interface may be a chat, intranet search, or messenger. The final form depends on technical constraints, permissions, and how the team works.

How is it different from ordinary file search?

Traditional search returns documents or passages. A second brain can compose an answer to a natural-language question and identify the sources used; that synthesis still requires evaluation.

---

We build knowledge graphs and RAG pipelines for ourselves too, and show them in our laboratory because they are our own tools, not presentation-only deployments. See second brain for companies or tell us what you search for most often.