Understand what plugin.system(context) is for, when it is injected, and how it differs from service.system

Plugin System Text

A plugin can implement:

system(context) {
  return "plugin-level system text";
}

What it means

plugin.system() expresses:

this plugin wants to contribute one system-level text block into runtime prompt assembly

Typical uses:

provider-specific operating guidance
capability-specific usage constraints
telling the agent which installed capability surface is currently available

Difference from `service.system()`

This boundary matters a lot.

`plugin.system`

In the full runtime prompt collection path, plugin system text is part of the formal runtime system assembly.

The runtime currently:

iterates over built-in plugins
only reads system() from enabled plugins
fail-opens if one plugin system loader throws

`service.system`

Services also support system(). In the local SDK session path, both explicitly injected service system text and registered plugin system text are collected by the SDK system composer.

You can inspect the resolved prompt blocks with session.system().

So in current product semantics:

plugin.system is a true runtime prompt augmentation layer
service.system is the service-owned counterpart for long-lived service rules

When plugin.system is a good fit

Use it when the text belongs to:

one plugin's operating guidance
one provider's rules of engagement
one capability package's runtime instructions

Built-in plugins that use it clearly

skill
web
asr
tts

These are all good examples of capability-description system text.

Plugin System Text

Table of Contents