@lazyingart/agintiflow 0.17.1 → 0.17.2

package/README.md

@@ -79,13 +79,13 @@ For larger repositories, use `--profile large-codebase` or choose **Large codeba
 
 AgInTiFlow can also spend cheap DeepSeek calls on parallel scout notes before the main executor starts a complicated task. It first writes a bounded project map to `.aginti/codebase-map.json`, then runs scouts for architecture, implementation, review, research, context mapping, tests, git workflow, integration, symbol tracing, and dependency risks. A coordinator Swarm Board is injected for the main agent and saved as `artifacts/scout-blackboard.json` in the session. The executor still does the real file/shell/browser work itself. Disable with `--no-parallel-scouts` or set `--scout-count 1..10`.
 
-The next productive-agent roadmap is tracked in [docs/productive-agent-roadmap.md](docs/productive-agent-roadmap.md): durable codebase maps, stronger scout blackboards, long-run checkpoints, LSP/symbol tools, test triage, and release automation.
+The next productive-agent roadmap is tracked in [docs/productive-agent-roadmap.md](docs/productive-agent-roadmap.md): durable codebase maps, stronger scout blackboards, long-run checkpoints, LSP/symbol tools, test triage, and release automation. Runtime choices, Docker persistence, host full-access tradeoffs, tmux sessions, and rolling-plan autonomy are documented in [docs/runtime-modes-and-autonomy.md](docs/runtime-modes-and-autonomy.md).
 
 For current docs, install errors, package/toolchain setup, and source discovery, the agent has a guarded `web_search` tool. It returns compact search results without browser search-engine loops and respects configured domain allowlists. Disable with `--no-web-search`.
 
 For raster image work, AgInTiFlow has an optional `image_generation` skill backed by the `generate_image` tool and a local `GRSAI` key. The skill tells DeepSeek when image generation is appropriate; the tool calls GRS AI Nano Banana, saves manifests/images under `artifacts/images`, and sends the result to the canvas. See [docs/auxiliary-image-generation.md](docs/auxiliary-image-generation.md).
 
-For long-running shell work, AgInTiFlow exposes host-side tmux tools when the shell tool is enabled: `tmux_list_sessions`, `tmux_capture_pane`, `tmux_send_keys`, and `tmux_start_session`. Use normal prompts such as `start this test server in tmux and monitor it` or `check my tmux session`. The agent captures panes before interacting, redacts outputs, blocks secret-like sends, and avoids sending sudo passwords or destructive commands.
+For long-running shell work, AgInTiFlow exposes host-side tmux tools when the shell tool is enabled: `tmux_list_sessions`, `tmux_capture_pane`, `tmux_send_keys`, and `tmux_start_session`. Use normal prompts such as `start this test server in tmux and monitor it` or `check my tmux session`. The agent captures panes before interacting, redacts outputs, blocks secret-like sends, and avoids sending sudo passwords or destructive commands. Tmux is intentionally host-side: Docker `run_command` containers are short-lived, so tmux servers started there cannot persist.
 
 AgInTiFlow now ships a Markdown skill library in `skills/<id>/SKILL.md`. Skills are prompt playbooks, while tools are deterministic actions such as `apply_patch`, `run_command`, `web_search`, `generate_image`, and `send_to_canvas`. Built-in skills cover code, websites/apps, LaTeX manuscripts, books, Word documents, image generation, GitHub, system maintenance, Android, R/Stan, Python, C/C++, shell, AAPS, and novel writing. See [docs/skills-and-tools.md](docs/skills-and-tools.md).
 

package/docs/agent-runtime-pipe.md

@@ -17,6 +17,8 @@ Runs can be stopped without corrupting session state. The CLI listens for Ctrl+C
 
 Default execution is Docker workspace mode with package installs approved inside the sandbox. The project is mounted at `/workspace`; persistent agent toolchain folders are mounted at `/aginti-home`, `/aginti-cache`, and `/aginti-env` from `~/.agintiflow/docker/`. Python, conda, and other language-level environments should be installed under `/aginti-env` so they survive across runs. Apt/apk package changes are ephemeral unless the Docker image is rebuilt.
 
+Docker shell commands are process-ephemeral: each `run_command` call starts a new short-lived container. Durable terminals, dev servers, and external agents should use host tmux tools, or a future persistent service-container mode. See [runtime-modes-and-autonomy.md](runtime-modes-and-autonomy.md).
+
 Generated local websites should use `preview_workspace` or `open_workspace_file`. The preview tool serves the host workspace on an automatically selected `127.0.0.1` port and opens it in the browser. AgInTiFlow blocks common transient Docker preview commands such as `python -m http.server` because each shell tool call runs in a short-lived container with no published host port.
 
 The failed `f(f(x)) = f'(x)` LaTeX task exposed three issues: host-mode command policy blocked setup/path commands, a 15-step budget was too small for iterative numerical work plus TeX output, and follow-up input could not be queued while the agent was running. The current runtime defaults and inbox pipe address those without hardcoding that specific math task.

package/docs/productive-agent-roadmap.md

@@ -27,9 +27,24 @@ AgInTiFlow should become a practical coding agent, not only a chat UI around a m
 6. Patch review loop: before finalizing large edits, run a cheap reviewer scout over diffs, risks, and missing tests.
 7. Dependency doctor: detect toolchain gaps and propose Docker/project-local setup before touching host installs.
 8. Release assistant: status, diff, changelog, version bump, pack, publish, push, and rollback notes as a reusable workflow.
+9. Rolling autonomy loop: replan by phase, gate each phase with a check, checkpoint artifacts/diffs, and continue until the requested outcome is complete or genuinely blocked.
+10. Persistent service containers: add a project-scoped long-running container mode for durable tmux/dev-server/language-server processes while preserving Docker isolation.
 
 ## Swarm Design
 
 Scouts must not become noisy subagents. Each scout gets the same bounded context pack generated from the durable codebase map and one role. The coordinator produces a Swarm Board with shared context, execution order, disagreements, must-read files, checks, and stop conditions. The main agent still owns tool use and must re-read exact files before editing.
 
 Use 3 scouts for medium tasks, 5 for large tasks, and up to 10 for complex multi-language or system tasks. More scouts are only useful when their roles cover different failure modes.
+
+## Long-Running Work
+
+The agent should not stop merely because the first plan was exhausted. It should maintain a rolling phase loop:
+
+1. Inspect the current project state.
+2. Pick the next concrete milestone.
+3. Execute with tools.
+4. Run the narrowest useful check.
+5. Save a checkpoint event, artifact, or diff.
+6. Replan from the new state.
+
+The loop ends only when the requested outcome is complete, the user interrupts, or a real dependency blocks progress. This avoids giant brittle plans while still supporting long autonomous work.

package/docs/runtime-modes-and-autonomy.md

@@ -0,0 +1,106 @@
+# Runtime Modes And Long-Running Autonomy
+
+AgInTiFlow should feel like a normal coding agent, but with an explicit execution contract. The core decision is not "safe versus useful"; it is which execution mode matches the task.
+
+## Evaluation Of The Tmux-In-Docker Case
+
+The failed task was expected under the current Docker design, but the agent should have chosen a better path.
+
+- `run_command` in Docker mode uses short-lived `docker run --rm` containers.
+- A tmux server started inside that container dies when the command exits.
+- Persistent folders such as `/aginti-env` and `/aginti-cache` preserve files and language environments, not running processes.
+- For durable terminal sessions, the correct tool is host-side `tmux_start_session`, followed by `tmux_capture_pane` and `tmux_send_keys`.
+
+The fix is guidance plus guardrails: raw `tmux` shell commands are blocked inside Docker `run_command`, and the model is told to use host tmux tools for durable sessions.
+
+## Execution Modes
+
+| Mode | Similar Codex idea | Best use | What persists | Risk |
+| --- | --- | --- | --- | --- |
+| `docker-readonly` | `-s read-only` | Inspect code, run read-only checks | Session logs only | Lowest |
+| `docker-workspace` | `-s workspace-write` | Normal coding, plotting, LaTeX, package setup | Workspace files, `/aginti-env`, `/aginti-cache` | Low to medium |
+| `host` conservative | Workspace access with approval | Git, host tools, local previews | Host filesystem changes in project | Medium |
+| `host` trusted | `-s danger-full-access -a never` style | Autonomous computer maintenance, host services, privileged workflows | Host state | High |
+| Future persistent container | Externally sandboxed full-auto | Long-running services and durable container processes | Workspace, env, running processes | Medium |
+
+Codex exposes these concerns as `--sandbox read-only|workspace-write|danger-full-access` and `--ask-for-approval untrusted|on-failure|on-request|never`. AgInTiFlow maps the same philosophy into:
+
+- `--sandbox-mode host|docker-readonly|docker-workspace`
+- `--package-install-policy block|prompt|allow`
+- `--allow-shell|--no-shell`
+- `--allow-destructive`
+
+## Docker Package Installs
+
+Docker package installs are safe when they match the sandbox contract.
+
+- `npm`, `pip`, `conda`, `curl`, `wget`, and `chmod` are practical inside `docker-workspace` when package policy is `allow`.
+- Python and conda-style environments should live under `/aginti-env` so they survive future runs.
+- Download caches should live under `/aginti-cache`.
+- OS package installs such as `apt-get install htop` affect only the current short-lived command container unless the Docker image is rebuilt.
+- To make OS packages portable, add them to `docker/sandbox.Dockerfile` and rebuild with `scripts/setup-agent-toolchain-docker.sh`.
+
+This is why a task can safely install Python packages in Docker, but cannot keep an interactive tmux server alive inside a one-shot Docker command.
+
+## Recommended Defaults
+
+Default daily coding:
+
+```bash
+aginti
+```
+
+This starts interactive chat with Docker workspace mode, file tools, shell tools, web search, and package installs allowed inside Docker.
+
+Direct trusted host mode:
+
+```bash
+aginti --sandbox-mode host --allow-shell --allow-destructive "fix this local service"
+```
+
+Use this only when the task truly needs host access. The agent should inspect first, show risky commands, stop on ambiguity, and avoid secrets.
+
+Durable tmux task:
+
+```bash
+aginti "start a tmux session named demo, run ls in it, keep it open, and tell me how to attach"
+```
+
+The agent should use `tmux_start_session`, `tmux_send_keys`, and `tmux_capture_pane`, not Docker `run_command`.
+
+## Future Persistent Container Mode
+
+A useful next runtime mode is a service container:
+
+- Start one named container per project, for example `agintiflow-<project-hash>`.
+- Mount the workspace, `/aginti-home`, `/aginti-cache`, and `/aginti-env`.
+- Keep the container alive with a shell, supervisor, or tmux server.
+- Execute later commands with `docker exec` instead of `docker run --rm`.
+- Provide explicit lifecycle commands: start, status, capture, stop, reset, rebuild.
+
+This would support durable tmux, dev servers, long installs, notebooks, and language servers inside a portable container while still isolating the host.
+
+## Long-Running Autonomy
+
+Large tasks should not stop because an early high-level plan ran out. AgInTiFlow should use rolling plans:
+
+1. Orient: inspect project instructions, git status, manifests, and current files.
+2. Plan the next phase only: choose a concrete milestone with a check.
+3. Execute: edit files, run commands, and capture artifacts.
+4. Gate quality: run the narrowest useful test, lint, compile, preview, or smoke check.
+5. Checkpoint: persist a session event, artifact, diff, or note.
+6. Replan: if the goal is not done, generate the next phase from the current state.
+7. Stop only when the requested outcome is complete, blocked by a real dependency, or the user interrupts.
+
+This keeps the agent sober. It avoids giant low-quality plans while still allowing long autonomous work.
+
+## Documentation Maintenance
+
+The documentation should be maintained as product code:
+
+- Keep reference docs in `docs/`.
+- Link important docs from `README.md` and the marketing website.
+- Add smoke tests when a workflow becomes behavior, not just guidance.
+- Update `AGINTI.md` for project-specific operating memory.
+- Treat docs changes as part of the release checklist before publishing npm.
+

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lazyingart/agintiflow",
-  "version": "0.17.1",
+  "version": "0.17.2",
   "type": "module",
   "description": "AgInTiFlow is a resumable Playwright website-control agent with OpenAI-compatible tool calling.",
   "license": "Apache-2.0",

package/scripts/smoke-tmux-tools.js

@@ -13,6 +13,7 @@ import {
   startTmuxSession,
   tmuxAvailable,
 } from "../src/tmux-tools.js";
+import { checkToolUse } from "../src/guardrails.js";
 
 const execFile = promisify(execFileCallback);
 const workspace = await fs.mkdtemp(path.join(os.tmpdir(), "agintiflow-tmux-"));
@@ -64,13 +65,35 @@ try {
   const destructive = checkTmuxToolUse("tmux_send_keys", { target: start.target, text: "rm -rf /" }, config);
   assert.equal(destructive.allowed, false, "tmux guardrail did not block destructive text");
 
+  const dockerTmuxCommand = checkToolUse({
+    toolName: "run_command",
+    args: { command: "tmux new-session -d -s should-not-run" },
+    config: { ...config, useDockerSandbox: true, sandboxMode: "docker-workspace", packageInstallPolicy: "allow" },
+  });
+  assert.equal(dockerTmuxCommand.allowed, false, "Docker run_command tmux usage should be blocked in favor of host tmux tools");
+  const dockerTmuxSearch = checkToolUse({
+    toolName: "run_command",
+    args: { command: "rg tmux README.md" },
+    config: { ...config, useDockerSandbox: true, sandboxMode: "docker-workspace", packageInstallPolicy: "allow" },
+  });
+  assert.equal(dockerTmuxSearch.allowed, true, "Docker run_command should still allow harmless tmux text searches");
+
   console.log(
     JSON.stringify(
       {
         ok: true,
         session,
         workspace,
-        checks: ["start-session", "send-keys", "capture-pane", "list-sessions", "secret-guardrail", "destructive-guardrail"],
+        checks: [
+          "start-session",
+          "send-keys",
+          "capture-pane",
+          "list-sessions",
+          "secret-guardrail",
+          "destructive-guardrail",
+          "docker-run-command-tmux-guardrail",
+          "docker-run-command-tmux-search-allowed",
+        ],
       },
       null,
       2

package/skills/tmux-session/SKILL.md

@@ -19,14 +19,16 @@ tools:
 ---
 # Tmux Session Control
 
-Use tmux tools for work that should keep running while the agent remains responsive: installs, builds, tests, dev servers, external agents, and monitored shells.
+Use host tmux tools for work that should keep running while the agent remains responsive: installs, builds, tests, dev servers, external agents, and monitored shells.
+
+Important runtime distinction: `run_command` in Docker mode runs a short-lived `docker run --rm` container. A tmux server created there dies when that command exits. Do not install or start tmux inside Docker command containers for persistent sessions. Use the host-side tmux tools instead.
 
 Workflow:
 
 1. Discover with `tmux_list_sessions` unless the user gave an exact target.
 2. Capture with `tmux_capture_pane` before sending input so context is current.
-3. Use `tmux_start_session` for new durable jobs rooted in the workspace.
+3. Use `tmux_start_session` for new durable host jobs rooted in the workspace.
 4. Use `tmux_send_keys` sparingly and never send secrets, sudo passwords, destructive commands, or unreviewed pasted scripts.
 5. For long commands, capture progress periodically and summarize the latest useful lines instead of flooding the chat.
 
-If a package or sudo install is missing, report the exact command and whether it should run in Docker, host, or a user-owned tmux session.
+If host tmux is unavailable, report that limitation and suggest installing tmux on the host or using a future persistent service-container mode. If a package or sudo install is missing, report the exact command and whether it should run in Docker, host, or a user-owned tmux session.

package/src/agent-runner.js

@@ -308,7 +308,7 @@ async function createInitialState(config, sessionId) {
               : `A host shell command tool is available under the configured trust policy on ${platformLabel(platform)}. On native Windows, prefer PowerShell/cmd-compatible commands or switch to WSL/Docker for bash-like toolchains.`
             : "No shell command tool is available.",
           config.allowShellTool
-            ? "Host tmux tools are available for long-running terminals: list sessions, capture panes, send safe keys/text, and start detached sessions. Prefer tmux for monitoring long installs/tests/dev servers without blocking; capture before sending input and never send secrets or sudo passwords."
+            ? "Host tmux tools are available for long-running terminals: list sessions, capture panes, send safe keys/text, and start detached sessions. Prefer these tools for monitoring long installs/tests/dev servers without blocking; capture before sending input and never send secrets or sudo passwords. Do not start or install tmux inside Docker run_command containers because those containers are short-lived."
             : "",
           config.allowFileTools
             ? `Workspace file tools are available in ${config.commandCwd}: inspect_project, list_files, read_file, search_files, write_file, apply_patch, open_workspace_file, and preview_workspace. For large or unfamiliar repositories, call inspect_project first, then search/read AGINTI.md/AGENTS.md/README/manifests as relevant before editing. apply_patch supports exact single-file replacements plus Codex-style/unified multi-file patches; prefer it for source edits after reading/searching the relevant context. Always use workspace-relative paths such as plot_fx.svg or docs/report.tex, never absolute host paths. Secret paths, .git internals, node_modules writes, and huge files are blocked. For generated local websites/pages, use open_workspace_file or preview_workspace instead of starting a localhost server inside Docker.`
@@ -339,6 +339,7 @@ async function createInitialState(config, sessionId) {
           "For research or web-search tasks, use browser tools or safe shell network tools when the current policy allows; cite or save useful sources in workspace notes when the task needs traceability.",
           "Use the canvas tunnel for outputs the user would likely want to inspect visually, such as figures, PDFs, screenshots, images, important markdown, or generated files.",
           "For environment or system-maintenance work, use the configured sandbox and package policy; Docker workspace mode is the preferred place for installs and toolchain setup.",
+          "For long-running work, create a durable checkpoint or artifact at each completed phase, then continue with the next concrete phase until the requested outcome is actually complete or blocked by a real dependency.",
           "If the user asks to open a generated local website or file, use open_workspace_file for a file or preview_workspace for a static site. Do not keep retrying the same localhost URL when a preview fails.",
           "Docker language/toolchain installs should prefer /aginti-env or project files so they persist across runs; apt/apk changes are ephemeral unless the image is rebuilt.",
           "If the run is close to the max-step limit, finish with the best complete artifact and honest limitations instead of starting a new approach.",
@@ -702,7 +703,7 @@ async function captureSyntheticSnapshot(store, step, config) {
           : `Shell tool available in: ${config.commandCwd} on ${platformLabel(platform)}. Use OS-compatible commands; prefer WSL/Docker for bash-heavy workflows on Windows.`
         : "Shell tool disabled.",
       config.allowShellTool
-        ? "Host tmux tools available: tmux_list_sessions, tmux_capture_pane, tmux_send_keys, tmux_start_session. Use them for long-running jobs and agent terminals; capture before sending input."
+        ? "Host tmux tools available: tmux_list_sessions, tmux_capture_pane, tmux_send_keys, tmux_start_session. Use them for long-running jobs and agent terminals; capture before sending input. Docker run_command containers are ephemeral, so tmux there will not persist."
         : "",
       config.allowFileTools
         ? `Workspace file tools available in: ${config.commandCwd}. Use inspect_project first for large or unfamiliar codebases, then search/read exact files before editing. Use workspace-relative paths. Use apply_patch for code edits; it supports exact single-file replacement and multi-file Codex-style/unified patches.`

package/src/guardrails.js

@@ -38,6 +38,17 @@ function isTransientDockerPreviewCommand(command) {
   );
 }
 
+function isDockerTmuxProcessCommand(command = "") {
+  return [
+    /^tmux\b/i,
+    /^(?:sudo\s+)?apt(?:-get)?\s+install\b.*\btmux\b/i,
+    /^(?:sudo\s+)?(?:dnf|yum)\s+install\b.*\btmux\b/i,
+    /^apk\s+add\b.*\btmux\b/i,
+    /^brew\s+install\b.*\btmux\b/i,
+    /^(curl|wget)\b.*\btmux\b/i,
+  ].some((pattern) => pattern.test(command));
+}
+
 function normalizeDomain(hostname) {
   return hostname.replace(/^www\./, "").toLowerCase();
 }
@@ -126,6 +137,14 @@ export function checkToolUse({ toolName, args, snapshot, config }) {
 
   if (toolName === "run_command") {
     const command = String(args.command || "").trim();
+    if (config.useDockerSandbox && isDockerTmuxProcessCommand(command)) {
+      return {
+        allowed: false,
+        reason:
+          "Docker run_command containers are short-lived, so tmux started there cannot persist. Use host tmux tools: tmux_start_session, tmux_capture_pane, tmux_send_keys, or tmux_list_sessions.",
+        category: "tmux",
+      };
+    }
     if (config.useDockerSandbox && isTransientDockerPreviewCommand(command)) {
       return {
         allowed: false,

package/src/model-client.js

@@ -227,7 +227,7 @@ export async function createPlan(client, config, state) {
             ? `Shell tool is enabled in ${config.commandCwd}. Host platform: ${platformLabel(platform)}. In Docker, this path is mounted as /workspace with persistent /aginti-env and /aginti-cache mounts. Use relative paths or /workspace paths, not absolute host temp paths. Sandbox mode: ${config.sandboxMode}. Package install policy: ${config.packageInstallPolicy}. For npm/pip/conda/venv setup, explain the need and wait for approval unless policy is allow. On native Windows host mode, prefer PowerShell/cmd-compatible commands or WSL/Docker for bash-like toolchains.`
             : "",
           config.allowShellTool
-            ? "Host tmux tools are enabled for long-running sessions. Plan to use tmux_start_session for durable jobs, tmux_capture_pane to monitor, tmux_send_keys to interact after capture, and tmux_list_sessions to discover existing sessions."
+            ? "Host tmux tools are enabled for long-running sessions. Plan to use tmux_start_session for durable jobs, tmux_capture_pane to monitor, tmux_send_keys to interact after capture, and tmux_list_sessions to discover existing sessions. Do not install or run tmux inside Docker run_command containers; those containers are short-lived and cannot preserve tmux servers."
             : "",
           config.allowFileTools
             ? `Workspace file tools are enabled in ${config.commandCwd}: inspect_project, list_files, read_file, search_files, write_file, apply_patch, open_workspace_file, preview_workspace. For large or unfamiliar repos, plan to call inspect_project first, then search/read AGINTI.md/AGENTS.md/README/manifests and exact files. apply_patch supports exact single-file replacements and Codex-style/unified multi-file patches; prefer it for edits after reading relevant context. Keep all paths workspace-relative, for example plot_fx.svg or docs/report.tex, and avoid secrets. For generated local HTML/SVG/PDF/static sites, plan to use open_workspace_file or preview_workspace rather than starting a localhost server inside Docker.`
@@ -468,7 +468,7 @@ export async function requestNextStep(client, config, messages) {
         function: {
           name: "tmux_list_sessions",
           description:
-            "List host tmux sessions and panes. Use this to discover long-running terminals, agent sessions, dev servers, or jobs before interacting with them. tmux tools run host-side even when command execution is Docker-sandboxed.",
+            "List durable host tmux sessions and panes. Use this to discover long-running terminals, agent sessions, dev servers, or jobs before interacting with them. tmux tools run host-side even when command execution is Docker-sandboxed; do not use run_command to start tmux inside an ephemeral Docker container.",
           parameters: {
             type: "object",
             properties: {
@@ -483,7 +483,7 @@ export async function requestNextStep(client, config, messages) {
         function: {
           name: "tmux_capture_pane",
           description:
-            "Capture recent text from a host tmux pane by target such as session:0.0. Use this to monitor progress or inspect a long-running job without interrupting it.",
+            "Capture recent text from a durable host tmux pane by target such as session:0.0. Use this to monitor progress or inspect a long-running job without interrupting it.",
           parameters: {
             type: "object",
             properties: {
@@ -500,7 +500,7 @@ export async function requestNextStep(client, config, messages) {
         function: {
           name: "tmux_send_keys",
           description:
-            "Send literal text and/or safe control keys to a host tmux pane. Use for interacting with known shells or agent sessions after capturing context. Do not send secrets, passwords, sudo passwords, or destructive commands.",
+            "Send literal text and/or safe control keys to a durable host tmux pane. Use for interacting with known shells or agent sessions after capturing context. Do not send secrets, passwords, sudo passwords, or destructive commands.",
           parameters: {
             type: "object",
             properties: {
@@ -526,7 +526,7 @@ export async function requestNextStep(client, config, messages) {
         function: {
           name: "tmux_start_session",
           description:
-            "Start a detached host tmux session rooted inside the workspace, optionally with a startup command. Use for long-running local jobs that should be monitored with tmux_capture_pane instead of blocking the agent.",
+            "Start a detached durable host tmux session rooted inside the workspace, optionally with a startup command. Use for long-running local jobs that should be monitored with tmux_capture_pane instead of blocking the agent. This is the correct tmux path in Docker mode because run_command containers are ephemeral.",
           parameters: {
             type: "object",
             properties: {