How BitSafe Runs on Notion, Part 1 of 5
A smart agent can still give a bad answer when the company around it is hard to read.
We learned that before our agent fleet reached its current scale. Useful documents existed, but they sat beside local team conventions and disconnected records. A company could appear under slightly different names in different places. A decision might live in a meeting transcript, while the task created from it had no link back to the discussion. People could fill the gaps because they knew the history. An agent could only work with what the system made explicit.
The first instinct was to improve the prompts. That helped at the edges. It did not resolve the underlying problem.
We had to make the company easier to understand.
That meant rebuilding Notion as a shared operating context before asking AI to take on more work. The lesson has held as BitSafe has grown to 22 standard workspace members and 75 active Notion agents as of 26 August 2026: automation compounds only when the company has a dependable way to represent what is true, who owns it, and what should happen next.
Most teams do not suffer from a shortage of information. They suffer from information that has no stable shape.
A sales update in chat may be accurate but hard to retrieve later. A project page can explain the goal without naming an owner. A meeting transcript preserves every word while leaving the decision buried. A policy can remain searchable long after it stopped being current.
People compensate through memory and conversation. They ask a colleague which document to trust or whether a customer name refers to the same account in another system. That social repair work is manageable until it becomes the default interface to the company.
AI exposes the cost quickly. An agent cannot reliably coordinate work when the same object has several meanings or when ownership is implied. More model capability does not repair ambiguous company state.
We chose to fix the state.
Start with the things the company needs to agree on
Our redesign began with a simple question: which objects must have one shared meaning across teams?
Projects and tasks were obvious. Documents and meetings followed. Companies, contacts, apps, teams, and people needed shared records because several functions referred to them. Once those objects had stable homes, relations could preserve the context between them.
The goal was not to model every detail of the company. We wanted the smallest structure that could answer recurring operating questions without a manual reconciliation step.
A project should reveal its owner, status, and work. A document should reveal who is responsible for its accuracy. A meeting should produce decisions and follow-ups, with links to the entities discussed. A company record should connect to the relevant meetings and work without becoming the center of the whole workspace.
Part 2 covers the architecture itself. The important point here is the order: agree on the company objects first, then give agents access to them.
Documents need trust signals
Putting documents in one place does not make them trustworthy. Search can make the problem worse by returning an old page with a confident title.
We added a small set of controls around documented knowledge. Every important document has a responsible person. Its status makes clear whether it is being drafted, reviewed, published, or archived. Verification provides another signal when accuracy matters.
This creates useful pressure. A page cannot remain authoritative by accident. Someone owns whether it still reflects the business.
It also improves retrieval for people and agents. A current SOP should outrank an abandoned draft. A published policy should be easier to distinguish from working notes. When guidance conflicts, ownership and status give the team a practical way to resolve it.
The operating lesson is straightforward: a knowledge base needs maintenance rules, not just storage.
Meetings should change the system
Meeting capture gave us another clear test.
A transcript is evidence, but it is rarely the final operating artifact. After a useful meeting, the company normally needs a short summary, a decision, an owner, or a task. Sometimes it needs all of those, though the meeting itself should not become a second project tracker.
We treat meetings as inputs to structured work. The record preserves the source, then the outcomes connect to the relevant company, project, document, or task. This lets an employee or agent trace a follow-up back to the discussion without rereading the full transcript.
The distinction matters. Capturing more words can increase storage while leaving the company no easier to operate. Capturing the decision changes what the organization can do next.
Structure should help people before it helps agents
It is easy to justify a workspace redesign in the language of AI. That can lead to a system optimized for machines and resented by everyone else.
We used a different test. Does the structure reduce work for the people who maintain it?
If a field supports no decision or workflow, it probably should not exist. If a page has no responsible person, it should not remain a source of truth. If several teams refer to the same entity, they should not maintain separate copies. If a recurring process matters, it needs a durable description rather than a remembered sequence.
We also avoided a big-bang migration. Active work moved first. When someone touched older content, they cleaned it to the current standard. Inactive material could be archived instead of polished for historical completeness.
That kept the redesign tied to live work. It also prevented months of migration effort from delaying the benefits.
What changed after the context improved
Once the workspace became more coherent, agents stopped needing elaborate explanations for ordinary work.
A drafting agent could find the current brand guidance and the document it should update. A meeting workflow could connect an action to an existing project. An employee could ask a cross-team question and receive an answer grounded in the same records colleagues used.
The gains came from consistency more than cleverness. Each new agent inherited the same company objects and ownership rules. Corrections could land in one durable place. New workflows could begin from structured state rather than rebuild context every time.
This is the foundation we would build first again.
AI systems are good at interpreting incomplete instructions. A company should not make incompleteness its operating model. Define the records, assign ownership, preserve decisions, and make trust visible. Then add agents.
Continue the series
Series hub: How BitSafe Runs on AI
Subscribe to the BitSafe newsletter for more from the Canton ecosystem and occasional field notes on how BitSafe operates.

