Agentic intelligence and all manner of autonomous tooling are (of course) on the rise and now finding a way into services used across every industry vertical. As the notion of a “second brain” working inside organisations as a functional extra to the existing workforce, this digital twin with decision-making power is now driving companies to question how they use AI models, which model they opt for, how much single platform lock-in they accept and how they govern all this new power.
Co-founder at conversation capture, transcription and information management company Bluedot, Dima Eremin, has some insightful views on how organisations should move forward here and whether the option of a second brain ends up dumbing us down, or actually making us smarter.
After several years in which enterprise AI discussions focused mainly on model capability, data has moved back to the centre. Businesses are discovering that access to a powerful model is not enough. The model also needs useful organisational knowledge, structured so that people and software can retrieve it, understand it and decide whether to trust it.
“The idea of a second brain follows these progressions naturally,” explained Eremin, speaking to Techzine this month. “Bring together company documents, customer records, project history, support data and internal conversations, then create a shared memory layer that employees and AI systems can use.”
Captured intelligence, injected into operational systems
At Bluedot, Eremin and team say that they “sit close” to one part of this emerging architecture, and that means they capture and structure meeting intelligence, then help companies move selected information into systems such as Salesforce, data warehouses, private cloud environments and AI workflows.
“That gives us a useful view of how businesses are trying to build organisational memory in practice,” said Eremin. “And it has made me question one of the central assumptions behind the second-brain idea.”
But for a large enterprise, one universal brain may be the wrong architecture because, as we know, companies do not have one single memory and a 5,000-person organisation is not a single coherent mind.
“Sales, product, legal, HR and finance use different systems, work with different definitions and operate under different access and retention rules. The same customer may be represented differently inside Salesforce, a support platform and a finance system,” explained Eremin.
He reminds us that even the meaning of a decision changes between teams. A product discussion may remain open for weeks. A legal approval may need a clear owner and audit trail. A sales commitment may be useful to an account team but inappropriate for wider access.
One shared pool of information ends up drowning us
Trying to collapse all of this into one shared pool can create a system that is too broad to trust and too restricted to be useful.
In Eremin’s view, a better approach may be several bounded memory layers: an account memory for sales and customer success, a product memory built from research and roadmap decisions, a project memory for delivery teams, and more tightly controlled environments for legal, HR or regulated work.
These layers can exchange selected information and they do not all need to become one database.
Meeting intelligence is part of the plumbing
Meetings contain information that rarely appears elsewhere.
“A CRM records that an opportunity was lost. The conversation may reveal that the customer rejected the implementation timeline. A project tool shows that a deadline changed, while the meeting contains the failed dependency, disagreement and decision that caused it,” said Eremin.
He argues that AI notetakers are an “important ingestion layer for organisational memory” (but then he would say that; that’s what his company does – do is it justified?)… and this is largely because they can turn speech into transcripts, identify speakers, extract actions and entities, and route selected information into other systems.
Meeting intelligence is only one input.
But it’s also important to realise that meeting intelligence is only one input i.e. a useful memory architecture also needs CRM data, documents, support records, project systems, identity controls and operational databases. The hard part is not collecting everything. It is deciding how those sources relate to each other.
“We increasingly see companies move beyond generic meeting summaries. One business may want customer objections and agreed actions written into custom Salesforce fields. Another wants meeting-derived data sent into Snowflake or its own cloud environment, where it can be combined with wider commercial and operational records,” said Eremin.
Others want selected meeting intelligence exposed through APIs or MCP connections, so employees and AI systems can retrieve it inside existing workflows while retaining the permissions applied to the original conversation.
That is where a notetaker starts to become part of the data infrastructure rather than another notes application.
The middle layer matters most
Most second-brain projects focus on ingestion and retrieval. They connect the sources… add semantic search, put an assistant on top, but the difficult work sits between those stages.
Before information becomes durable organisational memory, Eremin says it needs a schema, provenance and a lifecycle. The system must distinguish an observation from a proposal, an approved decision from an abandoned idea, and a current policy from something that has been superseded.
“A comment made during a meeting should not carry the same authority as an approved policy. When two sources disagree, the system should expose the conflict rather than allowing a model to quietly choose whichever version looks most relevant,” he added.
For CTOs, that means starting with a defined use case rather than a company-wide promise.
“Choose one memory failure: poor account handovers, repeated project discussions, slow onboarding or customer feedback scattered across hundreds of calls. Then design the ingestion, schema, permissions and delivery around that workflow,” concluded Eremin.
People before agents
The suggestion here is that AI agents will become major users of these memory layers. They will prepare account briefs, retrieve project history and trigger actions across business systems.
But people should be the first test.
Can an employee inspect the original source? Can they understand why an answer was returned? Can they challenge it and correct it when it is wrong?
If the memory layer works for people, it will work for agents.
Eremin adds a final comment and says that the future company’s second brain may not be one brain at all. It may be a network of connected, governed memories, built around the way different parts of the business actually operate.