Cloud-native applications were designed around cloud primitives. Codebolt-native applications are designed around Codebolt primitives: agents, plugins, memory, tasks, environments, dynamic panels, and cloud-scale execution.
codebolt
threads
refactor auth running
write tests queued
review diff ready
panels
chat | files | git | logs | settings
runtime
local -> docker -> remote -> cloud A Codebolt-native application is not just a web app with an AI chat box. It is an application whose workflow, backend, and runtime behavior are built around the Codebolt engine. The app can call agents, manage tasks, open dynamic panels, run plugins, coordinate environments, use memory, and scale work through local or cloud agent runtimes.
Choose the level of integration that matches your product. Start with APIs, move into plugin-backed applications, embed UI directly inside Codebolt, or host the engine yourself.
Connect a third-party product to Codebolt through the Client SDK or Cloud API. Your app keeps its own UI while Codebolt supplies agents, threads, tasks, jobs, git, memory, environments, and real-time sockets.
your product
│ REST + WebSocket
▼
Codebolt server / Cloud API
├─ agents + threads
├─ tasks + jobs
├─ memory + knowledge
└─ environments + tools
Use the Plugin SDK as the backend for app features. The plugin can expose Hono-style routes, validate requests, run engine APIs, push events, and keep application logic close to the runtime.
Open dynamic panels inside Codebolt so the application UI lives directly in the editor. Agents and plugins can open, update, stream to, and close panels during a workflow.
Run Codebolt on your own server or infrastructure like an agent framework, but with engine-level capabilities already included: agents, plugins, memory, orchestration, provider routing, environments, and UI extension points.
Let applications invoke Cloud agents as backend workers. Codebolt Cloud can route runs, start sandboxes, stream status, preserve run state, and scale agent invocations independently from the application frontend.
Applications inherit engine primitives instead of rebuilding them: agent management, multi-agent coordination, plugin execution, memory, evals, tasks, jobs, environment lifecycle, logs, and provider/model routing.
A third-party product can connect directly to a local Codebolt server or Codebolt Cloud using the Client SDK and APIs. That product can keep its own frontend, auth, domain model, and business workflow while delegating agent execution, task management, jobs, git operations, memory, environment control, and real-time updates to Codebolt. This is the lightest way to make an existing product Codebolt-native.
React / SaaS / internal tool
│
├─ REST APIs
├─ WebSocket events
└─ Cloud API
│
▼
Codebolt runtime
├─ chat + threads
├─ tasks + jobs
├─ agents + execution
├─ git + files
├─ memory + knowledge
└─ environments
For deeper integration, a Codebolt plugin can become the backend for a web application surface. The feedback form plugin is the small version of this pattern: the UI calls a plugin route, the plugin handles the request, updates state, emits events, and can use the full engine context. Larger applications can use the same shape for approvals, dashboards, review tools, business workflows, or vertical agent products.
UI panel
│ codeboltPlugin.fetch('/feedback')
▼
plugin.dynamicPanel.router(panelId)
├─ validate request
├─ call engine APIs
├─ run agents / jobs
├─ emit live events
└─ return JSON
plugin is the backend
Codebolt is the runtime
A Codebolt-native application can run inside the Codebolt Editor itself. Dynamic panels let plugins and agents create application UI at runtime, stream data into it, receive user actions, and adapt the interface to the workflow. That means Codebolt can become a planning tool, review console, support dashboard, data labeling surface, operations cockpit, or any domain app that needs agents as first-class workers.
Codebolt Editor
│
├─ project workspace
├─ agent threads
├─ terminal / files / git
└─ dynamic app panels
▲
│ messages + events
▼
plugin backend + engine APIs
the editor becomes your app shell
The application does not have to care whether work runs on a laptop, a cloud sandbox, a local server, or your own infrastructure. Codebolt can be used like an agent framework, but the framework already includes runtime UI, plugin lifecycle, memory, task state, environment routing, multi-agent coordination, and operational visibility. For Codebolt Cloud, applications can call backend agents through the API and scale each invocation independently.
Codebolt-native app
│
├─ local Codebolt server
├─ Codebolt Cloud API
├─ self-hosted engine
└─ remote environments
same app contract
different execution topology
Treat AI as a chat sidebar or one-off API call
Rebuild agent state, memory, task tracking, logs, and execution management from scratch
Need a separate backend for orchestration, tool access, scheduling, and long-running jobs
Often stop at one agent in one environment
Have to invent their own UI extension and plugin model
Use Codebolt as the backend runtime for agents, plugins, memory, jobs, tasks, and environments
Can run as standalone apps, plugin-backed apps, dynamic panels, Cloud API clients, or self-hosted engine deployments
Get multi-agent coordination and multi-environment scaling as runtime capabilities
Can turn the Codebolt Editor into a custom application shell
Build domain software on top of an engine that can evolve the agents, plugins, and UI around the workflow
The reason this matters is leverage. A Codebolt-native application starts with the engine features already in place: agent portfolios, custom agents, plugins, memory, tasks, jobs, files, git, terminals, environment providers, model routing, event streams, observability, evaluations, and dynamic UI. Instead of building a server around an agent, you build the application on an engine that already knows how agent work behaves.
engine capabilities
├─ agent management
├─ custom agents + plugins
├─ memory + knowledge
├─ tasks + jobs + goals
├─ files + git + terminals
├─ model/provider routing
├─ local/cloud environments
├─ observability + evals
└─ dynamic panels
your app composes these
instead of rebuilding them