Connected company brain

It keeps every approved system in sync and answers from all of them

A connected company brain runs one connector per system. Each connector syncs approved content on a schedule, normalises it into a common record and stores it with an embedding, its source link, its owner and its timestamp. That turns chat, mail, documents, tickets, code and structured records into one searchable body of evidence.

Questions arrive from people and from their agents through the same interface. Retrieval selects candidate passages, expands them so the surrounding context comes back, applies the asker's existing permissions, and returns a cited answer or an explicit refusal.

Success is one question reaching an answer the asker is entitled to see, supported by current material. The fit is strongest where knowledge is genuinely spread across systems, so that no single tool holds enough context to answer well.

Value comes from fewer searches, fewer interruptions and less repeated work

Three effects carry the value, and they are separable. People stop searching several tools in sequence. Specialists get fewer routine questions once colleagues can retrieve a cited answer without them. And teams reuse prior work instead of doing it again.

Measure the three separately, because they overlap in the data: a shortened search and an avoided expert interruption often describe the same episode, and adding both counts it twice. Faster onboarding is a fourth effect, and it needs its own causal evidence before it enters a business case.

The primary KPI is time to a supported answer. The clock starts when the need arises and stops at an answer that is relevant, current enough, cited and permitted.

Connector coverage and query volume tell you whether the brain is used, not whether it is worth anything.

A freed hour is worth what it becomes, not what it costs

Start from the pool of freed hours:

Freed-hour pool =
  employees in scope
  × hours saved per employee per week
  × 52
  × active adoption

The pool describes scale, not value, and an hourly cost is not the right price for it. A freed hour is worth what the person does with it next, so classify the hour before you value it:

• An hour that removes real spend, such as a hire not made, overtime not paid or a vendor fee avoided, is worth its loaded cost. This route is the floor of the case.
• An hour that reaches a binding constraint where demand is waiting, such as a delivery backlog or a pipeline the sales team cannot work, is worth the incremental contribution profit it creates there. That is normally more than the person costs, because a company only employs people whose output is worth more than their pay.
• An hour that dissolves into scattered convenience has no P&L value until it converts into one of the routes above.

Duplicate work avoided counts through the first route as rework hours that no longer happen. The constraint route needs the most evidence: which constraint the hours reach, whether demand exists to absorb the extra output, and what a marginal hour there contributes.

A connected brain also costs more to run than a single-source assistant, because every connector is a live integration with its own permissions, failure modes and maintenance. Count that cost per connector, not once.

A fictional ROI range, floor to base

These assumptions are illustrative only. They are not a benchmark, a forecast, a guarantee or a quote.

Freed-hour pool = 1,400 × 1.5 × 52 × 70% = 76,440 hours

Floor, cost route only =
  76,440 × 10% × 520 SEK = 3.97 MSEK

Base, cost route plus constraint route =
  3.97 + (76,440 × 5% × 1,100 SEK)
  = 3.97 + 4.20 = 8.18 MSEK

Year-one cost = 3.10 + 2.20 + (0.18 × 6) = 6.38 MSEK

Fictional net first-year value = -2.4 to +1.8 MSEK
Fictional payback = about 19 months on the floor,
  about 9 months in the base case

The two ends are the same deployment with different evidence. The floor claims only removed spend, and it does not pay back inside the first year. The base case does, because the constraint-linked hours are worth about twice what they cost, but every krona of that difference rests on internal facts: the named constraint, the waiting demand and the marginal contribution. Connector count still shapes the cost side, which is why connectors are added in order of demonstrated demand instead of all at once.

One connector per system, permissions outside the model

Each connector runs a scheduled sync, with a separate backfill path for the initial load. A single dispatcher runs them all, so a failing connector degrades one source instead of the whole brain. Polling on a schedule is easier to reason about than push subscriptions, and it makes sync lag an observable number rather than an assumption.

Records are normalised across source types before indexing, so a chat message, a document, a ticket, a mail thread, a code file and a database record all carry the same shape: title, timestamp, owner, source link and access metadata. Retrieval selects candidates by embedding similarity, then expands each candidate to restore the surrounding context that chunking removed.

Authorisation sits outside the model. The asker is resolved to a principal, the principal carries grants, and scope is enforced during retrieval and again before return, across embeddings, caches, citations and conversation history. An agent asking on a person's behalf inherits that person's scope and never more. Access is served as an OAuth protected resource, so the same rules apply whether the caller is a browser, a service or an agent.

Source content is untrusted data, never instructions, which limits indirect prompt injection through a document, a mail or a ticket comment. The model receives only permitted passages, cites material claims and declines when the evidence is thin.

Freeze an evaluation set of real questions per connector, including ambiguity, conflicts, missing answers and required refusals. Score retrieval quality, citation support and freshness against it on every change, and keep the set frozen so scores stay comparable over time. Maintain a permission matrix across roles, regions, teams and exceptional grants, and test revocation and deletion lag against agreed service windows.

Monitor connector failures, sync lag per source, unsupported claims and stale citations. Privacy-respecting logs should reconstruct the asker, the query, the passages and the permissions behind any answer.

Start with two connectors, not six

Choose the two systems that between them answer the most recurring questions, connect them, and release to a small group with named owners and baseline tasks.

Set the thresholds before the pilot: supported-answer time, citation support, sync lag, permission tests, revocation and deletion lag. Add the third connector only after the first two have held those thresholds for an agreed period, and let every further connector be justified by questions the current set cannot answer.

Do not build when:

• Most valuable answers depend on undocumented judgment rather than recorded material
• Source permissions are inconsistent across systems or cannot be synchronised reliably
• One system already holds enough context, in which case connect that one and stop
• Question volume is too low to justify per-connector integration and maintenance
• A configured feature in an existing platform meets the tested need at lower total cost
• Leadership expects distributed minutes saved to appear automatically as EBIT

In those cases, clean the sources first, redesign access, capture the expert knowledge, or connect a single system and prove demand before widening.

Sources and methodology

The value model and the implementation recommendations are Epicube analysis, and the worked economics are illustrative. These independent references inform the retrieval, evaluation and permission controls:

• NIST TREC 2025 RAG Track documents evaluation work for retrieval-augmented generation
• OWASP: Vector and Embedding Weaknesses covers access control, data leakage and retrieval risks
• OAuth 2.0 Protected Resource Metadata (RFC 9728) defines how a protected resource advertises its authorisation requirements
• NIST AI Risk Management Framework provides a general framework for governing and measuring AI risks