We Built an AI Operating System, Not Another Chatbot

How BitSafe Runs on AI, Part 1 of 5

A chatbot waits for a question. Company work rarely does.

A customer conversation moves while someone is in another meeting. A recurring check gets missed because its owner is focused elsewhere. A useful answer requires context from a document, a recent thread, and an operational system. The hard part is usually not generating a paragraph. It is knowing what changed, finding the right evidence, and taking the next permitted action.

That gap led us to build NanoClaw. The aim was not to create a more talkative assistant. We wanted an execution layer that could work across company systems while staying grounded in the operating context we maintain in Notion.

The central lesson is simple: a company-wide AI becomes useful when its boundaries are designed as carefully as its capabilities.

BitSafe is a 22-person company. Work crosses product, engineering, operations, and commercial teams quickly. The context required to make a sound decision is spread across structured records, conversations, source material, and live systems.

Notion gives us the shared foundation. It is our system of record and collaborative workspace. Projects, documents, decisions, customer context, and operating rules live there in forms that people and agents can inspect together.

NanoClaw handles a different class of work. It performs bespoke computation, gathers cross-source context, runs proactive checks, and executes through approved external tools. The two systems are complementary. Notion keeps company state legible. NanoClaw uses that state alongside other sources to complete work that does not fit inside one workspace.

This division matters because custom AI infrastructure is expensive to build and maintain. It only earns its place when the job requires more than drafting or workspace retrieval. We use it where the work needs one or more of these properties:

If a task can be completed cleanly inside Notion, it should stay there. Custom infrastructure should solve the narrow problems that justify it.

Each NanoClaw run begins in a short-lived execution environment. That choice reduces the amount of hidden state carried from one run into the next. A task starts, receives the context and tools it is allowed to use, completes its work, and ends.

Useful continuity lives outside that temporary runtime. Future work is stored as durable tasks. Confirmed corrections can be saved as memory. Current operating context is assembled from approved sources when a run begins.

This architecture changes the way we think about continuity. We do not ask a model to hold the company in an endless conversation. We keep the important state in systems that can be reviewed and maintained, then give each run only the context it needs.

That creates a healthier failure mode. When a run ends, the task record remains. When the model changes, the operating knowledge remains. When an instruction needs correction, the correction can be reviewed as a durable artifact instead of disappearing into chat history.

Giving an agent access to company systems creates obvious risk. Prompt wording alone is not a sufficient control.

NanoClaw exposes a defined set of actions through a controlled tool layer. The surrounding system checks what the agent is allowed to do before an action is executed. Network access is restricted. Credentials are scoped to the job rather than exposed as general agent context. Actions are logged so operators can reconstruct what happened.

The approval model is based on consequence. Routine reads can proceed without turning every task into a permission dialog. Destructive operations and other high-risk actions require explicit human approval. Automated customer-channel campaigns use a separate human approval workflow before distribution.

These controls are part of the product experience. An agent that asks about every harmless read becomes unusable. An agent that can make consequential changes without a meaningful gate becomes unsafe. The goal is a clear middle ground where low-risk work moves and human judgment stays attached to high-impact decisions.

The most useful company work often begins before anyone opens a chat.

NanoClaw can run recurring checks and surface results when a defined condition is met. A scheduled job can inspect whether source data is fresh. A monitor can detect that an expected process has gone quiet. A digest can collect changes that would otherwise require several people to search across systems.

The agent does not need to stay alive between those moments. The schedule is durable, and each run starts fresh. This keeps proactive work easier to inspect than a long-running process with opaque internal state.

It also supports a stricter notification discipline. Healthy checks should usually remain quiet. Warnings should explain the condition and the expected next step. Critical issues should reach a human through the appropriate escalation path.

Proactivity is valuable only when it reduces attention cost. A system that creates more notifications than decisions has moved the burden rather than removed it.

NanoClaw does not have perfect recall. Its answers depend on the quality, freshness, and permissions of the sources available to a run.

Temporary execution does not create perfect isolation by itself. Security comes from several controls working together, including scoped filesystems, network restrictions, credential handling, permissions, and audit trails.

The system is not autonomous in an absolute sense. People still define policy, approve high-risk actions, review sensitive output, and decide what should become a durable rule.

Those limits make the system more useful. They turn vague claims about an AI coworker into an operating model that can be tested.

Building a company-wide AI starts with a boundary map.

What is the system of record? Which sources can the agent read? Which actions can it take without approval? Which actions always stop for a person? Where does a correction live after the conversation ends?

Once those questions have precise answers, the model becomes one component in a larger system. That system can improve as the company improves its data, skills, and controls.

This is why we describe NanoClaw as an AI operating system. The useful part is the set of loops around the model: durable work, current context, controlled tools, and human authority.

Subscribe to the BitSafe newsletter for the next article.