Eight Innovation Mechanisms
English | 中文
Innovation lies in how capabilities compose, constrain, and leave evidence—not in tool count
Together, the eight mechanisms explain how an Agent grows from one model call into an execution system an enterprise can configure, supervise, recover, and integrate.
Plugin runtime and complete capability seams.
Event-sourced sessions and tool governance.
Session composition, long-running work, and multiple access paths.
How to read “innovation”
This page asks four questions about each innovation: which business friction it addresses, what mechanism exists in source, what control deployment requires, and what the current implementation does not promise. Business uses are inferences from mechanisms; only capabilities located in code, tests, or current documentation are described as implemented.
| Judgment layer | How this page states it | How a reader should use it |
|---|---|---|
| Implemented mechanism | Names a service, event, plugin, provider, or consumer | Enter technical validation and integration design |
| Application inference | Derives a pilotable business composition from the mechanism | Validate value against a real workflow |
| Current limitation | Names missing capability, trust premise, or protocol scope | Add it to risk and launch conditions |
1. Everything is a plugin: compose instead of forking the core
Business value. One deployment can compose software-delivery, knowledge-work, or controlled back-office Agents through profiles and bundles. Team differences remain in configuration and plugin trees instead of long-lived forks of the agent loop.
Mechanism. Cordis plugins contribute behavior through services, typed events, dependency injection, and reversible effects. Harness models, tools, sessions, Hosts, and client extensions follow the same model. The launcher loads cordis.yml, profiles layer deployment patches, and bundles package installable compositions. See the architecture overview and composition bundles.
Governance and limitation. A plugin is not inherently trusted. Composition determines which services it can call, but a plugin receiving Bash, dynamic Cordis, or live credential services has that authority. Enterprises still need plugin admission, versioning, and configuration review.
2. Capability seams: replace complete capabilities, not scattered branches
Business value. Local shell can become remote execution, model providers can change, and filesystem or persistence backends can move while upper-level tools keep the same call model. This reduces the effect of environment migration and vendor choice on business workflows.
Mechanism. A capability seam includes Service Definition, Service Provider, and Consumer roles. LLM, shell, subprocess, filesystem, web, storage, compaction, and subagent capabilities use this division. The owning capability resolves defaults explicitly instead of hiding fallbacks inside execution. See capability seams.
Governance and limitation. Replaceability does not make security properties identical. The E2B composition is explicitly a POC, the Windows ACL backend reports partial enforcement, and a remote environment must replace filesystem and process worlds together rather than swapping one function.
3. Everything model-visible is replayable: the session log is shared truth
Business value. One record supports recovery, forks, audit, incident analysis, and replay across interfaces. A business team does not have to reconcile contradictory model context, chat UI, and backend logs.
Mechanism. Turns, steps, user messages, assistant output, tool facts, request targets, and policy changes enter append-only SessionEvents. deriveMessages() rebuilds model history from ordered surface events. Compaction changes the derived surface through replacement while raw events remain. The core lives in the session package and session persistence.
Governance and limitation. Reconstructable facts do not automatically constitute compliant audit. Storage retention, access control, redaction, and export policy remain deployment responsibilities. Unknown required events and unsupported format versions refuse loading.
4. Governance in the tool pipeline: shared controls instead of tool-local copies
Business value. Approval, timeouts, audit, sandboxing, result pruning, and UI presentation can attach as common policy without reimplementing each domain tool. A new tool enters the same execution order automatically.
Mechanism. Calls pass through argument materialization, pre-execute, monotonic guards, execute, post-execute, finalize, and immutable result notification. ask becomes execution only after approval; missing approval support becomes denial. See the tool execution pipeline and tool registry.
Governance and limitation. The pipeline controls actions dispatched through the registry. A plugin, Host permission, or dynamic-code capability that can bypass the tool layer requires outer process, container, and deployment controls.
5. Each session owns its Agent composition
Business value. One runtime service can provide different tools, prompts, and models by department, tenant, task type, or risk tier. A platform team maintains the foundation while business teams own controlled compositions.
Mechanism. An Agent preset mounts a plugin tree into session scope, with service resolution ordered Agent, preset, then global. Standing composition lets several sessions reuse one preset's registrations while session identity and logs stay separate. The entry point is the Agent preset registry.
Governance and limitation. A composition cannot switch freely after model-visible output because the history was produced under another capability set. Deleting a preset does not rewrite running sessions; deployment still owns preset trust and configuration sources.
6. Long work becomes observable collaboration instead of one giant prompt
Business value. Complex work can separate goals, plans, background jobs, workflows, and subagents. Operators can inspect progress, tasks can wait for external results, and independent questions can run in parallel.
Mechanism. Goals, plans, jobs, schedules, workflows, and subagents own distinct state, lifecycle events, and model tools. A continuable subagent has durable session identity, later messages, and cold resume; one-shot delegation returns a disposable run handle. See the subagent capability and workflow capability.
Governance and limitation. Dynamic workflows do not journal script progress and cannot resume after process restart. Delegated child Agents use approval policy never. Parallelism is not an automatic benefit; tasks need independent questions and explicit synthesis ownership.
7. One runtime spine exposes multiple access paths
Business value. People collaborate through Web or CLI, automation uses ACP or JSON-RPC, and Python or TypeScript applications integrate through SDKs. Each interface reuses the same agent loop instead of rebuilding it.
Mechanism. Every access path ultimately drives the Agent registry, session events, and composed capabilities. The Web Host provides interactive UI, the headless profile runs one task, ACP serves automation clients, and JSON-RPC supports SDKs. See ACP, the TypeScript SDK, and Python runtime.
Governance and limitation. Interfaces are not equivalent mirrors. ACP creates fresh sessions, accepts baseline text, and emits committed assistant text; it does not expose loading, resume, forks, images, or complete tool trajectories. Integrations must use the capability each protocol actually publishes.
8. The business interface is also a plugin graph
Business value. Domain plugins can ship dedicated tool cards, detail panes, settings pages, and slots with their capability instead of maintaining a separate frontend. Users see business actions rather than generic JSON alone.
Mechanism. The Host scans dsh.client declarations and injects a client boot graph. The browser runtime folds session events through definition registries, conversation nodes, and keyed slots. Tool presentation intent is a pure function of arguments. Entry points include client modules and the Web runtime.
Governance and limitation. Unknown views fall back to generic cards, and malformed boot graphs fail loudly. Client plugins still need content security, sensitive-field hiding, accessibility, and version compatibility.
Choose a pilot from the mechanism
| Innovation mechanism | Best first question to validate | Result not to promise directly |
|---|---|---|
| Plugin composition | Can one foundation produce two clearly different Agents? | Zero-cost maintenance of every composition |
| Capability seams | Can an execution or model backend change without rewriting business tools? | Identical security properties across providers |
| Event-sourced sessions | Do refresh, recovery, and audit read the same facts? | Automatic regulatory compliance |
| Tool governance | Can a risky action be stopped consistently before execution? | Every plugin is constrained by tool policy |
| Session presets | Can teams share a process while separating capability sets? | A built-in enterprise tenancy system |
| Long-running collaboration | Can independent questions run and synthesize observably? | Every task becomes faster when parallelized |
| Multiple access paths | Can Web and automation reuse the same Agent? | Identical features across protocols |
| Client plugin graph | Can a domain action receive dedicated presentation? | No need for frontend product design |
Evidence status: Confirmed against current source unless noted. Business value is an application inference; limitations define the currently verifiable range.