Bolt request flow

One server + PostgreSQL · Logical responsibilities

Policy outcome
Swipe to explore the diagram →
Bolt request flowA logical view of Bolt: a workspace sends a request to the runtime, which reads context from PostgreSQL, calls a model, routes actions through a policy-controlled executor, requests human approval when required, records outcomes, checks the reply against its tool ledger, and returns it. Background learning maintains memory between conversations.messagecontextmodel callsactionaskdecisionexecutetool resultsrecord outcomedraft + tool ledgerchecked reply + artifactsmemory upkeepdenied resultPeople + conversationsWorkspaceWeb · iPhone · MacServerBolt runtimeOne run per threadShared server pathAction executorAllow · ask · denyExternal toolsConnected systemsWorkspace · CRM · booksPersistent recordPostgreSQLHistory · memory · ledgerSwappable modelsModel adapterContext → next actionWhen policy asksHuman approvalApprove or denyBefore the replyReply checksClaims + terminologyBetween conversationsLearning loopEvidence → memoryBackground workMemory updates and goal review continue between conversations.
1/10 A request arrives

Click a component to inspect it · ← → to step · Space to play or pause

A logical walkthrough of Bolt based on its documented architecture. Boxes represent responsibilities, not separate services. This tour shows one action; tool calls can repeat. Background learning is separate from the live request.