Built-ins Overview
The full built-in plugin map in Downcity, including public SDK plugins and platform-managed infrastructure plugins
Built-ins Overview
The current built-in plugin capabilities in code include:
skillwebsoundworkboardchatcontactscheduletaskmemoryshell
Package imports
Each SDK-facing built-in has an isolated package subpath:
| Plugin | Import path |
|---|---|
chat | @downcity/plugins/chat |
contact | @downcity/plugins/contact |
image | @downcity/plugins/image |
memory | @downcity/plugins/memory |
skill | @downcity/plugins/skill |
sound | @downcity/plugins/sound |
task | @downcity/plugins/task |
web | @downcity/plugins/web |
workboard | @downcity/plugins/workboard |
There is no default built-in collection factory. Import and instantiate the exact plugins required by each Agent.
Two groups matter
Public SDK-facing built-ins
These are the ones most developers are likely to read first:
skillwebsoundworkboardchat
sound requires the FED model catalog plus ASR and TTS functions through its constructor. Built-in plugins are assembled explicitly from their individual package subpaths.
These are the clearest examples for:
- action plugins
- hook or resolve plugins
- system text plugins
- runtime HTTP plugins
- lifecycle plugins that normal SDK users may still understand directly
Platform-managed or infrastructure built-ins
These are also built-ins in code, but they are more platform-oriented:
contactscheduletaskmemoryshell
These plugins are usually read to understand how the platform is assembled, not because every SDK user should manually attach them to a local Agent.
How to read this section
- If you want user-facing capability plugins, start with
skill,web,sound, andchat - If you want platform rule layers, read the built-in authorization capability in
chat - If you want control-plane or status surfaces, read
workboard - If you want infrastructure patterns, read
schedule,task,memory, andshell
Responsibility map
| Plugin | Main role | Shape |
|---|---|---|
skill | skill discovery, installation guidance, and content loading | action + system |
web | web methodology injection and dependency preparation | action + setup + system |
sound | FED speech-model discovery, ASR, TTS, and inbound auto-transcription | action + pipeline + system |
workboard | work snapshots and status surfaces | availability + runtime HTTP |
chat | channel runtime, queue worker, chat authorization, and role resolution | lifecycle + actions + hooks + resolves + system |
contact | peer-to-peer agent linking and sharing | action + system + remote protocol |
schedule | plugin action scheduling infrastructure | lifecycle-only infrastructure |
task | task scheduler and cron execution | lifecycle + actions + system |
memory | provider-neutral long-term memory and recall | lifecycle + actions + system |
shell | shell session runtime | lifecycle + actions |
Important distinction
Do not read “built-in” as “all of these are equally public.”
Some built-ins are best understood as:
- public capability plugins
- platform integration plugins
- infrastructure plugins
That distinction is one of the reasons the plugin concept docs stay in Agent SDK Docs, while concrete plugin guides live here.