A company talks about itself every day — in meetings, in chats, in documents. Normally that stream disappears: it stays in people's heads, in message threads, and in files nobody will open again. Tessbrain turns a company's conversations into its memory, and that memory into work: it answers questions with links to the original source, computes figures in code, drafts documents, runs processes, and notices on its own where the company has drifted out of sync.
One loop, four stages. Everything else in this document is detail inside it.
| Stage | What happens |
|---|---|
| Intake | Meetings, calls, Telegram and Slack, documents, links, CSV/Excel exports, CRM (amoCRM, Bitrix24, HubSpot, Pipedrive), 1C via OData, Google Sheets, BI. Nothing has to be entered by hand — the system consumes what is happening anyway. |
| Extraction | About thirty specialised extractors each pull their own layer out of a meeting: decisions, tasks, participants, KPIs, risks, ideas, opinions, causal chains, contradictions, outcomes. Every fact carries a source, a date and a confidence. How many model calls this costs depends on the model class: on a strong model the whole base pass is a single call, on a cheaper one it is split. |
| Memory | The company graph: typed entities and typed relationships. Facts are versioned, not overwritten. Overnight the system tidies itself: merges duplicates, weakens unconfirmed material, collects insights. |
| Work | Chat, documents, process boards, reports, simulations, controlled feeds to partners, and a connection into Claude Code and Cursor as a context source. |
The company brain does not work in a vacuum: it sits inside an ecosystem where each service contributes its own kind of conversation. This is not "integrations by the list" but a division of labour — capture and recognition live elsewhere, understanding and memory live here.
Our own meeting-processing system: it records and transcribes, the brain takes the finished material and breaks it into meaning. A trusted internal source, not a third-party service bolted on.
The domain of client communication is deliberately separated from internal memory: transcripts and audio are not copied to us. Events arrive — deal at risk, complaint, coaching recommendation — and the live client card is pulled from their system at display time. Conclusions their model produced are marked as model narrative and never become company facts: protection against one AI system feeding another its guesses.
A Telegram bot as a separate entry point: it delivers post-meeting artifacts, answers from company memory, and holds a conversation with an employee (section 11).
CRM, 1C via OData, Google Sheets, BI, file exports, links. Plus external parties who push facts in over the bus (section 13).
Writes to CRM (create a deal or lead, append a comment) on a separate path, isolated from reading and closed by default; delivery to Slack, email, Notion, Jira and other connected systems through board blocks; feeds to partners over the bus; "something new appeared" notifications for subscribers.
Three different flows that are easy to confuse — they concern different things.
Knowledge sync reads meetings from the source and runs them through extraction. It runs in the background with visible progress, and chat knows about it — during a run it honestly warns "sync in progress, data is incomplete" rather than answering from half the base as if that were all of it.
A dataset connected by link or to a CRM refreshes on the schedule its owner set. The fetch is always full — sources like Google Sheets do not offer a delta at all. But the system compares what it fetched against what is stored: unchanged means nothing is rewritten, no model spend on rebuilding the ontology, no empty version in history. Changed means the new data becomes current, the previous version moves into history (5 kept, with rollback), metrics recompute and subscribers are notified.
Changes the system makes in other systems: CRM writes, document delivery, tasks in trackers. Here the principle is the opposite of intake — money is locked by default: the CRM write path is off until deliberately enabled.
Company memory changes only through extraction and overnight tidying. Data tables change through source refresh. External systems change only through explicit process actions. No flow writes into another's territory: a data source cannot alter a fact from a meeting, and meeting extraction does not touch data tables.
Each workload gets its own model class, chosen by the rule "sensitivity to quality x frequency". Heavy and rare work that sets the quality of the whole knowledge base (meeting extraction, overnight consolidation, spec generation, final synthesis of a deep search) runs on a strong model. Frequent and interactive work (chat, ordinary search, intermediate steps) runs on a smaller one, where speed and price matter. The company chooses the provider and the key (section 14); the system chooses the tier per task.
Not notes and not document search, but a model of the company: people, projects, clients, decisions, tasks, metrics and the relationships between them. It grows out of conversation on its own.
A project budget, a person's role and department, a task's deadline and assignee, a project's status are kept as a chain of dated versions. A new value does not erase the old one — it marks it superseded, with the date and the source meeting. You see not only "what is it now" but "what was it and when did it change". Amounts are normalised to numbers, so "2M RUB" and "2,500,000 rub" from different meetings are comparable — growth shows as a figure, not as an impression.
The state of the company on 15 March, on 1 May and today — three slices side by side with an automatically computed difference: who appeared, what changed, what disappeared. Retrospective without archaeology through message threads. A version is dated by the meeting date, not the upload date, so an archive loaded in one day does not collapse into a single point.
Contextual links ("mentioned near each other") weaken over time, while structural facts — decided, assigned, changed role — never decay. Memory that forgets nothing bankrupts its owner; untyped forgetting would eat the org chart.
Between raw facts and an answer sits a layer that thinks ahead of the question.
When memory has no basis for an answer, the system says so instead of producing something that sounds right. This is the property that makes an answer presentable.
A profile of a person built from how they actually participated: role, projects, decisions, opinions, manner of speech — from meetings, not from a questionnaire.
Competencies, load, growth and risk of burnout — inferred from participation in real work rather than from a self-assessment form.
Who works with whom, where communication breaks, which pairs produce results and which stall.
Run an offer, a negotiation or a contested decision before money and time are spent.
The counterpart is not an invented avatar but a real client from the company graph: a dossier assembled from node properties, relationships and the cards of linked people (section 2.1). You can talk to it and run an offer past it.
Clients are grouped by actual attributes (industry, status, category). Clients without attributes honestly land in "no attributes" rather than being distributed into invented groups.
A multi-round discussion of a question: abstract roles (CEO, CFO, CTO) and profiles of real employees at one table, with a record of disagreements and a check of the conclusion against company data.
Personas answer in their own language, with an adversary set over them. In a panel of field personas the adversary attacks the messages.
The governing principle: code computes, not the language model. The model turns a question into a structured plan, the plan executes deterministically and is visible in the API response. If a question does not fit a plan, a fallback engages — the model writes the computation as code, which runs in a sandbox; the answer then arrives together with the code, so the logic can be checked.
"Revenue 4.2M", said at a standup, and a column from 1C become one metric with a shared history. The summary reads: "meetings said X, the data says Y — a 17% discrepancy".
Question → structured plan {operation, column, grouping, filters} → deterministic execution. When the model is unavailable a built-in parser handles common questions ("sum of X by month", "top N by Y") — figures are computed even without an LLM.
Coverage (how many rows were counted), how many were skipped, and why.
Three different chats for three different jobs — not one window with a mode switch.
| Chat | What it does | When you need it |
|---|---|---|
| Over company memory | Searches the whole memory three ways at once (meaning, exact terms, graph relationships) and synthesises an answer with a list of sources. Three channels are a necessity, not belt-and-braces: semantic search has a proven mathematical ceiling (ICLR'26) — a single vector cannot return every combination of documents, and the best models fail on enumerative queries. So enumerative questions — "show everyone who…", "how many…", "who worked on both A and B" — are recognised and weight the graph channel, where enumeration and intersection are exact by construction | "What did we decide about client X?", "Show everyone who worked with both A and B" |
| Over meetings and documents | No base-wide search at all: you choose the materials yourself, and the answer comes strictly from them | Reviewing a contract, preparing for a call about one client |
| Product guide | Explains how to use the product from curated help. Deliberately blind to company memory — no meetings, no graph | "How do I set up a board?" |
You lay blocks on a canvas and connect them with arrows: "when this happens → ask the company brain that → make a document → send it there". The diagram is not a picture for a presentation; it is the automation: save it and it runs on a schedule or on an event.
There are two kinds, and they mix on one canvas:
| Kind | Assembled from | What you get |
|---|---|---|
| Process | trigger, data sources (meetings, CRM, web), documents, conditions, delivery | Automation: do it and send it without a human |
| Creative | references, prompts, image and text generation | A presentation, ad creatives, a storyboard, a landing page in blocks |
Mixed boards are the ordinary case, not a trick: "after a meeting collect the results → draw a picture from them → send it to chat" is one board whose first half is process and second half creative.
Document generation lives in its own section and works on its own. Boards simply know how to call it — another entrance to the same module, not its owner.
A proposal, a contract, a client brief or a free-form document: the system takes the meeting material and the relationship history, assembles the text and returns a finished Word or PDF file on letterhead.
Upload your own DOCX with markers and the system fills them from memory and company details. The key part is that every field is marked: green for what was found in the data, yellow for what was inferred, red for what is missing. Not "your document is ready" but "your document is ready, check these three fields".
The system finds repeated patterns in memory and assembles them into rules.
The system remembers not only what was decided but how it turned out — and next time says so in advance.
"A competitor cut prices by 15%" becomes "competitor price pressure", classified by business tensions: growth versus margin, speed versus quality, in-house versus contractor. The tension reference is closed — anything that does not fit is honestly marked "other" rather than forced into the nearest match.
Retrospectives are mined for how things ended, and confidence rises only from confirmed outcomes, decaying with time. Ten discussions whose fate is unknown produce low confidence, not high — otherwise the number would mean "we talked about this a lot" while reading as "we verified this".
A separate loop for the small products, services and automations a company needs for itself. The point is not to draw a diagram but to produce a very detailed and correct technical specification grounded in company data — one you can hand to an external AI to implement and then verify that it built exactly that.
The goal the loop works towards: an employee who cannot program conceives a mini-service they or their colleagues need, brings it in SIMA to a coherent specification, hands it to an AI executor, and the system watches the result.
Passed, failed, and not proven. The third exists because "no evidence" is not the same as "done".
A separate product in the ecosystem: a Telegram bot with its own memory of a person. It brings an employee what concerns them personally after meetings, remembers how to talk to them, reminds them about tasks, and lets them ask the company brain without opening the web interface — just by writing in a messenger.
"What did we decide about client N?" and the answer arrives from the whole company memory with source links, using the same search as the web interface.
The name is literal: while a person walks from the meeting room to their desk, the system has already prepared drafts for them — matched to their role in that meeting. A strategic summary and questions for the founder, task cards for the project lead, a technical specification ready to hand off for the developer, a draft letter for sales. The role is determined by how the person participated, not by a line in the staffing table. Not a generic "meeting minutes" mailout but work already started for you: you sit down not to an empty screen but to a draft that needs correcting.
Not a dashboard you have to open, but an observer that notices and speaks first.
Departments do not tell each other important things, do not pass data along, and understand the same words differently. The company pushes on one part of the system and it breaks in another: sales accelerates the pipeline and support drowns; marketing promises a date production has never heard of. Nobody is individually at fault — connectivity is broken.
One number showing how far the company is moving in one direction, and above all where it diverges. The check runs at four levels: inside a department, between departments, company goals against department goals, and executives against each other. The index keeps history, so you see a trend rather than a snapshot.
A level with no data does not enter the index. Emptiness does not become perfect synchronisation — which is the first thing metrics like this usually get wrong.
Not simply "send a partner an export". This is the company's reception desk for machines: an external system, somebody else's AI agent or another company gets a key and exactly its own slice of memory — not a file but live answers. And, more importantly, the ability to work on those answers: understand the context and do a task without taking people's time.
The slice, the blocking of fact types and the redaction are applied to the material before an answer is composed. The model physically does not see what is forbidden — more reliable than "we asked the assistant not to talk about salaries".
Forbidden fact types → allowed fields inside a fact → replacing amounts with "[AMOUNT HIDDEN]", emails and phone numbers. The number of redactions is returned in the response. The real protection here is the folder slice and type blocking: a secrecy ceiling as a separate sieve on the main path does not yet fire, so it cannot be sold as a boundary.
The things that usually stop an adoption at the security department.
Not on a folder but on an individual graph node: a scale from "visible to all" to "CEO only". It works with the caveats in "Honest limits": classification filtering applies on the file graph backend, and the classification itself has to be set manually — everything defaults to "internal". The scenario "the M&A discussion will not surface for an intern" requires both.
Not only in the interface: on supported configurations, forbidden material is cut before synthesis, so the model cannot let slip what it never saw.
Row-level security policies: even a bug in application code will not let one client see another's data. An argument for a security officer, not a marketing claim.
The main audit log is protected from modification and deletion by a database trigger — compliance by construction rather than by promise. Plus a separate log of sensitive reads (profiles and confidential nodes): a leak more often looks like a read than a change. The data bus's own log does not yet have this protection.
One person in several organisations with switching, a holding above corporations, custom roles on top of built-in ones, a "Chinese wall" between companies in a group.
The model can run on your own servers. "Internal" has a single definition for the whole product, checked both at boot and at call time.
The section where "we are better" is replaced by numbers — including the ones that are not in our favour. Otherwise it would not be worth having.
LongMemEval (the oracle variant and the variant with distractor sessions), LoCoMo, HotpotQA, RAGTruth, TruthfulQA, QMSum. Accepted public sets rather than our own convenient examples; data is downloaded from public sources, and the judge and model are recorded in every result.
The difference comes from how we assemble and present memory, not from the mere fact of having it:
| What was compared | Baseline | Ours | Sample |
|---|---|---|---|
| HotpotQA — multi-hop questions | strict answer from fragments 0.57 | analysis mode 0.77 | 30 |
| LoCoMo — multi-session memory | 0.43 | product path with date resolution 0.57 | 30 |
| Hard LongMemEval questions | "dump the whole history" 0.25 | analysis mode 0.71 | 24 |
| Time-based questions | ranking without time 0.17 | temporal module 0.40 | 30 |
| Questions spanning many conversations | retrieval 0.23 | sessions with hits in full 0.57 | 30 |
Our hybrid retrieval (text + meaning + rank fusion) draws level with plain BM25 on LongMemEval: 0.49 against 0.50 on a sample of 200, and 0.675 against 0.675 on 40. Against "no memory at all" the gap is enormous (0.065); against solid text search, there is none.
Sample sizes are 20 to 200 questions. This is honest measurement, not statistics — a difference of two or three hundredths on thirty questions cannot be taken seriously, and we do not take it so.
This is part of the product, not fine print. A product that promises more than it delivers loses trust at the first demo.
Off by default — enabled deliberately
>=, not ==, and there is no Python lockfile, so the audited version is not guaranteed to be the installed one.