TypeScript Runtime in Pedelec
Pedelec runs JavaScript and TypeScript in a Workspace runtime with Sandbox as the default. Either the Agent or an approved Web application can orchestrate execution. A Runtime Module is optional reusable, developer-owned implementation for either path.
| Who orchestrates? | Implementation | Mechanism | Typical use |
|---|---|---|---|
| Agent | Plain script | pedelec-ts-runtime |
A small transformation the Agent writes when needed |
| Agent | Runtime Module | skills.runtimeModules and pedelec-ts-runtime |
The Agent calls a stable, developer-owned API |
| Application | Plain script | workspace.run() |
The application directly runs known Workspace logic |
| Application | Runtime Module | workspace.run(..., { runtimeModules }) |
The application directly invokes reusable Workspace logic |
Choose a path
Section titled “Choose a path”Does the task need Agent reasoning or dynamic planning? Let the Agent choose and run code. If the application already knows the deterministic operation, call workspace.run() directly. Then ask whether a short, one-off script is enough. If the implementation is repeated or domain-specific, package it as a Runtime Module.
An Agent can run a plain script; creating a module is not a prerequisite. Session modules and modules passed to a Workspace run have separate scopes.
Runtime Module or App Tool?
Section titled “Runtime Module or App Tool?”Use a Runtime Module for JavaScript/TypeScript logic operating on Workspace data. Use an App Tool when the Agent needs UI state, application state outside the Workspace, user interaction, browser callbacks, or application-specific RPC behavior. A Runtime Module does not replace an App Tool.
Continue reading
Section titled “Continue reading”- Agent Runtime Execution for plain Agent scripts.
- Runtime Modules for reusable implementation.
- Workspace Runtime Execution for application-controlled runs.
- Runtime & Security for the shared boundary.
- Tools API and PedelecWorkspace for exact contracts; Error Codes for failures.