|
|
@@ -97,22 +97,51 @@ Neither mode is assumed to win before measurement:
|
|
|
|
|
|
The likely trade-off is that direct tools may reduce argument-fallback calls on event-heavy conversations, while dual-agent mode should reduce prompt tokens and preserve first-answer behavior as the enabled capability set grows.
|
|
|
|
|
|
-### 2.3 Flat extensibility model
|
|
|
+### 2.3 Generic event kernel and flat built-in plugins
|
|
|
|
|
|
-The initial event model stays flat. There is one registry of self-contained event definitions; the first version does not introduce event category inheritance, nested capability trees, plugins, or a general workflow engine.
|
|
|
+The architecture separates a generic event kernel from concrete built-in event plugins. The plugin registry stays flat: the first version does not introduce event category inheritance, nested capability trees, dynamic installation, or a general workflow engine.
|
|
|
+
|
|
|
+The generic kernel owns only reusable orchestration concepts:
|
|
|
+
|
|
|
+- `EventRequest` and ordered `EventBatch` creation from either model protocol;
|
|
|
+- deterministic resolver chains and bounded LLM fallback;
|
|
|
+- schema validation and confirmation decisions;
|
|
|
+- execution-port invocation;
|
|
|
+- deduplication, concurrency, conflicts, cancellation, timeout, and terminal barriers;
|
|
|
+- normalized `EventResult` values and result-policy aggregation;
|
|
|
+- audit and performance spans.
|
|
|
+
|
|
|
+The kernel must not import, compare, or branch on built-in event names.
|
|
|
+
|
|
|
+A built-in plugin owns one concrete capability:
|
|
|
+
|
|
|
+- its namespaced event name and schema version;
|
|
|
+- the concise ChatAgent catalog description and provider tool schema;
|
|
|
+- deterministic resolver and validator;
|
|
|
+- optional LLM fallback policy;
|
|
|
+- execution handler/port adapter;
|
|
|
+- confirmation, risk, idempotency, concurrency, and result policies;
|
|
|
+- focused contract tests.
|
|
|
+
|
|
|
+Initial plugin names are:
|
|
|
+
|
|
|
+- `session.terminate`;
|
|
|
+- `device.volume.adjust`;
|
|
|
+- `calendar.schedule.create`;
|
|
|
+- `knowledge.web.search`.
|
|
|
|
|
|
Adding a capability should normally require only:
|
|
|
|
|
|
-1. one new event definition containing its name, concise ChatAgent description, argument schema, resolution strategy, result policy, timeout, concurrency metadata, and terminal flag;
|
|
|
+1. one new built-in plugin definition containing its namespaced name, schema version, concise ChatAgent description, argument schema, resolution strategy, result policy, timeout, concurrency metadata, and terminal flag;
|
|
|
2. one deterministic resolver/validator, with optional LLM fallback configuration;
|
|
|
3. one handler or service-owned port adapter;
|
|
|
4. focused contract, execution, failure, and concurrency tests.
|
|
|
|
|
|
-The parsers, ChatAgent protocols, Runtime, and shared event orchestration must not require an event-name-specific branch. They operate on the metadata declared by each definition. The event-specific flow sections below describe initial behavior and acceptance criteria, not hardcoded Runtime architecture.
|
|
|
+The parsers, ChatAgent protocols, Runtime, and generic kernel must not require an event-name-specific branch. They operate on the metadata declared by each plugin definition. The event-specific flow sections below describe built-in plugin behavior and acceptance criteria, not hardcoded Runtime architecture.
|
|
|
|
|
|
Multiple events remain a flat ordered list in one batch. Generic batch orchestration handles deduplication, conflict metadata, bounded concurrency, result aggregation, and terminal barriers.
|
|
|
|
|
|
-The flat model should evolve only when real additions reveal repeated structures that cannot be expressed cleanly with definition metadata. Examples include several events sharing one authorization flow, a multi-step transaction/rollback requirement, or recurring dependencies between event outputs. Until then, those abstractions are deliberately out of scope.
|
|
|
+The flat plugin registry should evolve only when real additions reveal repeated structures that cannot be expressed cleanly with definition metadata. Examples include several events sharing one authorization flow, a multi-step transaction/rollback requirement, or recurring dependencies between event outputs. Until then, those abstractions are deliberately out of scope.
|
|
|
|
|
|
## 3. Event Flows
|
|
|
|
|
|
@@ -191,11 +220,11 @@ Conflict policy:
|
|
|
- an event failure does not cancel unrelated events;
|
|
|
- follow-up outputs are aggregated by policy: deterministic confirmations first, then at most one ChatAgent LLM follow-up for all results that require natural synthesis.
|
|
|
|
|
|
-## 4. Runtime and Registry Changes
|
|
|
+## 4. Generic Kernel, Runtime, and Plugin Registry
|
|
|
|
|
|
-The design extends the registry-owned event definition with execution metadata rather than adding event-name conditionals throughout the runtime.
|
|
|
+The design extracts a generic kernel from Runtime and extends registry-owned plugin definitions with execution metadata rather than adding event-name conditionals throughout orchestration.
|
|
|
|
|
|
-Conceptually, an event definition contains:
|
|
|
+Conceptually, a built-in plugin definition contains:
|
|
|
|
|
|
- name, description, and JSON argument schema;
|
|
|
- argument-generation behavior;
|
|
|
@@ -208,18 +237,17 @@ Conceptually, an event definition contains:
|
|
|
- whether failure is safe to expose to ChatAgent;
|
|
|
- whether the event makes the session terminal.
|
|
|
|
|
|
-The runtime remains responsible for orchestration and ordering:
|
|
|
+Runtime remains responsible for session/turn and model-stream lifecycle. It delegates event work to the generic kernel:
|
|
|
|
|
|
1. stream ChatAgent output;
|
|
|
2. parse hidden text events or collect native tool calls into the same internal event batch;
|
|
|
-3. resolve event arguments using deterministic parsers first and LLM fallback only when needed;
|
|
|
-4. apply deduplication, conflict, and concurrency rules;
|
|
|
-5. dispatch independent EventAgent work concurrently;
|
|
|
-6. publish audit/tool results;
|
|
|
-7. apply each event's result policy;
|
|
|
-8. optionally run one aggregated follow-up ChatAgent round.
|
|
|
-
|
|
|
-EventAgent remains responsible for argument resolution, validation, and handler invocation. Production side effects remain behind service-owned ports/adapters.
|
|
|
+3. submit the flat batch to the event kernel;
|
|
|
+4. let the kernel resolve, validate, confirm, deduplicate, schedule, execute, and normalize results using plugin metadata;
|
|
|
+5. publish normalized audit/tool results;
|
|
|
+6. apply the kernel's aggregated continuation decision;
|
|
|
+7. optionally run one aggregated follow-up ChatAgent round.
|
|
|
+
|
|
|
+EventAgent supplies optional LLM fallback to the kernel; it does not own built-in event behavior. Production side effects remain behind service-owned ports/adapters implemented by plugins.
|
|
|
|
|
|
The local fast Gate for obvious high-confidence intents remains a later optimization. It should be evaluated only after the two configured model-driven modes establish a baseline and production-like measurements show that event-catalog/tool-schema cost or event-selection errors justify the added routing complexity.
|
|
|
|
zhenyu.hu