Skip to main content

Custom Agentic Application

Custom agentic applications are product-specific applications built on top of Codebolt.

The most important architecture choice is where the application runs, and what it connects to.

The three levels

LevelWhere the app runsPrimary connection model
Level 1: Inside CodeboltInside the Codebolt productPlugin SDK, Dynamic Panels, plugin UI
Level 2: Separate app, local Codebolt serverOutside CodeboltClient SDK or Plugin SDK to a local Codebolt server
Level 3: Separate app, hosted runtimesOutside CodeboltCloud relay / remote runtime connection
Custom agentic application architecture showing a custom UI shell, an optional plugin backend, and the Codebolt server as the shared runtime.Three Ways To Build A Custom Agentic Application1. Standalone AppYour front-end talks straight to the Codebolt server over HTTP APIs and sockets.Example`packages/simpleui`React SPA + axios `/api` + Socket.IO namespaces2. UI Wrapped By A PluginA plugin serves the UI inside Codebolt. The UI can still remain mostly front-end only.Example`sample-plugins/simpleui-plugin`plugin manifest points `ui.path` at the built SPA3. Plugin-Backed UIThe UI talks to a plugin bridge, and the plugin acts as the application backend.Example`sample-plugins/feedback-form-plugin``codeboltPlugin` bridge + `plugin.dynamicPanel.*`Codebolt Server Is Still The Runtime Of RecordYour application changes the UX and orchestration shape, but the server still owns files,tasks, threads, chat, agents, tools, memory, and real-time execution state.HTTP APIsrequests, CRUD, commandsSockets / Eventslive chat, tasks, swarm, logsPlugin Busdynamic panel, plugin sdk, gatewaysdirect APIs + socketsplugin hosts the application shelliframe bridge + plugin backendPick the lightest shape that matches your product: direct client if the UI can talk to the server,plugin wrapper if you want it embedded in Codebolt, plugin-backed bridge if the UI needs backend logic or mediation.

What’s in this section

PageWhat it covers
Level 1: Inside CodeboltEmbedded applications built as plugins, Dynamic Panels, or plugin-hosted UIs
Level 2: Separate app, local Codebolt serverStandalone apps that talk to a local Codebolt server over HTTP and WebSockets
Level 3: Separate app, hosted runtimesHosted apps that connect to remote Codebolt runtimes instead of localhost
Choosing the Right ArchitectureHow to decide between the three levels and pick the right SDK

Shared idea

In all three levels, your application can use Codebolt for:

  • Agents and threads
  • Files, tasks, and jobs
  • Memory and event streams
  • Automation, integrations, and routing

What changes is where the UI runs, where the application logic runs, and whether the connection target is local or remote.

See also